Service Catalog ProductStack Asset Support

Description

The feature is an improvement to the existing ProductStack construct to add support for the use of Asset files.

Use Case

I’m always frustrated as a Service Catalog administrator when I try to add a Lambda function to my ProductStack in CDK because I want to reference my Lambda code from an asset file, and CDK throws an error when I attempt to synthesize this. This limitation means that I’m unable to make use of ProductStack when I want to create a Service Catalog product consisting of Lambas that run large amounts of code. This is an example of a product which I would like to deploy to Service Catalog and share with end users across AWS accounts:

class ServerlessProduct extends sc.ProductStack {
  constructor(scope: cdk.Construct, id: string) {
    super(scope, id);

    // Defines an AWS Lambda resource
    const myHandler = new lambda.Function(this, 'Handler', {
      runtime: lambda.Runtime.NODEJS_14_X,
      code: lambda.Code.fromAsset(path.join(__dirname, 'handler')),
      handler: 'index.handler'
    });

    // Defines an API Gateway REST API resource backed by the handler function
    new apigw.LambdaRestApi(this, 'Endpoint', {
      handler: myHandler
    });
  }
}

When cdk synth is called, it will throw: Service Catalog Product Stacks cannot use Assets

##Proposed Solution

Currently, CDK vends an asset bucket during bootstrap-time to the customer’s AWS account. This bucket can be used successfully for enabling file asset support in ProductStack with CFN outputs from the parent stack for both the S3 bucket name and object key. The major issue with this approach is that when sharing a Service Catalog portfolio across accounts, a product that makes use of file assets cannot be provisioned since the parent stack with the aforementioned outputs does not exist in the end-user account.

To solve this, we could implement the usage of a bespoke S3 Bucket to contain asset files from assets used in a Service Catalog ProductStack. A bespoke bucket for this use case allows us to control the naming of the bucket as well as its permissions. Controlling the bucket name is important, especially at synth-time, since this will be referenced by resources that use assets, such as a Lambda function which references Python code stored in an asset file in the S3 bucket. Controlling permissions on a bucket which contains assets is important within the framework of Service Catalog since the administrator of a Service Catalog portfolio shares this portfolio across AWS accounts with end users who make use of products which reference asset files.

In order to implement this solution, we make use of S3 Deployments. S3 Deployments will essentially copy the assets from the bootstrap asset bucket to our own S3 Bucket enabling us to control the naming and permissions on the bucket.

Users can start using assets in their ProductStack without doing anything in which case a ProductStackAssetBucket (extends S3 Bucket) will be automatically generated for them for each ProductStack and named based on their accountId and region. Their assets will then be copied over to this bucket using S3 Deployment. The limitation here is that each ProductStack will generate its own Bucket.

Alternatively, we understand that creating a Bucket for each ProductStack may not be the ideal user experience but due to limitations we are unable to create them on a Portfolio level. As a workaround, we also allow users to define their own ProductStackAssetBucket and pass this property to their ProductStack. This will allow users to define a single bucket and use it for multiple ProductStacks. The only requirement is that user must define a bucketName for their bucket. This is required as we need the bucketName to be written to the template generated by the ProductStack.

Finally, when the user adds their ProductStack to a Product, the Product will become aware of the asset bucket(s). When they associate their Product to a Portfolio, the Portfolio will also become aware of the asset bucket(s). When they share their Portfolio with an end user account, the asset bucket(s) will grant read permissions to the end user account, so they will be able to access these assets when they provision their Product.

Draft PR:

A draft PR has already been made of this implementation here. They recommended me to go through the RFC process. https://github.com/aws/aws-cdk/pull/22143

Updated PR:

https://github.com/aws/aws-cdk/pull/22857

Roles

Role	User
Proposed by	@wanjacki
Author(s)	@wanjacki, @mackalex
API Bar Raiser	@corymhall
Stakeholders	@alias, @alias, @alias

See RFC Process for details

Workflow

• Tracking issue created (label: status/proposed)
• API bar raiser assigned (ping us at #aws-cdk-rfcs if needed)
• Kick off meeting
• RFC pull request submitted (label: status/review)
• Community reach out (via Slack and/or Twitter)
• API signed-off (label api-approved applied to pull request)
• Final comments period (label: status/final-comments-period)
• Approved and merged (label: status/approved)
• Execution plan submitted (label: status/planning)
• Plan approved and merged (label: status/implementing)
• Implementation complete (label: status/done)

---

Author is responsible to progress the RFC according to this checklist, and apply the relevant labels to this issue so that the RFC table in README gets updated.

[padaszewski]

As one of the voices of the community, I would like to say that many teams working with CDK + ServiceCatalog have been waiting for this feature for a long time. My team discovered ProductStack over a year ago, and it was a game changer for us, allowing us to move away from all sorts of copying CFN outputs + assets around. The lack of support for assets is a technical debt we are looking forward to resolve. On design considerations, we realize that these are topics for deeper discussion, but it’s also worth noting that ProductStack without asset provisioning capabilities misses the point in most cases, since every major application has at least some complex/large bundled lambdas. We would love to see this problem solved in the near future.

[wanjacki]

@corymhall @rix0rrr Any updates or other feedback on this PR? https://github.com/aws/aws-cdk-rfcs/issues/458