search

aws / aws-cdk

The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code
https://aws.amazon.com/cdk
Apache License 2.0
11.64k stars 3.91k forks source link

aws-cloudfront-origins: support for Secret in OriginOptions.customHeaders #20980

Open mauritz-lovgren opened 2 years ago

mauritz-lovgren commented 2 years ago

Describe the feature

It should be possible to use an aws-secretsmanager/Secret (or aws-cdk-lib/SecretValue) with aws-cloudfront-origins/OriginOptions.customHeaders attribute without the need to unwrap the secret, insecurely exposing it in the template.

Use Case

Providing a CDK generated secret to use between CloudFront distribution and Application Load Balancer, as recommended here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html

Proposed Solution

Add support for aws-secretsmanager/Secret like in aws-ecs/ContainerDefinitionOptions.secrets ( [key: string]: ecs.Secret ) (or using similar approach) in aws_cloudfront_origins/OriginOptions.customHeaders.

Other Information

Currently the aws_cloudfront_origins/OriginOptions.customHeaders attribute only supports a Record<string, string>, so, providing a aws-cdk-lib/SecretValue's value for a custom header forces one to use SecretValue.unsafeUnwrap().

Ideally, secrets should not be exposed in the CF template, but rather be dynamically looked up like with the ECS container secret value injection mechanism.

Acknowledgements

CDK version used

2.29.1

Environment details (OS name and version, etc.)

macOS Monterey and latest AWS CodeBuild AMIs

indrora commented 2 years ago

Does Cloudfront actively support using Secrets instead of hardcoded strings?

github-actions[bot] commented 2 years ago

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

mauritz-lovgren commented 2 years ago

Does Cloudfront actively support using Secrets instead of hardcoded strings?

No, CloudFront does not seem to support this. There are some examples using WAF with Lambda secret rotation (https://aws.amazon.com/blogs/security/how-to-enhance-amazon-cloudfront-origin-security-with-aws-waf-and-aws-secrets-manager), but the secret is still being exposed in CloudFront UI / API / CLI, so yes, might need to file an enhancement request to the CloudFront developers for CloudFront to be able to refer to header value as secret the way ECS does it, so we can use the same technique in the CDK.