Terraform v0.12.18
provider.azurerm v2.3.0
azurerm_storage_account_customer_managed_keyresource "azurerm_storage_account_customer_managed_key" "sta_encryption" {
storage_account_id = azurerm_storage_account.storage_account.id
key_vault_id = var.key_vault_id
key_name = var.key_vault_key_name
key_version = var.key_vault_key_version
}
Terraform plan output :
# module.storage_account_without_lifecycle_rules.azurerm_storage_account_customer_managed_key.sta_encryption will be created
+ resource "azurerm_storage_account_customer_managed_key" "sta_encryption" {
+ id = (known after apply)
+ key_name = "XXXXXXX"
+ key_vault_id = "/subscriptions/XXXXXX/resourceGroups/XXXX/providers/Microsoft.KeyVault/vaults/XXXX"
+ key_version = "XXXXXXXXXXXXXXXXXXXX"
+ storage_account_id = (known after apply)
}
Error :
Error retrieving Key Vault "XXX" (Resource Group "XXX"): keyvault.VaultsClient#Get: Failure responding to request: StatusCode=404 -- Original Error: autorest/azure: Service returned a
n error. Status=404 Code="ResourceGroupNotFound" Message="Resource group 'XXX' could not be found."
Enable Storage Service Encryption with customer-managed keys in Azure key vault
Unbale to encrypt storage account with customer-managed keys, if the azure key vault and storage account is located in located in different subscriptions
resource "azurerm_storage_account_customer_managed_key" "sta_encryption" {
storage_account_id = azurerm_storage_account.storage_account.id
key_vault_id = var.key_vault_id
key_name = var.key_vault_key_name
key_version = var.key_vault_key_version
}
@tombuildsstuff Our use case is that we store our storage encryption keys in a "Shared Services" subscription and configure encryption on our storage accounts to be encrypted using the keys managed in the Shared Services subscription. This is entirely possible through ARM templates. As we've migrated over to Terraform, however, this issue is blocking us from getting rid of the ARM templates altogether.
Looking at the current code, it looks like the provider is performing a read request on the key vault in key_vault_id and failing because it's in a different subscription. This is incompatible with using Key Vault's in a different subscription than the primary resource, which doesn't match Azure's behavior of allowing storage accounts to use encryption keys in different subscriptions as long as the vault is in the same region. I think the provider should match what is allowed by Azure.
I would propose adding either adding a key_vault_uri property or calculating the URI without an API call based on the environment configured in the provider and the vault name (https://docs.microsoft.com/en-us/azure/key-vault/general/secure-your-key-vault#resource-endpoints) to support cross-subscription scenarios. I'm happy to work on either approach myself and submit a PR if you'd like.
This is currently being worked on in https://github.com/terraform-providers/terraform-provider-azurerm/pull/6815
When is this PR going to be merged, would really love to have this capability
Most helpful comment
@tombuildsstuff Our use case is that we store our storage encryption keys in a "Shared Services" subscription and configure encryption on our storage accounts to be encrypted using the keys managed in the Shared Services subscription. This is entirely possible through ARM templates. As we've migrated over to Terraform, however, this issue is blocking us from getting rid of the ARM templates altogether.
Looking at the current code, it looks like the provider is performing a read request on the key vault in
key_vault_idand failing because it's in a different subscription. This is incompatible with using Key Vault's in a different subscription than the primary resource, which doesn't match Azure's behavior of allowing storage accounts to use encryption keys in different subscriptions as long as the vault is in the same region. I think the provider should match what is allowed by Azure.I would propose adding either adding a
key_vault_uriproperty or calculating the URI without an API call based on theenvironmentconfigured in the provider and the vault name (https://docs.microsoft.com/en-us/azure/key-vault/general/secure-your-key-vault#resource-endpoints) to support cross-subscription scenarios. I'm happy to work on either approach myself and submit a PR if you'd like.