hashicorp / terraform-provider-azurerm

Terraform provider for Azure Resource Manager
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs
Mozilla Public License 2.0
4.59k stars 4.63k forks source link

azurerm_key_vault_secret Produced Inconsistent Results #15281

Open RoyC7 opened 2 years ago

RoyC7 commented 2 years ago

Terraform (and AzureRM Provider) Version

Terraform v1.1.4 on linux_amd64 and Terraform v1.1.5 on linux_amd64

Affected Resource(s)

Terraform Configuration Files

resource "azurerm_key_vault_secret" "AppInsight-ConnectionString" {
  name         = "AppInsight-ConnectionString"
  value        = var.appinsstrg
  key_vault_id = azurerm_key_vault.keyvault.id
  content_type = ""
  tags         = {}
  timeouts {
    read = "10m"
  }
}

Panic Output

│ Error: Provider produced inconsistent result after apply │ │ When applying changes to │ module.AzKeyvault.azurerm_key_vault_secret.AppInsight-ConnectionString, │ provider "provider[\"registry.terraform.io/hashicorp/azurerm\"]" produced │ an unexpected new value: Root resource was present, but now absent. │ │ This is a bug in the provider, which should be reported in the provider's │ own issue tracker.

Important Factoids

Note even after having this message all (32)secrets are created on the keyvault

tgolly commented 2 years ago

I got this on a deployment this morning too, first time ever on TF code that hasn't changed for a long while. Very similar error to yours.

Error: Provider produced inconsistent final plan

When expanding the plan for
module.aks.azurerm_key_vault_secret.aks_admin_client_certificate to include
new values learned so far during apply, provider
"registry.terraform.io/hashicorp/azurerm" produced an invalid new value for
.value: inconsistent values for sensitive attribute.

This is a bug in the provider, which should be reported in the provider's own
issue tracker. 
MarcBuch commented 2 years ago

Same for me, but I noticed that the secret will be created on the Key Vault.

resource "azurerm_key_vault_secret" "this" {
  name         = var.secret_name
  key_vault_id = azurerm_key_vault.this.id

  value = var.secret
}

Terraform v1.1.6 on linux_amd64 azurerm v1.1.5

MarcBuch commented 2 years ago

As the Key Vault secret gets created, I tried to import the resource using the secret identifier. But I get this error message:

│ Error: Cannot import non-existent remote object
│
│ While attempting to import an existing object to "azurerm_key_vault_secret.connection-string", the provider detected that no object exists with the given id. Only pre-existing objects
│ can be imported; check that the id is correct and that it is associated with the provider's configured region or endpoint, or use "terraform apply" to create a new remote object for
│ this resource.

Other secrets are created without a problem. It seems like the provider is having an issue with special characters.

EDIT: CREATE works sometimes, UPDATE and DELETE don't work

HSoulat commented 2 years ago

I got the same issue, maybe in different context :

The secret is well created, but provider B do not seem capable to see the resource after creation.

jnahelou commented 2 years ago

I have a similar issue when the provider subscription differed from keyvault subscription.

Wrong usage :

# Use default credentials subscription <sub-a>
provider "azurerm" {
  features {}
}

resource "azurerm_key_vault_secret" "example" {
  name         = "issue-replication"
  value        = "test2"
  key_vault_id = "/subscriptions/<sub-b>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<kv>"
}

In Terraform logs, you can find the rest call for the wrong subscription <sub-a> GET /subscriptions/<sub-a>/resources?%24filter=resourceType+eq+%27Microsoft.KeyVault%2Fvaults%27+and+name+eq+%27<kv>%27&%24top=5&api-version=2020-06-01 HTTP/1.1

My workaround (you can also use a provider alias to dedicate keyvault provider):

provider "azurerm" {
  features {
  subscription_id = "<sub-b>" # Force the subscription to use
}

resource "azurerm_key_vault_secret" "example" {
  name         = "issue-replication"
  value        = "test2"
  key_vault_id = "/subscriptions/<sub-b>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<kv>"
}

Hope it helps..

L-u-k-e-GIT commented 2 years ago

Hi I have same issue Error: Provider produced inconsistent result after apply │ │ When applying changes to azurerm_key_vault_secret.vmpassword["vm3"], provider "provider[\"registry.terraform.io/hashicorp/azurerm\"]" produced an unexpected new value: Root resource was present, but now absent.
│ │ This is a bug in the provider, which should be reported in the provider's own issue tracker.

==================== Terraform v1.1.7 on windows_386

GiuseppeChiesa-TomTom commented 2 years ago

Hello,

I'm experiencing the same issue after switching to AzureRM v3.x (v3.13.0)

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to azurerm_key_vault_secret.slack_token, provider
│ "provider[\"registry.terraform.io/hashicorp/azurerm\"]" produced an
│ unexpected new value: Root resource was present, but now absent.
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵

Terraform and providers:

❯ terraform version
Terraform v1.2.4
on darwin_amd64
+ provider registry.terraform.io/articulate/validation v0.0.3
+ provider registry.terraform.io/gavinbunney/kubectl v1.14.0
+ provider registry.terraform.io/hashicorp/azurerm v3.13.0
+ provider registry.terraform.io/hashicorp/helm v2.6.0
+ provider registry.terraform.io/hashicorp/http v2.2.0
+ provider registry.terraform.io/hashicorp/kubernetes v2.12.1
+ provider registry.terraform.io/hashicorp/null v3.1.1
+ provider registry.terraform.io/hashicorp/random v3.2.0
+ provider registry.terraform.io/hashicorp/template v2.2.0
+ provider registry.terraform.io/hashicorp/time v0.7.2
+ provider registry.terraform.io/hashicorp/tls v3.4.0
SeanGraySage commented 1 year ago

Hello,

I'm also experiencing this issue with Terraform 1.3.3 and AzureRM provider 3.29.1. The secret is always created correctly but doesn't make it into the state file, which causes problems if we just run it again as it then complains that the resource already exists.

rafabu commented 1 year ago

seeing exact same behaviour with azurerm provider v3.32. Secrets get created in key vault but do not make it to the state with Provider produced inconsistent result after apply ... Provider produced an unexpected new value: Root resource was present, but now absent.

It mostly runs on a second try if we delete (and purge) the secrets beforehand.

krsche commented 1 year ago

Still happening on azurerm v3.57.0 :(
After three iterations of manually deleting & purging the secrets it worked...

Importing of the kv secrets did not work with error: Error: Cannot import non-existent remote object

Tiana125 commented 1 month ago

Same error happening on azurerm v4.3.0 :( But the good news is re-running plan + apply works, can see a new version of key vault secret is updated