feat: disallow cross account asset publishing in some scenarios

[iliapolo]

Issue # (if applicable)

Closes #.

Reason for this change

Description of changes

Description of how you validated changes

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

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[iliapolo]

For whoever ends up picking this PR up: hopefully there are just a couple of methods to implements:

aws-cdk/packages/aws-cdk/lib/api/deployments.ts

Lines 676 to 680 in 3a930fb

	private stagingBucketInToolkitStack(): boolean {
	// determine if the staging bucket exists in the
	// bootstrap stack (user might have removed it in case of a custom bootstrap template)
	throw new Error('TODO');
	}

aws-cdk/packages/aws-cdk/lib/api/deployments.ts

Lines 682 to 685 in 3a930fb

	private bootstrapVersion(): number {
	// grab the current bootstrap stack version from the customer account
	throw new Error('TODO');
	}

[HBobertz]

This was automatically done as part of the build 🤷‍♂️

[rix0rrr]

Use the logical ID of the resource (DescribeStackResources).

[rix0rrr]

This performs a lookupToolkit, which returns ToolkitInfo, which has most of the information already.

Why can't the logic live there?

[HBobertz]

I actually tried that first, but it started getting a bit ugly because that's an abstract class and we have a "we don't exist yet" version of that class, which kept breaking tests and was difficult to mock properly. So I just said screw it and refactored the change into functional util, which was much easier to test and mock.

[HBobertz]

Due to the nature of the change this is essentially not integ-testable so we will not be adding an integ test for this. Added pr-linter/exempt-test flag

[HBobertz]

Recreated the vulnerability. Got this exception when my bootstrap version is less than 21:

TempAppStack: fail: ❗❗ UNEXPECTED BUCKET OWNER DETECTED ❗❗ 
        
              We've detected that the S3 bucket cdk-hnb659fds-assets-446584840139-us-east-1 was 
              originally created in account 446584840139 as part of the CloudFormation stack CDKToolkit, 
              but now resides in a different AWS account. To prevent cross-account asset bucket access of your 
              deployments, CDK will stop now.

              If this situation is intentional and you own the AWS account that the bucket has moved to, remove the 
              resource named StagingBucket from the template of CloudFormation stack CDKToolkit and try again. 
              
              If this situation is not intentional, we strongly recommend auditing your account to make sure all 
              resources are configured the way you expect them [1]. For questions or concerns, please contact 
              AWS Support [2]. 
              
              [1] https://repost.aws/knowledge-center/potential-account-compromise
              
              [2] https://aws.amazon.com/support

And no such failure when our bootstrap version has been updated

This deployment will make potentially sensitive changes according to your current security approval level (--require-approval broadening).
Please confirm you intend to make the following modifications:

IAM Statement Changes
┌───┬─────────────────────────────────┬────────┬────────────────┬──────────────────────────────┬───────────┐
│   │ Resource                        │ Effect │ Action         │ Principal                    │ Condition │
├───┼─────────────────────────────────┼────────┼────────────────┼──────────────────────────────┼───────────┤
│ + │ ${rootFunction/ServiceRole.Arn} │ Allow  │ sts:AssumeRole │ Service:lambda.amazonaws.com │           │
└───┴─────────────────────────────────┴────────┴────────────────┴──────────────────────────────┴───────────┘
IAM Policy Changes
┌───┬─────────────────────────────┬────────────────────────────────────────────────────────────────────────────────┐
│   │ Resource                    │ Managed Policy ARN                                                             │
├───┼─────────────────────────────┼────────────────────────────────────────────────────────────────────────────────┤
│ + │ ${rootFunction/ServiceRole} │ arn:${AWS::Partition}:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole │

Which is the intended functionality

[aws-cdk-automation]

➡️ PR build request submitted to test-main-pipeline ⬅️

A maintainer must now check the pipeline and add the pr-linter/cli-integ-tested label once the pipeline succeeds.

[HBobertz]

I also added readme change since this isn't really a feat, more like a security fix but I'm keeping what eli designated the pr as. If we want readme changes feel free to request changes or remove the flag

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 3952ee5
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.