@jarv whatever we do we want to make sure that sandbox environments are still easy to tear down. I'm not sure if this will impact that, but it sounds like it will (we have similar issues on AWS). If so, we should set 7 days for non-sandboxes, 0 days for sandboxes perhaps?
@andrewn afaict this is only for secret versions, not the secrets themselves.
In fact, you can create a new secret, create a version with version-destroy-ttl and while you cannot delete the secret version immediately, you can delete the secret itself
There are two main resources within Secret Manager — secrets and secret versions. A secret is a project-global object containing a collection of metadata and secret versions. The secret version is where the actual secret data, such as credentials, API keys or certificates is stored.
and
Enabling the delayed destruction feature alone will not provide you complete defense against destruction of secret material. It is important that you set appropriate access controls on your secrets. Even with the feature enabled, an administrator of the secret can still choose to delete the complete secret if they wish.
I assume on the terraform side of things we are ok? because the secret versions are created with a null_resource and on destroy it will destroy the secret itself.
Please add a team label to this issue to help it get assigned to the right group.
If this relates to a specific service, find the appropriate team in the service catalog.
Use teamOps for reliability_ops services and teamFoundations for reliability_foundations services.
If you are still unsure where the issue should go, please ask in the #infrastructure-lounge Slack channel or ping @gitlab-org/production-engineering/managers in the issue.
@igorwwwwwwwwwwwwwwwwwwww I am thinking the optimal thing to do here is to set both version_destroy_ttl (for malicious or accidental deletes outside of Terraform) and deletion_policy = "ABANDON" for ensuring that no versions ever get deleted in Terraform runs. WDYT of that approach?