Terraform-provider-azurerm: azurerm_key_vault_secret with far-future expiration date does not converge

[n2qz]

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 v0.13.0-rc1

• provider registry.terraform.io/-/azurerm v2.22.0
• provider registry.terraform.io/hashicorp/azurerm v2.22.0

Also confirmed with:

Terraform v0.12.20

• provider.azurerm v2.22.0

Affected Resource(s)

• azurerm_key_vault_secret

Terraform Configuration Files

terraform {
}

provider "azurerm" {
  version = "= 2.22.0"
  features {
  }
}

data "azurerm_resource_group" "rg" {
  name = "rg-n2qz"
}

data "azurerm_client_config" "current" {
}

resource "azurerm_key_vault" "kv" {
  name                = "kv-test-n2qz"
  resource_group_name = data.azurerm_resource_group.rg.name
  location            = "eastus2"
  sku_name            = "standard"
  tenant_id           = data.azurerm_client_config.current.tenant_id
}

resource "azurerm_key_vault_access_policy" "key_vault_access_policy" {
  key_vault_id = azurerm_key_vault.kv.id
  object_id    = data.azurerm_client_config.current.object_id
  tenant_id     = data.azurerm_client_config.current.tenant_id

  secret_permissions = [
    "Get",
    "List",
    "Set",
    "Delete",
    "Recover",
    "Backup",
    "Restore",
  ]
}

resource "azurerm_key_vault_secret" "test-secret1" {
  depends_on   = [
    azurerm_key_vault_access_policy.key_vault_access_policy
  ]
  name         = "test-secret1"
  value        = "password"
  key_vault_id = azurerm_key_vault.kv.id
  expiration_date = "2111-12-31T00:00:00Z"
}

resource "azurerm_key_vault_secret" "secret2" {
  depends_on   = [
    azurerm_key_vault_access_policy.key_vault_access_policy
  ]
  name         = "test-secret2"
  value        = "password"
  key_vault_id = azurerm_key_vault.kv.id
  expiration_date = "9999-12-31T00:00:00Z"
}

Debug Output

Panic Output

Expected Behavior

Both test-secret1 and test-secret2 should converge.

Actual Behavior

test-secret1 converges.

test-secret2 does not converge:

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # azurerm_key_vault_secret.secret2 will be updated in-place
  ~ resource "azurerm_key_vault_secret" "secret2" {
      ~ expiration_date = "1816-03-29T05:56:08Z" -> "9999-12-31T00:00:00Z"
        id              = "https://kv-test-n2qz.vault.azure.net/secrets/test-secret2/c2f2c7488aad476f8a1bb744fe0f8c9c"
        key_vault_id    = "/subscriptions/xxx/resourceGroups/rg-n2qz/providers/Microsoft.KeyVault/vaults/kv-test-n2qz"
        name            = "test-secret2"
        tags            = {}
        value           = (sensitive value)
        version         = "c2f2c7488aad476f8a1bb744fe0f8c9c"
    }

Plan: 0 to add, 1 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

Steps to Reproduce

1. terraform apply
2. terraform plan

Important Factoids

References

[njuCZ]

@n2qz thanks for pointing out this issue. After digging into this problem, I found it's an upstream repo issue. I have fired an issue there https://github.com/Azure/go-autorest/issues/549. For now, to work around this problem, we would better specify the expiration date before 2200.

[tombuildsstuff]

@njuCZ whilst that's technically a bug in the Go SDK - I'd argue this is a bug in the Key Vault API that it's accepting invalid/unrealistic data here too (both in the past and the very far future) - so this probably wants an API bug too to track that?

[njuCZ]

@tombuildsstuff In the portal, there is no problem to set expiration date as "9999-12-31T00:00:00Z". And I have tested the unixTime type in go-autorest, the marshall and unmarshall function could not handle large date.

[tombuildsstuff]

@njuCZ if I'm honest that sounds like a bug in the Portal/API - presumably the API should be returning an error for a date ~8000 years in the future - particularly with secret/sensitive values, where it's recommended to have a short-lifetime for? As popular as Azure Key Vault is today, it seems optimistic to assume that the same code is still running ~8000 years from now

[njuCZ]

@tombuildsstuff I have fired an issue in rest-api-specs repo: https://github.com/Azure/azure-rest-api-specs/issues/10473

[n2qz]

At the very least, this field should never silently overflow and wrap around to the beginning of time. If there is a maximum date/time that will be accepted, overflow should result in an error message clearly stating that maximum value.

[tombuildsstuff]

@n2qz I'd agree - in this instance this bug itself comes from the Azure SDK (or rather it's transport layer, Azure/go-autorest) and is unlikely to be fixed anytime soon (the "Track1" SDK that exists today is being superseded - and unfortunately the "Track2" SDK which is intended to replace it doesn't yet meet our needs).

Whilst certain Azure examples do refer to "9999-12-31" as "infinite" - as it's recommended to use short-lifetimes for secrets, I'd suggest we wait for the service to confirm the maximum end-date here and then add validation to match that.