feat(cloudfront): use TLS_V1_2_2021 SecurityPolicy as default version (under feature flag)

[SvenKirschbaum]

This pull request adds the new TLSv1.2_2021 security policy to the respective enum and adds the feature flag @aws-cdk/aws-cloudfront:defaultSecurityPolicyTLSv1.2_2021, which, when enabled, causes distributions to use the new security policy by default.

---

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

[gitpod-io]

[njlynch]

Thanks for the contribution, @fallobst22 !

Adding the new security policy is great; however, we can't change the default value for an existing construct. Existing users may rely on the behavior of TLSv1.2_2019 (e.g., use ECDHE-RSA-AES128-SHA256) and may break when upgrading. Unlikely, but possible.

We can suggest people use TLSv1.2_2021, but can't enforce it on existing customers. The standard way to do this would be to use a feature flag to allow users to opt-in to the new default.

I would be happy for this just to be adding the new enum value, and tackle the feature flag / new default later. If you'd like to tackle it now though, that's fine as well.

Pull request has been modified.

[SvenKirschbaum]

Thanks for taking a look @njlynch

I have chosen to add a feature flag for the new default value as requested.
For the tests I decided to hardcode the security policy in the exhaustive props test, and split the ViewerCertificate tests into two, for the new and old default.

Please take a look again and tell me if you would like anything changed.

[njlynch]

Looks great, thanks for the extra effort!

[SvenKirschbaum]

Your change was missing a semicolon, which broke the linter.
I added it, but you will have to approve again.

[njlynch]

Thanks for fixing my mistake! :D

[SvenKirschbaum]

It looks to me like the pr linter disallows pull requests with a breaking changes section for stable modules, without checking if they are under a feature flag. However the Feature Flags section inside CONTRIBUTING.md explicitly states, that the breaking changes part should be included, so merging this is impossible without violating one of the two requirements.

In my eyes perhaps the linter should be adapted to check for the feature flag mark in the title, and allow the breaking changes in this case.

Would be great if you could take a look again @njlynch

[njlynch]

I've reviewed this with my colleagues, and we agreed to just remove the BREAKING CHANGES notice, as it's not really a breaking change for existing customers.

[mergify]

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]

AWS CodeBuild CI Report

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

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

[mergify]

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