Reputation: 596
I know that the recommendation from AWS to avoid creating secrets and setting the secret value in CDK, for example:
const secret = this.createSecret('MySecret', {
username: new cdk.CfnParameter(this, 'username', { noEcho: true }).valueAsString,
password: new cdk.CfnParameter(this, 'password', { noEcho: true }).valueAsString
})
However, as long as the parameter is provided securely in the deployment pipeline, for example in bitbucket pipelines (with secure repository variables):
cdk --parameters username=$USERNAME --parameters password=$PASSWORD
I can't see how this would be insecure? The actual username and password values never appear in the CDK synth output (cdk.out dir) or in any CloudFormation templates, therefore not accidentally committable to Git or visible via the CloudFormation console/cli; and the parameters specified are 'NoEcho' and therefore also not visible via the CloudFormation console/cli.
A common complaint I hear about CDK is that Secrets cannot be completely setup and configured in the CDK, the usual process is to create the secret in CDK and then manually go and configure the secret values, however, this goes against the spirit of Infrastructure as Code, and can be a royal pain when you have stack deployed in many regions/accounts.
Can someone please help me understand why this is not recommended and what might be insecure about it?
Upvotes: 1
Views: 1352
Reputation: 2136
With the method you have provided, where the secret value is provided at the change-set level as a Parameter, there isn't anything exposed and it's generally fine.
However, using CfnParameters is generally frowned upon, because it means all of the information (inputs) are not known at synthesis-time, which means it's incomplete. If you were to move these secret values into the CDK code directly then they'd be stored in the CloudFormation templates as plain-text which is also bad.
For values that are non-sensitive configuration values (lots of secrets are just things like api endpoints which are application configuration but not truly sensitive) you can use things like the 'unsafe' helpers (https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_secretsmanager-readme.html#creating-json-secrets).
If you have values that are truly sensitive then the management of the value is often preferred outside of IaC because doing a change-set (deployment) to update the value is often troublesome and heavy-handed.
Upvotes: 1