terraform-provider-azurerm: Azure Key Vault resource creation fails immediately following a destroy
Community Note
- Please vote on this issue by adding a π reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave β+1β or βme tooβ comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Terraform (and AzureRM Provider) Version
Terraform v1.0.0
on linux_amd64
+ provider registry.terraform.io/hashicorp/azurerm v2.64.0
Affected Resource(s)
azurerm_key_vault_secret
azurerm_key_vault_certificate
Terraform Configuration Files
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
}
}
}
provider "azurerm" {
features {
key_vault {
recover_soft_deleted_key_vaults = false
purge_soft_delete_on_destroy = true
}
}
}
resource "azurerm_key_vault_secret" "secret" {
name = "test"
value = "123"
key_vault_id = data.azurerm_key_vault.app.id
}
data "azurerm_key_vault" "app" {
name = "< keyvault name>"
resource_group_name = "< keyvault RG name >"
}
Debug Output
Panic Output
Expected Behaviour
Terraform apply should re-create the resources (secrets or certificates).
Actual Behaviour
Terraform apply immediately following a destroy results in the following error:
Error: keyvault.BaseClient#RecoverDeletedSecret: Failure responding to request: StatusCode=404 -- Original Error: autorest/azure: Service returned an error. Status=404 Code="SecretNotFound" Message="A secret with (name/id) xxxx was not found in this key vault. If you recently deleted this secret you may be able to recover it using the correct recovery command. For help resolving this issue, please see https://go.microsoft.com/fwlink/?linkid=2125182"
If the features
section of the provider is updated to explictly specify:
recover_soft_deleted_key_vaults = false
purge_soft_delete_on_destroy = true
the error then becomes:
azurerm_key_vault_secret.secret: Creating...
β·
β Error: keyvault.BaseClient#SetSecret: Failure responding to request: StatusCode=409 -- Original Error: autorest/azure: Service returned an error. Status=409 Code="Conflict" Message="Secret test is currently being deleted and cannot be re-created; retry later." InnerError={"code":"ObjectIsBeingDeleted"}
β
β with azurerm_key_vault_secret.secret,
β on main.tf line 18, in resource "azurerm_key_vault_secret" "secret":
β 18: resource "azurerm_key_vault_secret" "secret" {
Perhaps the destroy is not waiting long enough for the correct API response from ARM? Waiting another minute or so seems to resolve this as the resource is eventually marked as deleted/purged from the key vault.
Steps to Reproduce
terraform apply
terraform destroy
terraform apply
<< Fails
Important Factoids
Reverting to v2.63.0 of azurerm does not seem to resolve this. This behavior only seemed to start occurring in the past 24 hours (19/06/2021) from what Iβve observed.
References
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 15
- Comments: 15 (4 by maintainers)
Microsoft have responded stating that there is a current known issue related to long running operations, such as purging soft-deleted objects, which take longer to complete than expected. No current ETA on a fix, but it is being looked into.
This still seems to happen with 2.66.0. Perhaps a workaround is to extend the PUT request wait time, especially when getting a 409 back? Not sure if one of the core developers has looked at this yet.
Edit: Looks like Microsoft is rolling out a hotfix for this and expected to be in all regions by 15/07.
Looking at this briefly, it appears that this is a result of the of PUT (https://docs.microsoft.com/en-us/rest/api/keyvault/set-secret/set-secret) returning a 409 with the following error:
This is despite the prior purge (DELETE) call returning a 204 after the secret is deleted.
Logged a call with Microsoft support around this, but we may need the provider to check and handle 409s on the PUT/CREATE operations if this behavior is by design. This seems to only happen on resource re-creation or within a short period of time after a resource is deleted and purged.