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

[aakrem]

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

[richardhboyd]

+1 to this. I had to drop down to the L1 Construct to create a Secret with a specific value (i.e. a Lambda CR that creates an EC2 KeyPair, then put the SecretKey into SecretsManager via cfn)

[Cloudrage]

+1 too to create a SecretString in addition of the generateSecretString Props.

[ilkomiliev]

+1

[trusanen-bpg]

+1

[richardhboyd]

please don't add comments with just "+1". Use the 👍 on the original issue so that we can better track the number of users who want this and it keeps the comment section clean for discussion of the issue.

[gadams999]

+1 (yes, I did 👍 the main ask too :)). For Greengrass we have the need to send secrets locally to the secrets manager services, and based on the edge use-case, need to provide specific values and not randomly generated ones.

[bmVsc29u]

we need this for the scenario:

• generate accessKey per user
• store in somewhere secret, i.e. the secrets manager
• access it in the code build containerized environment

hence, either cloudformation provide a way to inject secrets directly to secrets manager, or allow secrets manager to store access secret key via AccessKey's property would be accepted. But I am worry about the secrets may leave some foot prints through the secretString way.

[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';

[skyrpex]

Libraries like react use abnormally long property names for properties that are insecure, like dangerouslySetInnerHTML. Maybe it would be a good idea to do something similar, if it's that dangerous.

[ThomasSteinbach]

The decision just to revert the ability to provide a secret string on secret creation is quite unsatisfying.

First the decision is not documented. It took me a while to get to the reasoning here, after I read the CDK API documentation, the CDK code and searching the open and closed issues. I was short before creating a feature request.

Furthermore the documentation explicitly says to use the aws_secretsmanager to store secret strings in AWS:

Parameters of type SecretString cannot be created directly from a CDK application; if you want to provision secrets automatically, use Secrets Manager Secrets (see the @aws-cdk/aws-secretsmanager package).

https://docs.aws.amazon.com/cdk/api/latest/docs/aws-ssm-readme.html#creating-new-ssm-parameters-in-your-cdk-app

So currently there seems no viable solution to store a secret string in AWS with CDK.

Instead of reverting the feature, wouldn't it be possible to implement another feature which let CDK hide sensitive content?

[njlynch]

So currently there seems no viable solution to store a secret string in AWS with CDK.

As stated in https://github.com/aws/aws-cdk/issues/5810#issuecomment-672736662, there is an option (using escape hatches); we intentionally want to keep some friction here given the potentially dangerous consequences of this approach. The other approach is to use the Secrets Manager via the console, SDK, or CLI to store the secret, then import the secret using the CDK.

[trusanen-bpg]

As stated in #5810 (comment), there is an option (using escape hatches); we intentionally want to keep some friction here given the potentially dangerous consequences of this approach. The other approach is to use the Secrets Manager via the console, SDK, or CLI to store the secret, then import the secret using the CDK.

There is still a valid need for this feature in the Secret-construct, even though there are potential security issues as well.

Suppose the following use-case: One would like to provision an RDS instance from a snapshot that includes a master user with some specific initial password. The master user credentials need to be passed automatically to some service that accesses the database.

A secure system can be achieved by utilizing secret rotation, but it would still require passing the initial password in CDK. Currently this can be done with escape hatches like you mentioned, but it's not very pretty or convenient. This could be a feature of SecretRotation as well.

[Cloudrage]

So currently there seems no viable solution to store a secret string in AWS with CDK.

As stated in #5810 (comment), there is an option (using escape hatches); we intentionally want to keep some friction here given the potentially dangerous consequences of this approach. The other approach is to use the Secrets Manager via the console, SDK, or CLI to store the secret, then import the secret using the CDK.

Not agree with that, in my case, I often use Secrets Manager to store multiple key/value for 1 use-case, don't want to create xxx SSM Parameter Store (like I do few years ago before SecretsManager was released).
In fact, I prefere store values in one "vault" instead of creating a lot of parameters.

For example, a "secret" with vpc keys (yeah, it's not possible with CDK to retreieve PrivateSubnets #9891 for example); so I've create 1 secret with @ll informations about my vpc/subnets (cidr, IDs...).
Another example with SMTP Secrets, store values like endpoint/port/user/domain but don't want to generate a string for the pwd, it's added by a CustomResource.
Same for a KeyPair.

So, in my code I have to always put a parameter like : generateStringKey: 'WaitingForSecretStringPropsInCDK'
Because I don't want to generate a string.

[cmwd]

Using ECS with a private repository is another example when this would be useful. The ContainerImage.fromRegistry method requires a Secret instance and this makes it hard to provide an authentication token.