Terraform-provider-azurerm: plan fails without Azure CLI login

Created on 13 Feb 2020  ·  3Comments  ·  Source: terraform-providers/terraform-provider-azurerm

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

Problem manifesting in this version as an error:

Terraform v0.12.10
+ provider.azurerm v1.35.0
+ provider.null v2.1.2

However in this version (and all versions starting with v1.37.0), it manifests as a hang:

Terraform v0.12.20
+ provider.azurerm v1.44.0
+ provider.null v2.1.2

Affected Resource(s)

*azurerm_resource_group
*azurerm_storage_account
*azurerm_storage_container
*azurerm_virtual_network
*null_resource

Terraform Configuration Files

Problem manifests using both of the below methods:

provider "azurerm" {
  subscription_id = var.SubscriptionId
  tenant_id       = var.TenantId
  client_id       = var.ClientId
  client_secret   = var.ClientSecret
}

and:

provider "azurerm" {
  subscription_id = var.SubscriptionId
  tenant_id       = var.TenantId
  use_msi         = var.UseMSI
}

Actual Behavior

Starting on or about 2/7/2020, with no changes to our Terraform templates or versions, "terraform plan" started failing in the followings ways:

1) Using 1.35.0, with subscription_id/tenant_id/client_id/client_secret:

Error: Unable to list provider registration status, it is possible that this is due to invalid credentials or the service principal does not have permission to use the Resource Manager API, Azure error: azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request to https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx/providers?api-version=2016-02-01: StatusCode=0 -- Original Error: adal: Failed to execute the refresh request. Error = 'Post https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/oauth2/token?api-version=1.0: x509: certificate signed by unknown authority'

2) Using 1.35.0, with subscription_id/tenant_id/use_msi=true

Error: Unable to list provider registration status, it is possible that this is due to invalid credentials or the service principal does not have permission to use the Resource Manager API, Azure error: resources.ProvidersClient#List: Failure sending request: StatusCode=0 -- Original Error: Get https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx/providers?api-version=2016-02-01: x509: certificate signed by unknown authority

3) Using 1.37.0 or later:

"terraform plan" hangs indefinitely

Important Factoids

The problem was unaffected by any of the following:

  • Generating new client_secret
  • Setting skip_provider_registration="true"

The problem was resolved by installing the Azure CLI and doing an "az login". (Because we're running Terraform in an Alpine container, the official installer fails, but I had luck using the instructions here).

Possibly Related Issues

This sounds like it could be related, but I'm still seeing the issue in 1.44.0:

authentication question

Most helpful comment

hi @lubars

Thanks for opening this issue.

From memory Alpine Linux contains a subset of the necessary Certificate Authorities required to validate other SSL Certificates - which is why you're seeing the x509: certificate signed by unknown authority since the Azure Certificate cannot be verified). It's possible the Azure CLI is aware of Alpine Linux and handles this (I'm unsure) however unfortunately this isn't something we're able to fix within the Azure Provider (and as such I'm going to close this issue for the moment) - however you should be able to resolve this by adding the certificates needed to validate this to the container (an example of how to do this can be found here).

Thanks!

All 3 comments

hi @lubars

Thanks for opening this issue.

From memory Alpine Linux contains a subset of the necessary Certificate Authorities required to validate other SSL Certificates - which is why you're seeing the x509: certificate signed by unknown authority since the Azure Certificate cannot be verified). It's possible the Azure CLI is aware of Alpine Linux and handles this (I'm unsure) however unfortunately this isn't something we're able to fix within the Azure Provider (and as such I'm going to close this issue for the moment) - however you should be able to resolve this by adding the certificates needed to validate this to the container (an example of how to do this can be found here).

Thanks!

@tombuildsstuff Adding ca-certificates did the trick! Thank you -

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!

Was this page helpful?
0 / 5 - 0 ratings