-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(bootstrap): remove Security Hub finding KMS.2 #24588
Conversation
**NOTE:** This PR bumps the version of the bootstrap stack to `16`, but there is no need to update your bootstrap stacks, unless it is to get rid of the Security Hub finding; this change has no effect on the functionality of any CDK app deployed to the environment. [Security Hub finding KMS.2](https://docs.aws.amazon.com/securityhub/latest/userguide/kms-controls.html#kms-2) says: > The control fails if the policy is open enough to allow kms:Decrypt or kms:ReEncryptFrom actions on any arbitrary KMS key. > > [...] > > The control only checks KMS keys in the Resource element and doesn't take into account any conditionals in the Condition element of a policy. While are confident that this control is overly sensitive, and there is no actual security impact from the current configuration of the policy, customers are anxious about the Security Hub findings reported on resources we create. Therefore, we turn the `Resources: *` into a list of wildcard ARNs, one for each trusted account. This should satisify Security Hub without breaking the functionality of the bootstrap resources (as this statement is only used for cross-account CodePipeline deployments using CDK Pipelines). The CloudFormation expression we use to turn a list of account IDs into a list of ARNs is quite crazy. I would have used `${AWS::Region}` instead of allowing all regions, but `{ Fn::Join }` doesn't allow using intrinsics in its separator. I tested the new template using a CDK Pipeline that deploys in-region, cross-region, cross-account and cross-account-cross-region.
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 CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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). |
**NOTE:** This PR bumps the version of the bootstrap stack to `16`, but there is no need to update your bootstrap stacks, unless it is to get rid of the Security Hub finding; this change has no effect on the functionality of any CDK app deployed to the environment. [Security Hub finding KMS.2](https://docs.aws.amazon.com/securityhub/latest/userguide/kms-controls.html#kms-2) says: > The control fails if the policy is open enough to allow kms:Decrypt or kms:ReEncryptFrom actions on any arbitrary KMS key. > > [...] > > The control only checks KMS keys in the Resource element and doesn't take into account any conditionals in the Condition element of a policy. This control is a "defense in depth" control. It does not mitigate any attack by itself, and there is no actual security impact from the current configuration of our policies. However, customers are anxious about the Security Hub findings reported on resources we create for them. Therefore, we turn the `Resources: *` into a list of wildcard ARNs, one for each trusted account. This should satisify Security Hub without breaking the functionality of the bootstrap resources (as this statement is only used for cross-account CodePipeline deployments using CDK Pipelines). The CloudFormation expression we use to turn a list of account IDs into a list of ARNs is quite crazy. To turn `['1111', '2222', '3333']` into `['arn:aws:kms:*:1111:*', 'arn:aws:kms:*:2222:*', 'arn:aws:kms:*:3333:*']` we do the following: * Skip the entire statement if the list is empty * Use the following equivalence if the list has at least one element (E1 cannot be expressed in CloudFormation but E2 can): ``` (E1) xs.map(x => PREFIX + x + SUFFIX).join(SEP) <==> { assuming xs.length >= 1 } (E2) PREFIX + xs.join(SUFFIX + SEP + PREFIX) + SUFFIX ``` * Finally split the string on the separator to come up with an array of elements. I would have used `${AWS::Region}` instead of allowing all regions, but `{ Fn::Join }` doesn't allow using intrinsics in its separator. I tested the new template using a CDK Pipeline that deploys in-region, cross-region, cross-account and cross-account-cross-region. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…(revert security hub finding fix) (#25540) **NOTE**: This PR bumps the version of the bootstrap stack to 18, but there is no need to update your bootstrap stacks as this PR changes no functionality. We are reverting #24588 because it includes hardcoded partitions in the bootstrap causing the `p0` in #25272. Including intrinsics `${AWS::Partition}` here is impossible. In addition, #24588 was reported to not actually fix the Security Hub finding: #19380 (comment). Although this is a revert, I am rolling forward the bootstrap version to 18. reverts #24588. fixes #25272. see #25273 & #25507. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…(revert security hub finding fix) (#25540) **NOTE**: This PR bumps the version of the bootstrap stack to 18, but there is no need to update your bootstrap stacks as this PR changes no functionality. We are reverting #24588 because it includes hardcoded partitions in the bootstrap causing the `p0` in #25272. Including intrinsics `${AWS::Partition}` here is impossible. In addition, #24588 was reported to not actually fix the Security Hub finding: #19380 (comment). Although this is a revert, I am rolling forward the bootstrap version to 18. reverts #24588. fixes #25272. see #25273 & #25507. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
NOTE: This PR bumps the version of the bootstrap stack to
16
, but there is no need to update your bootstrap stacks, unless it is to get rid of the Security Hub finding; this change has no effect on the functionality of any CDK app deployed to the environment.Security Hub finding KMS.2 says:
This control is a "defense in depth" control. It does not mitigate any attack by itself, and there is no actual security impact from the current configuration of our policies. However, customers are anxious about the Security Hub findings reported on resources we create for them.
Therefore, we turn the
Resources: *
into a list of wildcard ARNs, one for each trusted account. This should satisify Security Hub without breaking the functionality of the bootstrap resources (as this statement is only used for cross-account CodePipeline deployments using CDK Pipelines).The CloudFormation expression we use to turn a list of account IDs into a list of ARNs is quite crazy. To turn
['1111', '2222', '3333']
into['arn:aws:kms:*:1111:*', 'arn:aws:kms:*:2222:*', 'arn:aws:kms:*:3333:*']
we do the following:I would have used
${AWS::Region}
instead of allowing all regions, but{ Fn::Join }
doesn't allow using intrinsics in its separator.I tested the new template using a CDK Pipeline that deploys in-region, cross-region, cross-account and cross-account-cross-region.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license