Skip to content
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(cli): assets are KMS-encrypted using wrong key #18340

Merged
merged 4 commits into from
Jan 10, 2022

Conversation

rix0rrr
Copy link
Contributor

@rix0rrr rix0rrr commented Jan 10, 2022

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 #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.
@rix0rrr rix0rrr requested a review from a team January 10, 2022 10:20
@rix0rrr rix0rrr self-assigned this Jan 10, 2022
@gitpod-io
Copy link

gitpod-io bot commented Jan 10, 2022

@github-actions github-actions bot added the package/tools Related to AWS CDK Tools or CLI label Jan 10, 2022
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Jan 10, 2022
@mergify
Copy link
Contributor

mergify bot commented Jan 10, 2022

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

Comment on lines +133 to +139
type BucketEncryption =
| { readonly type: 'no_encryption' }
| { readonly type: 'aes256' }
| { readonly type: 'kms'; readonly kmsKeyId?: string }
| { readonly type: 'access_denied' }
| { readonly type: 'does_not_exist' }
;
Copy link
Contributor

@RomainMuller RomainMuller Jan 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kinda sorta wonder why you didn't go and turn the type field into a constant... To keep compile-time referential checks in place?

Although I guess the TypeScript type checker still achieves the same outcome with this declaration.

@rix0rrr
Copy link
Contributor Author

rix0rrr commented Jan 10, 2022

Fun times

Get "https://public.ecr.aws/v2/": Get "https://public.ecr.aws/token/?account=AWS&client_id=docker&offline_token=true&service=public.ecr.aws": net/http: TLS handshake timeout

@rix0rrr
Copy link
Contributor Author

rix0rrr commented Jan 10, 2022

Choo choo all aboard the merge train

@rix0rrr rix0rrr changed the title fix(cli): assets are KMS-encrypted using default key fix(cli): assets are KMS-encrypted using wrong key Jan 10, 2022
@mergify
Copy link
Contributor

mergify bot commented Jan 10, 2022

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

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
  • Commit ID: c8b3a08
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

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

@mergify mergify bot merged commit 64ae9f3 into master Jan 10, 2022
@mergify mergify bot deleted the huijbers/cli-asset-upload branch January 10, 2022 16:04
@mergify
Copy link
Contributor

mergify bot commented Jan 10, 2022

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

TikiTDO pushed a commit to TikiTDO/aws-cdk that referenced this pull request Feb 21, 2022
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*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS. package/tools Related to AWS CDK Tools or CLI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

(assets): S3 asset publishing does not use the specified KMS Key
3 participants