feat(imagebuilder-alpha): add support for Component Construct

[tarunb12]

Issue

aws/aws-cdk-rfcs#789

Reason for this change

This change adds a new alpha module for EC2 Image Builder L2 Constructs (@aws-cdk/aws-imagebuilder-alpha), as outlined in aws/aws-cdk-rfcs#789. This PR specifically implements the Component construct.

Description of changes

This change implements the Component construct, which is a higher-level construct of CfnComponent.

Example

const component = new imagebuilder.Component(this, 'Component', {
  componentName: 'build-and-test-component',
  componentVersion: '1.0.0',
  description: 'A build and test component',
  changeDescription: 'Initial version',
  // Encrypt component data with a KMS key
  kmsKey: kms.Key.fromKeyArn(
    this,
    'ComponentKey',
    this.formatArn({ service: 'kms', resource: 'key', resourceName: '1234abcd-12ab-34cd-56ef-1234567890ab' })
  ),
  platform: imagebuilder.Platform.LINUX,
  // Include the OS versions this component supports
  supportedOsVersions: [
    imagebuilder.OSVersion.AMAZON_LINUX,
    imagebuilder.OSVersion.RHEL_10,
    imagebuilder.OSVersion.SLES_15,
    imagebuilder.OSVersion.UBUNTU
  ],
  // Hello world component data
  data: imagebuilder.ComponentData.fromJsonObject({
    name: 'build-and-test-component',
    schemaVersion: imagebuilder.ComponentSchemaVersion.V1_0,
    phases: [
      {
        name: imagebuilder.ComponentPhaseName.BUILD,
        steps: [
          {
            action: imagebuilder.ComponentAction.EXECUTE_BASH,
            name: 'hello-world-build',
            inputs: {
              commands: ['echo "Hello build!"']
            }
          }
        ]
      },
      {
        name: imagebuilder.ComponentPhaseName.VALIDATE,
        steps: [
          {
            action: imagebuilder.ComponentAction.EXECUTE_BASH,
            name: 'hello-world-validate',
            inputs: {
              commands: ['echo "Hello validate!"']
            }
          }
        ]
      },
      {
        name: imagebuilder.ComponentPhaseName.TEST,
        steps: [
          {
            action: imagebuilder.ComponentAction.EXECUTE_BASH,
            name: 'hello-world-test',
            inputs: {
              commands: ['echo "Hello test!"']
            }
          }
        ]
      }
    ]
  })
});

Describe any new or updated permissions being added

N/A - new L2 construct in alpha module

Description of how you validated changes

Validated with unit tests and integration tests. Manually verified generated CFN templates as well.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[ozelalisen]

Left some comments as first part of the review, I am not fully completed

[ozelalisen]

I do not see any configuration for kmsKey, should we not configure permissions for grantEncryptDecrypt for the key to be able to use it?

[tarunb12]

Good call. I can add a method.

[ozelalisen]

Also please add an integ test regarding this, since this is only way we can test it

[tarunb12]

Ah i think i misunderstood. So, IB APIs are able to use the key so long as the caller (deployer of the CFN stack or the role associated with the stack) have permissions to do so. The only other principal that would need access is the instance profile role in the Infrastructure Configuration. We can grant the role permissions on the key automatically if you suggest (whenever we create an image or pipeline in the Image/ImagePipeline construct), or just add a grantDecrypt method on the component.

[tarunb12]

Regarding integ test - the key is actually only used during image builds. Given the construct does not exist yet for Image/ImagePipeline, we probably cannot test that the key permission grant works in an image build until we have those constructs

[ozelalisen]

Yes, that makes sense to add grantDecrypt method on constructor when key exists.

Sounds good, we can add integ tests when those constructs created

[ozelalisen]

I think we should go with the first approach where you grant permissions on the role within Image/Image Pipeline, not with exposing grantDecrypt on this interface, as it has basically no usage rather than exposing a public method, that kmsKey already does. Let's remove this grantMethod in this class

[tarunb12]

ah got it - I had misunderstood. we can do that then

[ozelalisen]

Publishing second round of comments

[ozelalisen]

Also please add an integ test regarding this, since this is only way we can test it

[ozelalisen]

This overcomplicates the token validation with redundant checking. Fn.split and Fn.select already handle tokens internally. So you could basically simplify this as:

const componentNameVersionSplit = componentNameVersion.split('/');
return [componentNameVersionSplit[0], componentNameVersionSplit[1]];

[ozelalisen]

Sorry about this, I recommended wrong method, this should be with FN functions since they can be tokens:

const componentNameVersionSplit = cdk.Fn.split('/', componentNameVersion);
    return [
      cdk.Fn.select(0, componentNameVersionSplit),
      cdk.Fn.select(1, componentNameVersionSplit),
    ];

[ozelalisen]

What I mean here is that you do not need that second split on implementation, as Fn.split checks internally if componentNameVersion is token, so you do not need to provide second part where you use native typescript split function, using only Fn.select and Fn.split is sufficient

[tarunb12]

I see - didn't know Fn worked like that! Updated

[ozelalisen]

Just reminder for next PRs that title should include alpha suffix to be appeared in the CHANGELOG correctly

Pull request has been modified.

[ozelalisen]

Sorry about this, I recommended wrong method, this should be with FN functions since they can be tokens:

const componentNameVersionSplit = cdk.Fn.split('/', componentNameVersion);
    return [
      cdk.Fn.select(0, componentNameVersionSplit),
      cdk.Fn.select(1, componentNameVersionSplit),
    ];

Pull request has been modified.