-
Notifications
You must be signed in to change notification settings - Fork 248
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
do not create cloudfront log bucket if disabled #303
do not create cloudfront log bucket if disabled #303
Conversation
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
are the AWS CodeBuild logs publicly viewable? If not @biffgaut could you please let me know what they say? |
22db0f3
to
a74e36c
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
a74e36c
to
d373bdc
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
d373bdc
to
43453cb
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
enableLogging: false, | ||
}); | ||
|
||
expect(stack).toHaveResourceLike("AWS::CloudFront::Distribution", { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not explicitly test for the absence of Logging
prop which would be better, is there a test checking for absence elsewhere in the codebase?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this command looks for an identical resource, so if a logging prop exists it will fail. What we are missing (and what would have prevented this issue) is a check that the logging bucket does not exist. You could add that with an expect(stack).not.toHaveResourceLike("AWS::S3::Bucket", { _define logging bucket here_ });
call if you're willing to add that...
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
56fbab8
to
2e194ce
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
0c958ba
to
6fae6e9
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
c878d60
to
5638074
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
5638074
to
e8c5ca0
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
e8c5ca0
to
03545cc
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
03545cc
to
a86d17a
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
You make an excellent point, I don't think we had considered that before. We will definitely update the docs, although I don't think making an account available is going to possible. Perhaps some way of generating the .expected files on our end during the pipeline. Hand editing can make them pass, we've had trouble in the past when hand edits masked the fact the the construct didn't launch - but we have new testing that launches all the constructs every night so that's no longer a concern. We need to do a better job overall of describing the steps involved in contributing - we're still pretty new and improving those steps, but it's definitely something on our (too long) todo list. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple questions within...
@@ -62,33 +62,18 @@ function defaultCloudfrontFunction(scope: cdk.Construct): cloudfront.Function { | |||
export function CloudFrontDistributionForApiGateway(scope: cdk.Construct, | |||
apiEndPoint: api.RestApi, | |||
cloudFrontDistributionProps?: cloudfront.DistributionProps | any, | |||
httpSecurityHeaders?: boolean): [cloudfront.Distribution, | |||
httpSecurityHeaders: boolean = true): [cloudfront.Distribution, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Big fan of this !
|
||
function getLoggingBucket(cloudFrontDistributionProps: cloudfront.DistributionProps | any, scope: cdk.Construct): s3.Bucket | undefined { | ||
return cloudFrontDistributionProps?.enableLogging !== false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Parsing this logic and comparing it to the original logic had me doing my homework on truthy, falsey and missing values...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hehe, sorry I should have probably explained it in more depth, though I had gotten engulfed with the snapshot updates
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's much easier to follow than the original code - my struggles were determining the behavior of the original code and comparing it to this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is where the extensive test suite pays off! :)
enableLogging: false, | ||
}); | ||
|
||
expect(stack).toHaveResourceLike("AWS::CloudFront::Distribution", { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this command looks for an identical resource, so if a logging prop exists it will fail. What we are missing (and what would have prevented this issue) is a check that the logging bucket does not exist. You could add that with an expect(stack).not.toHaveResourceLike("AWS::S3::Bucket", { _define logging bucket here_ });
call if you're willing to add that...
@@ -58,7 +58,7 @@ test('check bucket metadata', () => { | |||
rules_to_suppress: [ | |||
{ | |||
id: "W35", | |||
reason: "This S3 bucket is used as the access logging bucket for CloudFront Distribution" | |||
reason: "This S3 bucket is used as the access logging bucket for another bucket" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we want to do this. This is finding the logging bucket set up in buildS3Bucket(), which a resource by the test infrastructure and doesn't tell us anything about construct behavior. As I see it, logging should still be the default behavior, so there should still be a logging bucket with this suppression rule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch, I believe I got the getLoggingBucket()
logic wrong, fixing...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, the updated logic did not change the test result apparently. Could you elaborate as to whats going on here in terms of rules_to_suppress
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We run a tool called cfn_nag that looks for security concerns in cloudformation templates (in this case, it looks at test snapshots). It's an external tool that doesn't allow us to ignore specific rules in configuration so we need to add metadata to the CFN to remove false positives. There are 2 buckets in the construct, both with metadata suppressing W35 - one is test infrastructure ("...another bucket...") and another that is part of the construct ("...CloudFront distribution..."). So either statement should pass expect statement, but the latter is looking at the construct and evaluating what we are looking for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation! I changed it back, not sure why I had changed it in the first place, there has been many iterations as you know 😅
4e878c7
to
61ae0c8
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
e2115e6
to
bc25f6b
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Getting the following error which is unrelated AFAICT:
offending line was checked in 10 months ago: offending line is Line 123 in d96c11b
|
That's a tool we run internally on PRs that looks for patterns that indicate sensitive information being checked in. In this case it's a false positive around the fake account number. The .viperlightignore file is a list of all the false positives to ignore by filename and line number. Unfortunately that's a very brittle system for identifying the false positives, because even trivial code changes can change line numbers for an entire file. In this case the account number moved rom 123 to 124, so line 41 of .viperlightignore should be changed to :124 Not sure why the error message says look at line 125, everything I can see says the issue is on line 124. |
bc25f6b
to
640eda3
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
640eda3
to
b7484d4
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
This line comes after the viperlight tag, so at least it wont affect that. |
b7484d4
to
575bac0
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
also refactor cloudfront-distribution-defaults Signed-off-by: Naseem <naseem@toric.com>
575bac0
to
25262ab
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Naseem - quite a long journey, thanks for sticking with it and adding this improvement that will benefit lot of users! This will probably get pushed to the NPM repos within the next week. Because of the requirement that all versions must match, we're locked into releasing identical version numbers with the CDK. Since we can't get ahead of them we usually lag at least 1 version behind so if we have an emergency we can drop it right away. This requirement will ease with the coming release of CDK 2.0. |
Thanks for your patience and various explanations along the way @biffgaut! |
@biffgaut was this included in 1.118.0? |
Yes, it did. Somehow we didn't catch it for CHANGELOG.md - I will update CHANGELOG.md to reflect that. Thanks. |
naseemkullah@ If the commit message follows the conventionalcommits it will be automatically picked up by CHANGELOG.md |
*Issue #, if available: #302
Description of changes:
Avoid creating a cloudfront log bucket if cloudfront logging is disabled.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.