CloudFront Function: Secret/Config management

[ChristopheBougere]

I'm following this post for securing content with CloudFront Function.

The major drawback to me is the need to write the secret in the CloudFront Function code, and thus committed in the repository. It also makes it more complicated to use different values for each environment.

I know CloudFront Function don't have environment variables, and cannot do network call, so I'm trying to find a workaround and was thinking about this:

1. We could store secrets in our CDK context (in the cdk.json file that doesn't need to be committed)
2. In addition to the filePath option of the FunctionCode.fromFile() method, we could add a dictionary of placeholders to replace
3. CDK would then replace the placeholders by the secrets coming from the context. It would still be in plain text in the Function code, but at least it wouldn't be in plain text in the code repository.

Here is a quick snippet (not tested):

import * as fs from 'fs';
import { aws_cloudfront } from 'aws-cdk-lib';

export interface FileCodeWithPlaceholdersOptions {
  readonly filePath: string;
  readonly placeholders?: Record<string, string>;
}

export class FileCodeWithPlaceholders extends aws_cloudfront.FunctionCode {

  constructor(private options: FileCodeWithPlaceholdersOptions) {
    super();
  }

  public render(): string {
    const code = fs.readFileSync(this.options.filePath, { encoding: 'utf-8' });
    for (const [key, value] of Object.entries(this.options.placeholders)) {
      code.replace(key, value);
    }
    return code;
  }
}

What do you think?

[hoegertn]

Some opinions and questions from my side:

• The cdk.json and cdk.context.json should also be committed to the repo for determinism
• Where would it come from if not committed to the repo? It needs to be there in your pipeline.
• Can't you modify the source file in your pipeline before running cdk synth and call eg SecretsManager to load secrets?

[ChristopheBougere]

Thanks for your answer.

• The cdk.json and cdk.context.json should also be committed to the repo for determinism
• Where would it come from if not committed to the repo? It needs to be there in your pipeline.

Well, they could be loaded by a CI/CD from a unique source, other than the repo. But I agree that they might not be the best place for this purpose. But storing secrets in the repo in the code of the CloudFront Function isn't neither.

Can't you modify the source file in your pipeline before running cdk synth and call eg SecretsManager to load secrets?

Well, I'd like it to be as much automated as possible, and as much as possible directly handled by the CDK framework.

• So maybe the FileCodeWithPlaceholders could take secret names instead of cdk context keys?
• Do you think it would make sense to add this to the CloudFront.Function construct directly?

[indrora]

As was stated in the article you linked, the best practice for this is to use a Secrets Manager/KMS managed key that is retrieved by the lambda at runtime (as you are allowed to make calls to the AWS SDK) in order to keep from keeping your secrets in your CDK code -- only the references to your keys are there, not the keys themselves.

[padamopoulou]

Are you allowed to make calls to the AWS SDK in CloudFront Functions though?