feat: alternate approach for external crn support

[Aashiq-J]

Description

Issue: #510
In this alternate approach, we can pass the keys to be created and key_crn of already created keys in the list of keys. For example,

  "key_management": {
    "access_tags": [],
    "keys": [
      {
        "key_ring": "slz-slz-ring",
        "name": "slz-vsi-volume-key",
        "root_key": true
      },
      {
        "name": "sample",
        "crn": "xxxx-xxxx-xxxx-xxxx"
      }
    ],
    "name": "slz-kms",
    "resource_group": "slz-service-rg",
    "use_hs_crypto": false
  },

In this example, the slz-vsi-volume-key key will be created in slz-kms key-protect and sample will not be created as it is an existing key. And the user can use the sample key like rest of the keys in SLZ.

Disclaimer: If the user is using a existing_key_crn the user has to manage the auth policy for the access to the kms.

Release required?

• No release
• Patch release (x.x.X)
• Minor release (x.X.x)
• Major release (X.x.x)

Release notes content

  "key_management": {
      "keys": [
          {
              "key_ring": "slz-slz-ring",
              "name": "slz-slz-key",
              "root_key": true
          },
          {
              "name": "slz-atracker-key",
              "existing_key_crn": "xxxx-xxx-xxx"
          }
      ],
      "name": "slz-slz-kms",
      "resource_group": "slz-service-rg",
      "use_hs_crypto": false
  }

You can now use keys that you created outside this module or from different accounts. You specify the key CRN in the "existing_key_crn" field. When using an existing key crn, user must have an authentication policy that allows the block-storage, cloud-object-storage and secrets-manager to access the Key Management Service in the external account.

Run the pipeline

If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.

Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:

/run pipeline

Checklist for reviewers

• If relevant, a test for the change is included or updated with this PR.
• If relevant, documentation for the change is included or updated with this PR.

Merge actions for mergers

• When merging, use a relevant conventional commit message that is based on the PR contents and any release notes provided by the PR author. The commit message determines whether a new version of the module is needed, and if so, which semver increment to use (major, minor, or patch).
• Merge by using "Squash and merge".

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[SirSpidey]

@Aashiq-J

I think these pieces of content would be helpful:

• variables.tf: If you can't have a description for parts of the object, then include a comment on the existing_key_crn property. Idenitfy which properties are mutually exclusive (in other words, you don't identify both the name and the crn in the same object, right?)
• Does this warrant an example? Or content in the readme for an existing example?
• Good release notes (see below)

Perhaps a release note like this?

You can now use keys that you created outside this module (or is it from different accounts, or is it different instances). You specify the key CRN in the "existing_key_crn" field. The existing key must have an authentication policy that allows the service (which service?) to access the Key Management Service in the external account.

[toddgiguere]

@Aashiq-J
The code changes look good from a terraform standpoint, one of the biggest changes here is that we are switching many of the key.id inputs to key.crn inputs for many of the provider calls.

Have we confirmed that all of the resource blocks are ok with crn instead of the id? Have we done a test with a cross-account key and verified that the resources (cos buckets, boot keys of vsi/cluster etc) are using the correct keys for encryption?

[Aashiq-J]

Hi, @toddgiguere , @SirSpidey

I have tested it and it works with crn. Maybe I can post some screenshots of the test.
I thought of adding a test for it, but to test it we need to add auth policies or create an automated way to add the auth policies in the kms account.

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[SirSpidey]

I realize now that both name and existing CRN are allowed. So I don't have any more comments.

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[jor2]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[Aashiq-J]

/run pipeline

[ocofaigh]

@Aashiq-J probably no point in constantly rebasing and triggering pipeline as every pipeline run is provisioning resources in our account and adding to cost + quotas. Lets get the PR reviewed and approved and then trigger the pipeline. I was off when you guys talked about this so perhaps @toddgiguere you can give it a final review please?

[Aashiq-J]

/run pipeline

[jojustin]

I see Todd has approved this PR. Just merging this.

[terraform-ibm-modules-ops]

🎉 This PR is included in version 4.9.0 🎉

The release is available on:

• GitHub release
• v4.9.0

Your semantic-release bot 📦🚀