Aws cdk don't provide a way to create secrets with specified values

In the link below it’s specified in the docs that we can create secrets from a JSON file containing the values of the secrets.

aws secretsmanager create-secret --name MyTestDatabaseSecret \
    --description "My test database secret created with the CLI" \
    --secret-string file://mycreds.json

Unfortunately, I don’t find a way to do this with aws cdk. The create-secret method doesn’t accept values of the secrets themselves and code like below will autogenerate a secret.

    new secretsmanager.Secret(this, 'Secret', {
      description: 'secret description,
      secretName: 'secretName'
    });

Secrets manager docs from CLI: https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/create-secret.html#examples

AWS CDK secrets manager docs: https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-secretsmanager.Secret.html

[njlynch]

#9594 closed this issue, but then #9610 reverted it. I wanted to share the rationale on this issue for those that have been waiting for the functionality.

Supplying the secretString directly in the CDK exposes the secret in all of the CDK outputs (cdk.out and outputs of commands like cdk synth), in the CloudFormation template itself (visible in the console and via the SDK/CLI), and increases the risk of a secret being committed to source. Even with appropriate warnings in the documentation, the risk of accidental leakage was deemed too high by the team.

The preferred guidance is to use the AWS SDK/CLI/console to store these secrets, and then import them into you CDK app.

If you still want to achieve the same effect, you can always either use escape hatches or write your own construct.

// Escape hatch approach
const secret = new secretsmanager.Secret(stack, 'Secret');
const cfnSecret = secret.construct.defaultChild as secretsmanager.CfnSecret;
cfnSecret.generateSecretString = undefined;
cfnSecret.secretString = 'mynotverysecuresecret';

[njlynch]

Thanks everyone for continuing to 👍 and comment on this issue with your use cases. When we reverted the initial implementation, we were worried about the potential for accidentally leaking secrets when specifying the initial string value, and wanted to intentionally add a little friction to make it more likely a user doing it knew the consequences.

Given the feedback on this issue, I’m going to re-open.

One possible compromise that still addresses the original concerns would be to re-enable passing in a secretString, but require that the value was a Token. This means that creating a secret for an IAM user’s credentials (@bmVsc29u 's use case) or from the output of a custom resource (@richardhboyd 's example) would be supported, but just providing a hard-coded ‘p@ssw0rd’ would still require some degree of work-around.

I would love to get feedback on if the above solves (most) use cases, or if there’s still a strong need to hard-code an insecure plaintext string password.