-
-
Notifications
You must be signed in to change notification settings - Fork 249
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
feat: add origin-shield #207
Conversation
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.
Bridgecrew has found infrastructure configuration errors in this PR ⬇️
@@ -390,6 +390,15 @@ resource "aws_cloudfront_distribution" "default" { | |||
origin_ssl_protocols = var.origin_ssl_protocols | |||
} | |||
} | |||
|
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.
Verify CloudFront Distribution Viewer Certificate is using TLS v1.2
Resource: aws_cloudfront_distribution.default | ID: BC_AWS_NETWORKING_63
Error in referred variable: locals "minimum_protocol_version" > variable "minimum_protocol_version"
How to Fix
resource "aws_cloudfront_distribution" "pass" {
...
viewer_certificate {
cloudfront_default_certificate = false
minimum_protocol_version = "TLSv1.2_2018"
}
}
Description
This policy identifies AWS CloudFront web distributions which are configured with TLS versions for HTTPS communication between viewers and CloudFront. As a best practice, use TLSv1.1_2016 or later as the minimum protocol version in your CloudFront distribution security policies@@ -390,6 +390,15 @@ resource "aws_cloudfront_distribution" "default" { | |||
origin_ssl_protocols = var.origin_ssl_protocols | |||
} | |||
} | |||
|
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.
Ensure CloudFront distribution has a strict security headers policy attached
Resource: aws_cloudfront_distribution.default | ID: BC_AWS_NETWORKING_65
…s-cloudfront-s3-cdn into feat/origin_shield
✅ Verified on my own stack that it works. The automated tests however will likely only work once #208 has been merged since the AWS Provider is now explicitly checking for a value to be set for |
This pull request is now in conflict. Could you fix it @syphernl? 🙏 |
/rebuild-readme |
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.
Change details
-
Error ID Change Path Resource BC_AWS_NETWORKING_63 Fixed /main.tf aws_cloudfront_distribution.default BC_AWS_NETWORKING_65 Fixed /main.tf aws_cloudfront_distribution.default
/test all |
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.
In general this LGTM, with the exception that I think that being able to set region = "auto"
and the map that comes alongside it is a little too "smart" for Terraform. This is more something that should happen on the provider side. I'd like someone else to weigh in. @osterman ?
It'd also be nice to get @Nuru 's opinion on the addition of an origin_shield
attribute to s3_origins
and custom_origins
, which is a breaking change.
main.tf
Outdated
# Origin Shield mapping configuration | ||
# See: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html | ||
origin_shield_region_mapping = { | ||
# Regions where Origin Shield is available | ||
us-east-2 = "us-east-2" # US East (Ohio) | ||
us-east-1 = "us-east-1" # US East (N. Virginia) | ||
us-west-2 = "us-west-2" # US West (Oregon) | ||
ap-south-1 = "ap-south-1" # Asia Pacific (Mumbai) | ||
ap-northeast-2 = "ap-northeast-2" # Asia Pacific (Seoul) | ||
ap-southeast-1 = "ap-southeast-1" # Asia Pacific (Singapore) | ||
ap-southeast-2 = "ap-southeast-2" # Asia Pacific (Sydney) | ||
ap-northeast-1 = "ap-northeast-1" # Asia Pacific (Tokyo) | ||
eu-central-1 = "eu-central-1" # Europe (Frankfurt) | ||
eu-west-1 = "eu-west-1" # Europe (Ireland) | ||
eu-west-2 = "eu-west-2" # Europe (London) | ||
sa-east-1 = "sa-east-1" # South America (São Paulo) | ||
|
||
# Regions where Origin Shield is NOT available (choose closest region) | ||
us-west-1 = "us-west-2" # US West (N. California) | ||
af-south-1 = "eu-west-1" # Africa (Cape Town) | ||
ap-east-1 = "ap-southeast-1" # Asia Pacific (Hong Kong) | ||
ca-central-1 = "us-east-1" # Canada (Central) | ||
eu-south-1 = "eu-central-1" # Europe (Milan) | ||
eu-west-3 = "eu-west-2" # Europe (Paris) | ||
eu-north-1 = "eu-west-2" # Europe (Stockholm) | ||
me-south-1 = "ap-south-1" # Middle East (Bahrain) | ||
} |
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.
See my other comment on this type of behaviour not having much precedent in our modules.
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.
No, we do similar things here: https://github.com/cloudposse/terraform-aws-utils/blob/master/main.tf
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.
ironically, I see we are using a local
for it too, but I think a var
would be more appropriate in this case.
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.
@osterman right, but I didn't think https://github.com/cloudposse/terraform-aws-utils/blob/master/main.tf of a proper example since it's a utility module specifically meant to map region short-hands and not a regular module. But anyways, if it's acceptable precedent in your view, then that helps.
origin_shield = object({ | ||
enabled = bool | ||
region = string | ||
}) |
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 sucks that we have to make such a complex object even more complex. It's a breaking change, but there really isn't any other logical place for it IMO.
If we didn't have to opt in it'd be cool (https://www.terraform.io/language/functions/defaults)
But it is what it is.
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 agree. Let's hope the defaults
function will soon move out of the experimental phase.
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.
@syphernl how much of a blocker is this for you? We're trying to keep breaking changes to a minimum, and yes, desperate for defaults
function to graduate from experimental.
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.
@osterman Our customers would like to have this implemented in their environment.
For the time being we could probably use our own fork/branch instead although from update-perspective that is not ideal.
origin_shield = object({ | ||
enabled = bool | ||
region = string | ||
}) |
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.
See comment on breaking change
@korenyoni I have changed the local into a var as @osterman suggested. |
/test all |
@korenyoni @Nuru Do you have any updates regarding this? Our project development is nearing completion and we'd like to enable the Origin Shield for this soon. |
At the moment it's in @Nuru 's hands. From @Nuru :
|
I implemented the non-breaking-change portion of this in #247 |
what
why
references