`azurerm_key_vault_secret` forces replacement if expiration_date is not known until apply

[adamoddy]

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 comments along the lines of "+1", "me too" or "any updates", 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 and review the contribution guide to help.

Terraform Version

1.11.0

AzureRM Provider Version

4.21.1

Affected Resource(s)/Data Source(s)

azurerm_key_vault_secret

Terraform Configuration Files

resource "azurerm_key_vault_secret" "expiring_secret" {
  name            = "expiring-secret"
  key_vault_id    = var.key_vault_id
  expiration_date = timeadd(timestamp(), "${30 * 24}h")
  value           = "My secret value"
}

Debug Output/Panic Output

Relevant portion of the plan debug output, with keyvault name and other properties not relevant to this issue redacted:

2025-02-28T11:50:32.002Z [DEBUG] provider.terraform-provider-azurerm_v4.21.1_x5.exe: {"value":"My secret value","contentType":"","id":"https://[REDACTED].vault.azure.net/secrets/expiring-secret/[REDACTED]","attributes":{"enabled":true,"exp":1743335824,"created":1740743226,"updated":1740743356,"recoveryLevel":"Recoverable","recoverableDays":90},"tags":{}}
2025-02-28T11:50:32.004Z [WARN]  Provider "registry.terraform.io/hashicorp/azurerm" produced an invalid plan for azurerm_key_vault_secret.expiring_secret, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .tags: planned value cty.MapValEmpty(cty.String) for a non-computed attribute
      - .content_type: planned value cty.StringVal("") for a non-computed attribute
2025-02-28T11:50:32.006Z [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = error reading from server: EOF"
2025-02-28T11:50:32.033Z [INFO]  provider: plugin process exited: plugin=.terraform/providers/registry.terraform.io/hashicorp/azurerm/4.21.1/windows_amd64/terraform-provider-azurerm_v4.21.1_x5.exe id=48916
2025-02-28T11:50:32.033Z [DEBUG] provider: plugin exited
2025-02-28T11:50:32.034Z [DEBUG] building apply graph to check for errors
2025-02-28T11:50:32.034Z [DEBUG] ProviderTransformer: "azurerm_key_vault_secret.expiring_secret (expand)" (*terraform.nodeExpandApplyableResource) needs provider["registry.terraform.io/hashicorp/azurerm"]  
2025-02-28T11:50:32.034Z [DEBUG] ProviderTransformer: "data.azurerm_key_vault.key_vault (expand)" (*terraform.nodeExpandApplyableResource) needs provider["registry.terraform.io/hashicorp/azurerm"]
2025-02-28T11:50:32.034Z [DEBUG] ProviderTransformer: "azurerm_key_vault_secret.expiring_secret" (*terraform.NodeApplyableResourceInstance) needs provider["registry.terraform.io/hashicorp/azurerm"]
2025-02-28T11:50:32.034Z [DEBUG] ProviderTransformer: "azurerm_key_vault_secret.expiring_secret (destroy)" (*terraform.NodeDestroyResourceInstance) needs provider["registry.terraform.io/hashicorp/azurerm"] 
2025-02-28T11:50:32.034Z [DEBUG] ReferenceTransformer: "azurerm_key_vault_secret.expiring_secret (expand)" references: [data.azurerm_key_vault.key_vault (expand)]
2025-02-28T11:50:32.035Z [DEBUG] ReferenceTransformer: "data.azurerm_key_vault.key_vault (expand)" references: []
2025-02-28T11:50:32.035Z [DEBUG] ReferenceTransformer: "azurerm_key_vault_secret.expiring_secret" references: [data.azurerm_key_vault.key_vault (expand)]
2025-02-28T11:50:32.035Z [DEBUG] ReferenceTransformer: "provider[\"registry.terraform.io/hashicorp/azurerm\"]" references: []

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # azurerm_key_vault_secret.expiring_secret must be replaced
-/+ resource "azurerm_key_vault_secret" "expiring_secret" {
      ~ expiration_date         = "2025-03-30T11:57:04Z" -> (known after apply) # forces replacement
      ~ id                      = [REDACTED] -> (known after apply)
        name                    = "expiring-secret"
      ~ resource_id             = [REDACTED] -> (known after apply)
      ~ resource_versionless_id = [REDACTED] -> (known after apply)
      - tags                    = {} -> null
      ~ version                 = [REDACTED] -> (known after apply)
      ~ versionless_id          = [REDACTED] -> (known after apply)
        # (3 unchanged attributes hidden)
    }

Expected Behaviour

When a valid expiration date is calculated at apply, the expiration date on the key vault secret should be updated and the secret should not be recreated.

Actual Behaviour

The key vault secret is deleted and then recovered with the updated expiration date.

Steps to Reproduce

1. Create an azurerm_key_vault_secret resource with an expiration date set
2. Generate a plan to update the resource with a new expiration date calculated at the time of apply using the timestamp() function
3. The plan will force replacement of the azurerm_key_vault_secret resource

Important Factoids

No response

References

Appears to be caused by the changes in azurerm_key_vault_secret: remove expiration triage recreate #28494

[stephybun]

@wuxu92 could you take a look at this?

[wuxu92]

Thank you, @stephybun, for the reminder. I had forgotten to update that pull request because the dynamic field's value would remain empty in CustomizeDiff. I have now created a new pull request to address this issue.

[gravufo]

Will this prevent recreate if the expiration is just changing from non-nil to non-nil but a different value?
Currently this is breaking our pipelines because it's trying to recreate the secret just because of an expiration date change.

[wuxu92]

If the expiration_date is interpolated with a reference or variable whose value is unknown during the planning stage, the secret will be recreated. The new pull request aims to address this issue. Conversely, if the value is determined at the planning stage, such as a literal value, the secret will not be recreated.

[gravufo]

I'm not sure I understand why the secret would need to be recreated either way. Wouldn't just posting a new version of the secret without an expiration_date work just fine?
We have plenty of lifecycle prevent_destroy everywhere and enforced by a linter, so this kind of behavior has a big impact.

[wuxu92]

Thank you, @gravufo, for bringing this to our attention. I attempted to update the not-before-date and expiration-date fields by creating a new version, and it does work. Unfortunately, the currently used SDK doesn't support setting a "null" value via the API to achieve this. This functionality may be added through PR: hashicorp/pandora#4633; however, there is no estimated timeline for its merge. In the meantime, I plan to revert the forceNew logic for these fields and make them updatable once the SDK is ready. cc @stephybun

[gravufo]

I understand the challenges. Thank you for taking my comment into consideration :)

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.