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(s3): buckets with SSE-KMS silently fail to receive logs #23385

Merged
merged 2 commits into from
Dec 22, 2022

Conversation

laurelmay
Copy link
Contributor

AWS S3 Server Access Logging does not support logging to buckets that
use SSE-KMS, only to buckets without default encryption or to buckets
that use SSE-S3. At least in some cases, this misconfiguration can be
caught within the CDK (when logging to the same bucket or when the
target bucket is using a KMS CMK).

This will still fail to catch scenarios where the target bucket is using
SSE-KMS using a KMS-managed key because the encryptionKey property is
not set on the Bucket in that scenario.

This may be a breaking change for some users; what is currently a mostly
silent misconfiguration will become an error when synthesizing.


All Submissions:

Adding new Construct Runtime Dependencies:

  • This PR adds new construct runtime dependencies following the process described here

New Features

  • Have you added the new feature to an integration test?
    • Did you use yarn integ to deploy the infrastructure and generate the snapshot (i.e. yarn integ without --dry-run)?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

AWS S3 Server Access Logging does not support logging to buckets that
use SSE-KMS, only to buckets without default encryption or to buckets
that use SSE-S3. At least in some cases, this misconfiguration can be
caught within the CDK (when logging to the same bucket or when the
target bucket is using a KMS CMK).

This will still fail to catch scenarios where the target bucket is using
SSE-KMS using a KMS-managed key because the `encryptionKey` property is
not set on the Bucket in that scenario.

This may be a breaking change for some users; what is currently a mostly
silent misconfiguration will become an error when synthesizing.
@gitpod-io
Copy link

gitpod-io bot commented Dec 18, 2022

@aws-cdk-automation aws-cdk-automation requested a review from a team December 18, 2022 16:41
@github-actions github-actions bot added p2 admired-contributor [Pilot] contributed between 13-24 PRs to the CDK labels Dec 18, 2022
Copy link
Collaborator

@aws-cdk-automation aws-cdk-automation left a comment

Choose a reason for hiding this comment

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

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.

@laurelmay
Copy link
Contributor Author

Fixes must contain a change to an integration test file and the resulting snapshot

I don't know of any situations where there's currently an integration test for expected failures; I am happy to write one if there's an example to follow

@TheRealAmazonKendra TheRealAmazonKendra added the pr-linter/exempt-integ-test The PR linter will not require integ test changes label Dec 20, 2022
@aws-cdk-automation aws-cdk-automation dismissed their stale review December 20, 2022 03:40

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

Copy link
Contributor

@comcalvi comcalvi left a comment

Choose a reason for hiding this comment

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

Thanks for the fix!

@mergify
Copy link
Contributor

mergify bot commented Dec 21, 2022

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
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: ace683d
  • 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 1b7a384 into aws:main Dec 22, 2022
@mergify
Copy link
Contributor

mergify bot commented Dec 22, 2022

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).

brennanho pushed a commit to brennanho/aws-cdk that referenced this pull request Jan 20, 2023
AWS S3 Server Access Logging does not support logging to buckets that
use SSE-KMS, only to buckets without default encryption or to buckets
that use SSE-S3. At least in some cases, this misconfiguration can be
caught within the CDK (when logging to the same bucket or when the
target bucket is using a KMS CMK).

This will still fail to catch scenarios where the target bucket is using
SSE-KMS using a KMS-managed key because the `encryptionKey` property is
not set on the Bucket in that scenario.

This may be a breaking change for some users; what is currently a mostly
silent misconfiguration will become an error when synthesizing.

----

### All Submissions:

* [X] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md)

### Adding new Construct Runtime Dependencies:

* [ ] This PR adds new construct runtime dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-construct-runtime-dependencies)

### New Features

* [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)?
	* [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)?

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
brennanho pushed a commit to brennanho/aws-cdk that referenced this pull request Feb 22, 2023
AWS S3 Server Access Logging does not support logging to buckets that
use SSE-KMS, only to buckets without default encryption or to buckets
that use SSE-S3. At least in some cases, this misconfiguration can be
caught within the CDK (when logging to the same bucket or when the
target bucket is using a KMS CMK).

This will still fail to catch scenarios where the target bucket is using
SSE-KMS using a KMS-managed key because the `encryptionKey` property is
not set on the Bucket in that scenario.

This may be a breaking change for some users; what is currently a mostly
silent misconfiguration will become an error when synthesizing.

----

### All Submissions:

* [X] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md)

### Adding new Construct Runtime Dependencies:

* [ ] This PR adds new construct runtime dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-construct-runtime-dependencies)

### New Features

* [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)?
	* [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)?

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
mergify bot pushed a commit that referenced this pull request May 24, 2023
…uckets (#25350)

The previous changes(#23514 & #23385) about failing early when certain encryption type being used is not correct. In fact, KMS encryption works fine for server access logging target buckets with proper permission being setup.

So this change is removing the condition failing for the SSE-KMS with customized encryption key case.

However, it is not possible to know which encryption type for the server access logging bucket, so the only checking can be applied after this change merged is failing when logging to self case using BucketEncryption.KMS_MANAGED.

After this fix, the only condition would be failed pre-checking is __Log to self and using KMS_MANAGED encryption type__

This change only fix the checking condition, so this change won't affect snapshot at all. Hence, Exemption Request.

----

*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
admired-contributor [Pilot] contributed between 13-24 PRs to the CDK p2 pr-linter/exempt-integ-test The PR linter will not require integ test changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants