Terraform-provider-azurerm: CLI auth does not work with Key Vaults secrets

[mattops]

Whilst trying to manage key vault secrets, using CLI auth, getting:

* module.my_mod_instance.azurerm_key_vault_secret.my_secret_name: azurerm_key_vault_secret.my_secret_name: Error making Read request on Azure KeyVault Secret my_secret_name: keyvault.ManagementClient#GetSecret: Failure responding to request: StatusCode=401 -- Original Error: autorest/azure: error response cannot be parsed: "" error: EOF

getting this in the DEBUG logs:

e.g.
TF_LOG=DEBUG terraform apply

2018-01-02T14:11:47.804Z [DEBUG] plugin.terraform-provider-azurerm_v1.0.0_x4: 2018/01/02 14:11:47 [DEBUG] Resource "https://vault.azure.net" isn't a management domain

This is related to this line of code:

https://github.com/terraform-providers/terraform-provider-azurerm/blob/1005762a37e67f93aa340b40d1682f70523da61a/azurerm/helpers/authentication/access_token.go#L37

When managing azure key vaults, Azure needs the correct bearer token for the specific "Azure resource endpoints" - in this case it should be "https://vault.azure.net".

When managing secrets via the az cli - this is done transparently, but is effectively similar to:

az account get-access-token --resource https://vault.azure.net

This token then then permits access.

[mattops]

@tombuildsstuff any idea when this will get fixed?

[steve-hawkins]

this is not limited to just secrets in a key vault

I am also hitting this same error when managing certificates in a key vault

[kcighon]

is there currently a workaround?

[hafizullah]

just got slapped by this issue :(

[anoff]

Ran into the same issue while debugging locally. My workaround was using a service principal locally instead of az login

provider "azurerm" {
  # following ENV need to exist: ARM_SUBSCRIPTION_ID, ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_TENANT_ID
}

One other thing I missed is creating an access policy for the SP within the keyvault otherwise it won't be able to manage secrets. Seems to be common KeyVault behavior but I initially thought any IAM contributor can also manage secrets 🙄 If you deploy the keyvault itself via TF make sure the access policy is set automatically.

[hafizullah]

Thanks @anoff 👍 will give your workaround a try

[andrey-moor]

Same issue with the keys, any update on this?

[andrey-moor]

@tombuildsstuff is there any reason to make this check only for management domain?

if !strings.Contains(accessToken.Resource, "management") {
  log.Printf("[DEBUG] Resource %q isn't a management domain", accessToken.Resource)
  continue
}

If that's important does it make sense to create a list of allowed domains for now and the future platform features?

[donestefan]

Please keep in mind that there are multiple vault domains (like *.vault.microsoftazure.de for azure germany).

[tombuildsstuff]

@donestefan indeed - rather than hard-coding domain name suffixes we use the values from the Azure Environment (which contains, amongst other things - the API Base URI's & Domain Suffixes).

To give an update here: we're intending on getting to this - but I can't give an timeframe for fixing this at this point.

I took a quick look into this recently and the complexity comes with testing this (since CloudShell, the Azure CLI v1 [Node.JS] and the Azure CLI v2 [Python]) all return the same configuration file with a different schema, such that we need to manually test this in each environment (since the format can [and has in the past] changed). In the interim the workaround is to use a Service Principal, which whilst I realise isn't ideal - does provide a workaround for this issue for the moment.

Regarding prioritising this - if you'd like to see this implemented, we'd really appreciate a 👍 on the first post here - which we use to influence what we're working on (we tend to sort issues by the most 👍 when determining what should be prioritised).

Thanks.

[MarkWme]

I hit this issue today whilst working with data.azurerm_key_vault_secret whilst developing a terraform deployment locally on my Mac (Azure CLI 2.0.37, Terraform 0.11.7, azurerm 1.7.0) I found that using the Cloud Shell it worked fine, so just adding that as another potential workaround for folks hitting this issue.

[tombuildsstuff]

👋 hey all

Just to let you know that @sophos-jeff has contributed a fix for this in #1349 which fixes this issue. So that we can ship this in the next release I've split this out into PR #1544, (I hope you don't mind @sophos-jeff).

Thanks!

[marrik96]

Just ran into this issue. Looks like a fix was pushed? I'm on terraform v0.11.7 with Azure provider v1.8.0. Not clear if issues is fixed or if I'm doing something wrong. Working with secrets using "azurerm_key_vault_secret"

Thanks.

[tombuildsstuff]

hi @mattops @steve-hawkins @kcighon @hafizullah @anoff @marrik96 @MarkWme @donestefan @andrey-moor

Just to let you know that is now available in [v1.10 of the AzureRM Provider(https://github.com/terraform-providers/terraform-provider-azurerm/blob/v1.10.0/CHANGELOG.md#1100-july-21-2018) - which you can update to this version by specifying it in the Provider block, like so:

provider "azurerm" {
  version = "=1.10.0"
}

Thanks again @sophos-jeff :)

Thanks!

[hashibot[bot]]

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!