terraform-provider-azurerm: key vault soft-delete causing failure when updating secrets or certificates

I’m seeing exactly the same issue. The new key_vault block in the features block in the v.2.0 AzureRm Terraform provider does support deleting and purging soft delete-enabled Key Vaults, but this functionality doesn’t seem to extend to deleting and purging secrets/keys/certificates which are managed by Terraform:

https://www.terraform.io/docs/providers/azurerm/index.html#purge_soft_delete_on_destroy

This has been released in version 2.41.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.41.0"
}
# ... other configuration ...

I’ve started looking into this and it appears that there is an overlap in how the key_vault features block impacts the Azure Key Vault itself and the objects (secrets, keys, certificates) within it assuming purge protection is not enabled.

The recover_soft_deleted_key_vaults option will recover both the key vault itself and objects within it. If this is set to false, and the either the keyvault itself or the object in question (for example: azurerm_key_vault_secret) have been destroyed but not purged, terraform apply will error out saying that the resource already exists. If this is set to true, then either the keyvault or the objects will be recovered on terraform apply.

The purge_soft_delete_on_destroy option will permanently delete the azurerm_key_vault resource on a terraform destroy when set to true. Note that this does not apply to all objects within the key vault itself.

In a specific case to azurerm_key_vault_secret (could be the same for keys and certificates), the secret will be deleted and remain in deleted state after a destroy. This means that further “post-execution” steps are required to completely purge the secret. This can be done before/after terraform runs or using local-exec on the same secret resource in question.

As some have already highlighted both in this issue and others, this is becoming more of a concern now that soft-delete will be enforced across all keyvaults later this year and no longer be optional. In situations where terraform is managing its own secrets (creation/updates/deletion), one would expect that a destroy operation can provide the option to “purge” the secret.

That said, one question is: would we use the existing provider-level feature purge_soft_delete_on_destroy to perform a purge after the secret is deleted or would a new option need to be defined that is clearer in terms of what exactly is happening? Would or can we want to enforce this on the resource (per secret/key/certificate) level or keep it provider wide? Note that its not always the case that both the keyvault and the secret are being provisioned within the same state context.

This could be implemented with something like this:

	_, err = client.DeleteSecret(ctx, id.KeyVaultBaseUrl, id.Name)
	log.Printf("[DEBUG] Secret %q deleted.", id.Name)
	// If purge_soft_delete_on_destroy = true and soft_delete is enabled on the keyvault, then purge the secret on deletion
	if meta.(*clients.Client).Features.KeyVault.PurgeSoftDeleteOnDestroy {
		log.Printf("[DEBUG] Purging %q from %q.", id.Name, id.KeyVaultBaseUrl)
		_, err = client.PurgeDeletedSecret(ctx, id.KeyVaultBaseUrl, id.Name)
		// TODO: Wait for secret state to transition as purge operation is not instant and we want to avoid 409s ("ObjectIsBeingDeleted")
		if err != nil {
			return fmt.Errorf("Error purging secret %q from %q: %v", id.Name, id.KeyVaultBaseUrl, err)
		}
	}

Feedback is appreciated. Happy to raise a PR if needed based on what the wider group comes back with.

We also have this problem. Now that Azure will remove opt-out of soft-delete on all Key Vaults by the end of year, this presents a major problem. All automation we’ve built on Terraform for certificate renewals is now a manual taks.

Side note / question: Is it a bug that a azurerm_key_vault_certificate must be re-created and is not updated in-place? The certificate resource does support versioning, but maybe the underlying API does not?