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
*azurerm_resource_group
*azurerm_storage_account
*azurerm_storage_container
*azurerm_virtual_network
*null_resource
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
}
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
The problem was unaffected by any of the following:
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).
This sounds like it could be related, but I'm still seeing the issue in 1.44.0:
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!
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 authoritysince 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!