aws-secretsmanager: secret string regenerated when non-generated values change

[maxhayward]

Describe the bug

Apologies if deemed a feature request rather than a bug.

Creating a new Secret, with the generateSecretString prop, successfully generates the string. But if I make a change to any of the non-generated items in secretStringTemplate section, the secret is regenerated.

Expected Behavior

Changing the value of a non-generated key in the secret JSON (such as hostname or port) should not regenerate the generated value. Or at least there should be an option to specify whether we want the generated value to be regenerated at such a change.

Current Behavior

The password is regenerated.

Reproduction Steps

First, generate a secret using the following.

    new Secret(this.parent, "mysecret", {
        secretName: "secretName",
        generateSecretString: {
            secretStringTemplate: JSON.stringify({
              address: "address1",
              database: "database",
              port: "1234",
              username: "userName",
            }),
            generateStringKey: "password",
            excludePunctuation: true,
            includeSpace: false,
            excludeCharacters: "'\\/",
        }
    }

Then, change the address field to "address2" and deploy.

Possible Solution

Additional option in SecretStringGenerator to specify whether we want the generated value to be regenerated at change-time.

Additional Information/Context

No response

CDK CLI Version

2.20.0

Framework Version

No response

Node.js Version

16.14.2

OS

MacOS / Amazon Linux

Language

Typescript

Language Version

No response

Other information

No response

[skinny85]

Hey @maxhayward,

thanks for opening the issue. Unfortunately, I believe this behavior is due to how the SecretsManager service is designed, and there's not much that CDK can do to change that.

Out of curiosity, why does re-generating the secret doesn't make sense to you, if you change the template? That makes perfect sense to me - the previous value might be invalid with the current template, after all!

Thanks, Adam

[github-actions[bot]]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[MarcFletcher]

Many thanks for investigating. At the point a secret is re-generated it may already have been used to instantiate downstream use cases. This makes it very high risk if it happens unexpectedly. For example process being:

• Generate new random secret.
• Then use that secret to instantiate database users.

If the secret is reset that won't change the database users and potentially now you can't login to the DB.

If there is no easy way to ensure the value of a secret is not changed, due to SecretsManager implementation, perhaps CDK should throw an exception if the value of a secret will be changed. Similar to how termination protection blocks CDK from continuing if something will result in a resource being unexpectedly destroyed.

Kind regards.

[skinny85]

@MarcFletcher makes sense. I'm turning this one into a feature request then.

[sammcj]

Really keen to see this fixed, we've had our secrets blown away several times because of this.

[sammcj]

Just wondering if there's any update on this? Had more outages due to this.

[ivandjomegni]

Looking forward to have this feature implemented as well. There is this use case where I generate an API Key value using secret manager, and use that secret as the value for my API Key so it can be found in secret store. However, if I rerun my CDK build and the secret is regenerated, then the value of the key doesn't match anymore.

[csbrown]

Does anyone have a workaround for this? I don't want to have my secrets end up in Cloudformation plaintext with secretObjectValue, but this behavior is not acceptable when used to create database users.

[mixtah]

I had the same issue except my usage meant that an encryption key was unexpectedly lost when I was deploying a stack that needed a reference to the secret for it's IAM permissions. The key was lost, the data cannot be decrypted and so the data had to be deleted as the idea is for no human to need to see these keys. Luckily it's just development but the crux here is the unexpected regeneration of the key can break things.

Perhaps a solution is a setting that determines if a change in the value should let it be redeployed/regenerated or not. If we really want to redeploy it, we can always flick the boolean, deploy, then flick it back.

[jkkitakita]

Regeneration of secret string cannot be prevented, but, using secrets rotation, I was able to work around this problem by setting rotate_immediately_on_update=True. see https://github.com/aws/aws-cdk/issues/26099