Feature: Lock on secrets

[a-nldisr]

Feature request:

In the Doppler interface, you can place locks on secrets, it would be nice to set locks on secrets from the Terraform provider to ensure removing/changing a resource doesn't cause accidental removal.

Example

resource "doppler_secret" "db_password" {
  project = "backend"
  config = "dev"
  name = "DB_PASSWORD"
  value = random_password.db_password.result

  lock = true
}

To be able to remove the resource the lock = true needs to be changed to false

[a-nldisr]

Update: Locks are not present on secrets directly, they need to be done on branch configs.

[nmanoogian]

Hey @a-nldisr! Thanks for writing in about this. We've gotten feedback from other users that it would be handy to mark certain secrets as "Terraform managed" so that they can't be modified outside of Terraform. Is this what you're aiming to do?

...it would be nice to set locks on secrets from the Terraform provider to ensure removing/changing a resource doesn't cause accidental removal.

Can you expand on this a bit? I'm not sure if there's a way we could design the provider such that removing or changing a resource doesn't remove the corresponding object in Doppler. Even using locks at the config level, you would still be able to remove the config by unlocking it first.

[a-nldisr]

Hi @nmanoogian! Comments would be greatly appreciated, but would like to use the lock:

In general when you use this feature in cloud resources, you need to first remove the lock and afterward you can update or delete the secret. We have a few secrets we want to place only in Doppler and nowhere else, and it would be costly if these would be lost due to a terraform mistake.
A workflow would look like:
Remove lock from code > run terraform > adjust config > run terraform > config deleted
Current workflow is:
adjust config > run terraform > config deleted

Lock would give some safety mechanisms on configs which are important.

[nmanoogian]

Ah, I see! Thank you for walking me through that. The strategy of needing to update the resource twice to perform a deletion makes sense. I'll pass this along to our product team!