Deleting a key vault secret does not purge it, therefore it's not available for reuse.

[thrixton]

When a key vault secret is created using user-provided name and then deleted, the secret is not purged, meaning it cannot be reused until either manually purged or expired by the retention window (min 7 days).

Example resource

const credentialsSecret = new azure.keyvault.Secret("credentials", {
        keyVaultId: conf.infraConfig.keyVaultId,
        value: credentials.password,
        name: `credentials`,
    }, { deleteBeforeReplace: true });

[mikhailshilkov]

Hi @thrixton thank you for reporting this.

I believe this is by design, as this is the default deletion mode for KeyVault secrets. The same actually applies to vaults themselves, and probably other KeyVault object.

I know the classic provider has a configuration lever to switch purging on/off. I think we'd need to have a similar capability before we could switch to purge-by-default.

Do you have other ideas of how to enable auto-purge but also provide other users the ability to keep soft-delete on?

[thrixton]

@mikhailshilkov , I think there should be a property purgeOnDestroy: boolean which if true would purge the secret when destroyed.
I'm not sure which config you're referring to for the classic provider, can you point me in the right direction?

[mikhailshilkov]

I mean these options, although I'm having a hard time to find any documentation about them:

https://github.com/pulumi/pulumi-azure/blob/d40c65699cbe10fe356b50346db841618b6e3be4/sdk/nodejs/types/input.ts#L28-L29

[thrixton]

I see, thanks.
Yes, that sounds like the exact feature that needs migration to azure-native.

[adiesner]

How about simply restoring the secret if a deleted (but not yet purged) secret exists?

The secret provider should

• create the secret
• if that fails, try to restore a deleted secret with the same name and set value

or simply purge it if the creation fails and then recreate it.

[Bj3MaS]

I has same issue, it resolved for me by setting enableSoftDelete:false

[PawelStadnicki]

I personally see key vault and secrets as very fragile special resources and don't want to play with disabling soft deletion at all.
You may remember to bring back proper settings after the development phase but it is risky especially when multiple persons are working on the same IaC code or it is run via DevOps.

I agree that having to purge them manually in development in order to keep naming convention is a kind of burden but it is a trade-off.

For unsupported or tricky operations you can consider using CliWrap nuget and call 'az purge' command in your C# program (with Pulumi API you can apply it to a destroy command)

[pierskarsenbarg]

According to this article, Microsoft will be enabling soft-delete by default and deprecating the ability to turn it off.

This means that if you have an iternal policy that means you need to not use auto-naming, you're not going to be able to delete keyvaults because we don't provide a way of recovering at the moment.

[praneetloke]

@pierskarsenbarg

This means that if you have an iternal policy that means you need to not use auto-naming, you're not going to be able to delete keyvaults because we don't provide a way of recovering at the moment.

I am not following this statement. Could you please clarify this?

[pierskarsenbarg]

@praneetloke in Azure classic, if you have a key vault that isn't auto-named, delete it and attempt to re-create it, the provider will attempt to recover it. We don't do this in Azure native.

Currently, in Azure, you can disable soft-delete, which means that when you delete the resource, it's gone for good, and if you don't use auto-naming then you can recreate the resource over and over again. However, when MS/Azure enables soft-delete permanently, it means that a new key vault created with the same name as one that has been soft-deleted (i.e. it's in a recycle bin somewhere) will fail.

[praneetloke]

@pierskarsenbarg thank you for the explanation! :)

[JasonWhall]

I'm willing to contribute to this as I am also impacted by soft-delete being enabled by default across KeyVaults.

IMO it seems like the "easiest" course of action would be to start replicating the behaviour in the Pulumi.Azure provider by recovering from Soft-delete as the default. This will cover cases where purge-protection is enabled on the KeyVault.

I can see there is already some logic to override the generated method for KeyVault resources here. Would it be the case of just extending this further to override the Create/Update functions and implement the recovery logic? If so I'm happy to contribute a PR to do this.

[bizmonger]

So do I really have to manually purge my deleted secrets each time I want to run my automation (that relies on Classic KeyVault)?

[benhathaway]

My team would be very interested in a solution to this problem. Turning off soft-delete is not a real solution - particularly if Microsoft remove the option in the near future.
I was looking for some kind of callback or hook that would let us write custom onDestroy code to purge the keys - but I couldn't find one. I am currently planning on writing something in powershell to run on our build pipeline after the Pulumi destroy has completed (yuk!).
Incidentally; we will have similar problems with the Azure ConfigurationStore component - except that there are even fewer options exposed for that one (there is nothing equivalent to SoftDelete: false).

[yori-s]

A purgeOnDestroy option would be nice, both at the secret and vault level

[cermakp]

Hi, any updates on that?