Key Vault Key Not Found for the multi-subscription case

[ivanignatiev]

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

Affected Resource(s)

• azurerm_key_vault_key

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key: https://keybase.io/hashicorp

Debug Output

Panic Output

Expected Behavior

Retrieve Key from KeyVault from subscription different from current context.

Actual Behavior

Resource azurerm_key_vault_key is trying to verify if KeyVault exists in the current subscription when KeyVault and its resource group are placed in the another one, so it raises Resource Group Not Found error.

Steps to Reproduce

1. Configure Key Vault in Subscription 2 (xxxx-xxxx-xxxx-xxxx)
2. Take the template from example https://www.terraform.io/docs/providers/azurerm/r/key_vault_key.html and copy to it Resource ID of created KeyVault (/subscriptions/xxxx-xxxx-xxxx-xxxx/resourceGroups/xxx-rg/providers/Microsoft.KeyVault/vaults/xxx-kv)
3. Login to your Azure account and select Subscription 1 (yyyy-yyyy-yyyy-yyyy) and try to deploy the resource depended on azurerm_key_vault_key from Key Vault in Subscription 2 (xxxx-xxxx-xxxx-xxxx)
4. terraform apply

Important Factoids

References

This issue should appear after merge of PR #2820 (comment)

• #0000

[tesharp]

We have discovered the same problem now..

It is also mentioned in #2396 when changing from using uri to id. It is recommended to use a different provider for data source, but that is not a good solution as it requires that it has access to that subscription. The Key Vault is in a subscription the CI service principal should not have access to. It has read access to a specific Key Vault in that subscription, but no access to subscription or any resource groups in that subscription. As it is now it doesn't work in a secure CI pipeline.

At least data source could use the vault_uri and not id attribute. I can see the problems it creates for key_vault resources when uri doesn't resolve to any valid dns if it is deleted and exists in state. For data source however it has to exist to even work, so why can't it just keep using vault_uri and therefore not depend on access in another subscription?

[tombuildsstuff]

👋

Taking a look through here this behaviour is expected since at this time we're looking the Key Vault up using the Key Vault ID, within the Subscription, as such you'd need to use a Provider alias to look this up, for example:

provider "azurerm" {
  features {}
}
provider "azurerm" {
  features {}
  alias = "other"
  subscription_id = "0000-...."
}

data "azurerm_key_vault" "existing" {
  name = "somekeyvault"
  resource_group_name = "some-resource-group"
  provider = "azurerm.other"
}

data "azurerm_key_vault_key" "existing" {
  name = "some-existing-key"
  key_vault_id = data.azurerm_key_vault.example.id
  provider = "azurerm.other"
}

resource "azurerm_app_service" "test" {
  // ..

  app_settings {
    SomeReference = data.azurerm_key_vault_key.existing.value
  }
}

It's worth noting that this behaviour is now called out in the documentation:

NOTE: The vault must be in the same subscription as the provider. If the vault is in another subscription, you must create an aliased provider for that subscription.

Since this behaviour is expected at this time and called out in the documentation - I'm going to close this issue for the moment - however should you have any further usage questions I'd point you to the community forums where someone should be able to help.

Thanks!

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!