feat(cloudfront): mutual TLS #36245
feat(cloudfront): mutual TLS #36245
Conversation
github-actions
bot
added
the
distinguished-contributor
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
...framework-integ/test/aws-cloudfront/test/integ.distribution-mtls.assets/mtls-test-handler.ts
Fixed
Show fixed
Hide fixed
...4059581719d059fbdfc854912e8a27be60d7784f4bf89aae78071ca0219ecb40.assets/mtls-test-handler.js
Fixed
Show fixed
Hide fixed
...8fa19fb03891638e9070c4bee8ad539f11932b9cd7f884f6570b5622df2fc78c.assets/mtls-test-handler.js
Fixed
Show fixed
Hide fixed
aws-cdk-automation
added
pr/needs-further-review
aws-cdk-automation
removed
the
pr/needs-further-review
|
It might be better to avoid using NodejsFunction in integ test. |
mazyu36
left a comment
mazyu36
left a comment
There was a problem hiding this comment.
Thanks for the contribution. Before reviewing, let me confirm the implementation direction.
| }); | ||
|
|
||
| // Create TrustStore using L1 construct (CfnTrustStore) | ||
| const trustStore = new cloudfront.CfnTrustStore(this, 'TrustStore', { |
There was a problem hiding this comment.
Is there any reason why the trust store is not implemented as an L2 construct?
I don't think creating L2 constructs is mandatory, so if you have a reason, please let me know.
There was a problem hiding this comment.
Of course, I’m planning to implement it! My initial thought was to merge this PR first, then implement the L2 for truststore while deprecating truststoreId.
However, I’m starting to think it might not be ideal to implement an argument that will soon become obsolete. So it might be better to either implement the L2 first, or include it in this PR.
That said, including the L2 implementation might make this PR a bit too large. What are your thoughts on this?
There was a problem hiding this comment.
Thank you.
In my opinion, if you are going to deprecate the property after implementing L2, it would be better to implement L2 from the beginning. I don't think the trust store itself will be a very complex construct.
If you're not going to deprecate it, I think the current policy is fine.
There was a problem hiding this comment.
Sure! I'll add TruestStore L2 construct in this PR. Please wait for a while.
3 participants
Issue # (if applicable)
None
Reason for this change
AWS cloudfront now supports for mTLS authentication.
https://aws.amazon.com/jp/about-aws/whats-new/2025/11/amazon-cloudfront-mutual-tls-authentication/
Description of changes
L2 Construct Implementation
(distribution.ts)
MtlsModeenum withREQUIREDandOPTIONALvaluesViewerMtlsConfiginterface with flat structure:mode: mTLS enforcement modetrustStoreId: ID of the CloudFront TrustStoreadvertiseTrustStoreCaNames: Optional flag to advertise CA names during TLS handshakeignoreCertificateExpiry: Optional flag to accept expiredcertificatesviewerMtlsConfigproperty toDistributionPropsDescribe any new or updated permissions being added
None
Description of how you validated changes
added both unit and integ tests
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license