-
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
[cli] Enable logging for the cdktoolkit-stagingbucket #9294
Comments
related to #9256 - as suggested by @rix0rrr we're pursuing based on this comment:
I'm in favour of this approach as the feedback around having to keep adding flags to deliver functionality is something that can quickly grow out of control. It also becomes more challenging to debug and triage every time we add new flags to deliver functionality. @ddneilson does this approach still meet your requirements? any thoughts/feedback/concerns? |
marking issue as |
How is this progressing @shivlaks - I am in need of this so is there anything I can do to assist ? |
This is not being actively worked on, the current recommended way to achieve this is to customize the bootstrap stack, explained here: https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html#bootstrapping-customizing |
This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled. |
It has been identified during a security audit that the
cdktoolkit-stagingbucket
that is created by CDK bootstrap does not have logging enabled. The request is to enhance the bootstrap so that it can include deployment of a logging bucket.Use Case
Security -- "Inadequate log information could negatively impact forensics investigations, preventing engineers from appropriately root causing incidents."
This is particularly important, in my opinion, because the zip files that contain Lambda code are, by default, staged in the CDK staging bucket when using an Asset to deploy -- as many of the CDK constructs do. If those assets were modified in the staging bucket by an attacker, then there would be no way to perform an investigation on how/when that happened without S3 access logging.
Proposed Solution
Enable either:
Storing logs is not free, so there should be some consideration for making the logging optional (default: enabled), or providing a lifecycle rule that will expire logs older than some period.
Other
N/A
This is a 🚀 Feature Request
The text was updated successfully, but these errors were encountered: