What's the best way to handle key vault creation in Bicep with soft deletion and purge protection?

[hallgeir-osterbo-visma]

In Terraform, it's possible to enable automatic recovery of deleted key vaults and secrets if they are soft deleted. If it's a new key vault or secret, it'll choose to create it instead. However, in Bicep, it's a bit more tricky. Here we have to specify createMode on the resource to choose whether to recover, or create a new vault. If a soft-deleted vault exist, createMode: 'default' will fail. If it doesn't, createMode: 'recover' will fail.

This is a problem for us, especially with development environments where we sometimes delete resources and create them again. We can't set createMode to recover unconditionally, because it'll cause new environments not currently deployed to fail, as well as if we add new key vaults to the bicep project.

There's a couple of issues reported, that if resolved, would completely fix this issue for us:
#7529
#10655

But until (if ever) these are resolved, what's the best way to approach this? When we potentially have a mix of soft-deleted and non-existing key vaults that must be either recovered or created, this seems very cumbersome.

Any good tips here?

[brwilkinson]

I don't think there is a good "declarative" approach here.

I assume if it's set to recover and it's new, then it fails? Hopefully you are not using access policies anyway, RBAC is a better model in most circumstances.

The fallback would be to add a restore function in a deploymentScript, which skips action if the vault isn't soft deleted or restores if it was.

Then run that Module, before you're normal keyvault Module.

If this is for a lab, I would just disable soft delete all together.

What scenario do you find yourself in need of this? How often are people deleting vaults? Perhaps consider a delete lock as an alternative.

Or let the deployment fail, then run a manual restore command, then redeploy.

[BartDecker]

@brwilkinson yeah indeed as you proposed. We just check in the nightly cleanup script if a keyvault has purge protection turned on and if so we skip the removal of the keyvault. This allows the build flow to run afterwards.

[hallgeir-osterbo-visma]

Right! Thanks for a good answer.

To answer your followup questions:

• Yes, if we set it to recover, and the key vault is not soft-deleted but instead new, then it fails.
• About access policies vs RBAC - We're using access policies right now, but we are planning to migrate to RBAC. It solves some other issues we have at the moment with key vaults.
• About which scenario this is for: Well, it's in the "lab"/dev stage at the moment. But the key vaults are already created, and with soft-delete enabled. I suppose we can wait for the retention period to expire, then set soft delete to false?

Good tips about using a deployment script. We'll look into that as a workaround for now.

I'll mark your post as an answer. Thank you!

[brwilkinson]

Thanks for the follow up @hallgeir-osterbo-visma

There are those 2 open issues that you listed on this, so it will likely get placed in the queue for the KV team to assess.

Perhaps a new mode "createOrRestore". However I wouldn't expect any timely action from them, that might assist in the short term.

[portal7]

totally agree, it's a nightmare try to avoid colissions with existing or not