-
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
(assets): S3 asset publishing does not use the specified KMS Key #18262
Comments
@rix0rrr I assume you'll want to take a look at this one. |
I had trouble reproducing this, but you are indeed correct. This must be because of #17668, where the putObject call has been turned from:
into
I'm guessing the inclusion of Though Arlind assured me he had tested it. More investigation is necessary. |
Trace:
|
Suspicion confirmed. With a locally fixed version of the CLI that includes the key ID it works:
|
Even though a custom KMS key is specified as the default encryption key on the file assets bucket, all uploaded assets are encrypted using the default key. The reason is that in #17668 we added an explicit `encryption: kms` parameter to the `putObject` operation, so that an SCP that is commonly in use across large organizations to prevent files from ending up unencrypted, can be used (the SCP can only validate call parameters, such as whether the `putObject` call includes the parameter that reuests encryption, not the effective end result, such as whether a file would end up encrypted). However, we did not include the KMS Key Id into the `putObject` request, which caused S3 to fall back to the default key. Solution: also look up the key id and pass that along as well. Fixes #18262.
Even though a custom KMS key is specified as the default encryption key on the file assets bucket, all uploaded assets are encrypted using the default key. The reason is that in #17668 we added an explicit `encryption: kms` parameter to the `putObject` operation, so that an SCP that is commonly in use across large organizations to prevent files from ending up unencrypted, can be used (the SCP can only validate call parameters, such as whether the `putObject` call includes the parameter that reuests encryption, not the effective end result, such as whether a file would end up encrypted). However, we did not include the KMS Key Id into the `putObject` request, which caused S3 to fall back to the default key. Solution: also look up the key id and pass that along as well. Fixes #18262. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Even though a custom KMS key is specified as the default encryption key on the file assets bucket, all uploaded assets are encrypted using the default key. The reason is that in aws#17668 we added an explicit `encryption: kms` parameter to the `putObject` operation, so that an SCP that is commonly in use across large organizations to prevent files from ending up unencrypted, can be used (the SCP can only validate call parameters, such as whether the `putObject` call includes the parameter that reuests encryption, not the effective end result, such as whether a file would end up encrypted). However, we did not include the KMS Key Id into the `putObject` request, which caused S3 to fall back to the default key. Solution: also look up the key id and pass that along as well. Fixes aws#18262. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
What is the problem?
When publishing assets to the assets bucket, the files are not encrypted using the same KMS key as the default encryption method of the bucket. If the buckets' default encryption is set to KMS with a Customer Managed key, the objects will be encrypted with the AWS Managed key. This will make it impossible to shared the objects with the rest of the Organizational accounts. In this case it is not possible to deploy a stackset with assets.
Reproduction Steps
Create the bootstrapping stack with a KMS key:
cdk bootstrap --bootstrap-kms-key-id '' aws:///
This will create a bucket that uses a new Customer Managed key as default encryption (not AWS_MANAGED_KEY)
Create a cdk app with assets and synthesize the app.
Publish assets:
cdk-assets publish --path cdk.out/-.assets.json
What did you expect to happen?
The objects should be encrypted with the Customer managed key.
What actually happened?
The object are encrypted with the AWS Managed KMS Key
CDK CLI Version
2.3.0
Framework Version
No response
Node.js Version
16
OS
Mac
Language
Typescript
Language Version
No response
Other information
I think the behaviour changed with the following change:
8191f1f#diff-1f59ad129e9c6ce901748465a75693927875be1babb51d0f0871530c31678842
If I remove the s3:GetEncryptionConfiguration permissions, objects will be uploaded using the proper default encryption method (without the encryption header).
The text was updated successfully, but these errors were encountered: