CODEWITHSUNDEEP
aws-cloudformationaws-cdk
froi
froi

Reputation: 7788

Why is it recommended to manually provision pre-existing secrets in AWS SecretsManager as opposed via CDK/Cloudformation?

Quote from the aws cdk docs:

If you need to use a pre-existing secret, the recommended way is to manually provision the secret in AWS SecretsManager and use the Secret.fromSecretArn or Secret.fromSecretAttributes method to make it available in your CDK Application

Why is that? Is it because it's not ideal to save the plain text secret into code?

Or we don't want the secret to appear in the cloudformation template?

Upvotes: 3

Views: 3083

Answers (1)

fedonev
fedonev

Reputation: 25739

Yes and yes. Earlier CDK versions did not even permit passing text values to the Secret constructor. We only recently got the secretStringBeta1: string prop along with a stern warning:

It is highly encouraged to leave this field undefined and allow SecretsManager to create the secret value. The secret string -- if provided -- will be included in the output of the cdk as part of synthesis, and will appear in the CloudFormation template in the console. This can be secure(-ish) if that value is merely reference to another resource (or one of its attributes), but if the value is a plaintext string, it will be visible to anyone with access to the CloudFormation template (via the AWS Console, SDKs, or CLI).

Our CDK code and generated templates are meant to be deterministic and version-controlled, further heightening the risk of leakage if plaintext secrets are used.

Edit: Per @gshpychka's comment, a safe alternative to importing with Secret.fromSecretArn is to construct a new Secret without a secret value. This creates a secret with a random password, which you change post-deploy in the Console. This approach helpfully ties the secret's lifecycle to the Stack and lets you set its properties in the context of the Stack.

Upvotes: 3

Related Questions