Recovered key vault has old network acls

[twendt]

Is there an existing issue for this?

• I have searched the existing issues

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 Version

1.3.3

AzureRM Provider Version

3.28.0

Affected Resource(s)/Data Source(s)

azurerm_key_vault

Terraform Configuration Files

variable "ip" {
  type = string
  description = "IP to whitelist in key vault"
}

provider "azurerm" {
  features {
    key_vault {
      purge_soft_delete_on_destroy = false
      recover_soft_deleted_key_vaults = true
    }
  }
}


data "azurerm_client_config" "current" {}

resource "azurerm_resource_group" "this" {
  name     = "rg-keyvault-test-whitelist-001"
  location = "westeurope"
}

resource "azurerm_virtual_network" "this" {
  name                = "vnet-keyvault-test-001"
  location            = azurerm_resource_group.this.location
  resource_group_name = azurerm_resource_group.this.name
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_subnet" "this" {
  name                                           = "default"
  resource_group_name                            = azurerm_resource_group.this.name
  address_prefixes                               = ["10.0.1.0/24"]
  virtual_network_name                           = azurerm_virtual_network.this.name
  service_endpoints                              = ["Microsoft.KeyVault"]
  private_endpoint_network_policies_enabled = true
}

resource "azurerm_key_vault" "this" {
  name                     = "kv-test-whitelist-001"
  location                 = azurerm_resource_group.this.location
  resource_group_name      = azurerm_resource_group.this.name
  purge_protection_enabled = true

  sku_name = "standard"

  network_acls {
      default_action             = "Deny"
      bypass                     = "None"
      ip_rules                   = [ var.ip ]
      virtual_network_subnet_ids = [ azurerm_subnet.this.id ]
  }

  tenant_id = data.azurerm_client_config.current.tenant_id

}

Debug Output/Panic Output

none

Expected Behaviour

The given IP should be configured in the network acls and also the subnet should be configured in the network acls.

Actual Behaviour

The network acls are the ones that the where configured on the old deleted key vault.
The plan does actually show correct entries and the apply runs successfully. But afterwards the network acls do not match the configuration.

The vnet rule is deleted after the apply. This however might be how it works in Azure. If the vnet has been deleted, like in the example below, then the vnet rule in the network acls is deleted after the recover. If the vnet has not been deleted, but only the key vault, then the vnet rule still exists in the recovered key vault.
The IP rules are always wrong.

Running another terraform apply fixes the issue. This should not be required though.

Steps to Reproduce

1. terraform apply -var 'ip=1.2.3.4'
2. terraform destroy
3. terraform apply -var 'ip=1.2.3.5'

Important Factoids

No response

References

No response

[ms-zhenhua]

Hi @twendt, thank you for reaching out.
This issue is caused by the Azure service. When recovering the key vault, the Azure service will only recover the last deleted result, but not update the properties with the latest configuration. I have reported this issue to Azure.

[twendt]

Would it not be possible to update they key vault again after recovering it?

[ms-zhenhua]

Hi @twendt, since creating and updating a resource in the same operation is not a common case in the provider, we need to do more investigation on it.
As a workaround for this issue, you may consider create a new key vault instead of recovering the old one if you decide to update some of its properties.

[manicminer]

If it results in a viable workflow, we could update the key vault after recovering the soft deleted key vault.

[jamesw4]

Ran in to same issue last week while running through process to destroy and re-create a test env.