The ability to keep the previous version of the secret when the google_secret_manager_secret_version is being replaced

[alexku7]

Sometimes ( usually!) when the current version of the secret is rotated we prefer not to destroy the replaced secret version .

It could be very useful to add a flag to google_secret_manager_secret_version resource which will specefy when I want to destroy/keep/disable the previous secret version when the google_secret_manager_secret_version is need to be replaced

[rileykarson]

I think we'd expect the secret to get replaced here- you're updating a specific version to a specific value. Adding a new google_secret_manager_secret_version resource is how you would add a new version of the secret while preserving the old, one.

Not entirely related, but possibly relevant: #14488

[alexku7]

Sorry but I disagree.

Think about the following scenario
For example
I use acme_certificate to renew a certificate and store the renewed certificate in the google secret.
So the google_secret_manager_secret_version gets the secret_data as the output from the acme_certificate resource.

When I renew the new secret_data is stored, usually I want not to destroy the current secret version with the current certificate. I might want to keep it as is or disable the version but not to destroy.
It can be critical to rollback to the previous certificate in case of any unexpected issue.

Bottom line, not always we want to destroy the previous version when we add a new version to the secret.

This is why the google secret has versions, no ?

[rileykarson]

The issue is that the google_secret_manager_secret_version manages a specific version of the secret- if the configuration you've written tells Terraform to delete the version, deleting the version is appropriate. That's where #14488 is relevant, I expect that some (most?) users don't want secret versions managed with this level of granularity by Terraform and want to update the latest version.

[alexku7]

@rileykarson
I am pretty sure
It's much simpler.

All what's needed is to add additional param like "dont_destroy_previous_version_on_change".

That's all.
If the secret_data param changed, the tf will create a new version with new secret_data but without destroying the current last version.

[rileykarson]

A deletion_policy field could work, yeah: https://googlecloudplatform.github.io/magic-modules/best-practices/#deletion-policy

[alexku7]

Thanks

[sergioagm]

Sorry, is there any update on this?

We also are interested in a deletion_policy for secrets rotation. In our use case, we have multiple services using a mix of Cloud Functions and Cloud Run that get their configuration as Environment Variables from Secret Manager.

To avoid the issue of updating a secret and the app not picking it up (due to using latest) we always pin it to a specific version. The issue is that when the secret data is updated, our previous secret is destroyed and we have to immediately start a new deployment pointing to the new version. This can cause downtime if, for example, in the meantime a Cloud Function is triggered and tries to use the old version that was already destroyed.

Also as previously mentioned, this makes our rollbacks very difficult to manage since deploying an app pointing to an old secret version won't work.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.