[RDS] Issue with credentials & Secret attachment #11040
Assignees
Labels
@aws-cdk/aws-rds
Related to Amazon Relational Database
bug
This issue is a bug.
in-progress
This issue is being actively worked on.
needs-triage
This issue or PR still needs to be triaged.
Comments
Cloudrage
added
bug
github-actions
bot
added
the
@aws-cdk/aws-rds
Cloudrage
changed the title
|
@Cloudrage is this a duplicate of #10800? |
|
Hello @skinny85 , Not really sure but indeed, when updating the Secret, all fields generated by the attachment was lost. |
jogold
added a commit
to jogold/aws-cdk
that referenced
this issue
Oct 31, 2020
…tachment When the `excludeCharacters` prop is updated the secret is correctly regenerated but the database is not updated because the `MasterUserPassword` prop does not change. Moreover the connection fields created by the attachment are lost because the secret is regenerated but the `AWS::SecretsManager::SecretAttachment` doesn't "rerun". Introduce a new `fromFixedUsername()` static method in `Credentials`. When used the `MasterUsername` prop of the database references the username as a string instead of a dynamic reference to the username field of the secret. Moreover the logical id of the secret is a hash of its customization options. This way the secret gets replaced when it's customized, the database gets updated and the attachement reruns. This without updating the `MasterUsername` prop, avoiding a replacement of the database. Closes aws#11040
|
Ok. Let's close this one then, and move the conversation to #10800 to have it all in one place. |
|
mergify bot
pushed a commit
that referenced
this issue
Nov 6, 2020
…tachment (#11237) When the `excludeCharacters` prop is updated the secret is correctly regenerated but the database is not updated because the `MasterUserPassword` prop does not change. Moreover the connection fields created by the attachment are lost because the `AWS::SecretsManager::SecretAttachment` doesn't "rerun" (it references the same secret). Introduce `fromGeneratedSecret()` and `fromPassword()` static methods in `Credentials`. When used the `MasterUsername` prop of the database references the username as a string instead of a dynamic reference to the username field of the secret. Moreover the logical id of the secret is a hash of its customization options. This way the secret gets replaced when it's customized, the database gets updated and the attachement reruns. This without updating the `MasterUsername` prop, avoiding a replacement of the database. For instances that were created from a snapshot the `MasterUsername` prop is not specified so there's no replacement risk. Add a new static method `fromGeneratedSecret()` in `SnapshotCredentials` to replace the secret when its customization options change (also hash in logical id). Deprecate `Credentials.fromUsername()` but keep it as default to avoid a breaking change that would replace existing databases that were not created from a snapshot. Deprecate `SnapshotCredentials.fromGeneratedPassword()` which doesn't replace the secret when customization options are changed. Closes #11040 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When updating a SecretsManager Secret defined in "credentials" prop of an RS Instance, we lost the attachment.
Reproduction Steps
Create an RDS Instance with "credentials" prop targeting a Secret.
Update the Secret.
What did you expect to happen?
I want to update my Secret but keep the attachment ith the DB.
What actually happened?
You lost the attachment and it's not possible to add it because we have an error :
Secret is already attached to a target.So a workaround is to update the DB with no/or another Secret.
But in that case, DB Instance is replaced/recreated (???!!!)
Environment
Other
In my case, I've update the DB without the prop "credentials", then, update it again with my Secret (the Original one).
But it recreate @ll my DB instances 2 times and lost datas of course...
credentials: rds.Credentials.fromSecret(SecretsManager)This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: