A key use case for Variable Sets is the ability to define a set of environment variables that the Azure Provider can use to authenticate with Azure Resource Manager. I am in the process of refactoring some TFC Workspace configurations to use a Variable Set for these credentials instead of Variables defined on the Workspace itself.
My Azure Provider cannot authenticate to Azure RM when the ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_SUBSCRIPTION_ID and ARM_TENANT_ID environment variables are defined in a Variable Set and applied to my Workspace. The following error is displayed:
Terraform v1.6.1
on linux_amd64
Initializing plugins and modules...
Planning failed. Terraform encountered an error while generating this plan.
╷
│ Error: unable to build authorizer for Resource Manager API: could not configure AzureCli Authorizer: could not parse Azure CLI version: launching Azure CLI: exec: "az": executable file not found in $PATH
│
│ with provider["registry.terraform.io/hashicorp/azurerm"],
│ on main.tf line 13, in provider "azurerm":
│ 13: provider "azurerm" {
│
╵
Operation failed: failed running terraform plan (exit 1)
When I define the same environment variables as Workspace Variables, the authentication is successful and my Azure Provider is able to do its thing.
Versions used
~ terraform version
Terraform v1.6.1
on darwin_amd64
+ provider registry.terraform.io/hashicorp/azurerm v3.76.0
Posting here because im using the free tier of TFC. Can anyone offer any tips or pointers to try and resolve this?
It’s tough to say what might be going on here since I can’t see how you’ve configured things, but here are two possible ideas in the hope that one will be a good start in diagnosing this:
Variable sets can include both “terraform variables” (like you might declare with variable blocks in the root module) and “environment variables”. Providers expect to receive settings like this as environment variables, so you must be sure to choose that option when you create the variable set.
The precedence rules for different variable sets and the direct configuration for a workspace are quite subtle. I suggest checking carefully that you have assigned the variable set containing these values, that there are no other variable sets that might be overriding them, and that there are no entries in your direct workspace settings that might override them.
I’m sorry I can’t offer anything more specific at this point! But if you dig in to both of those and share what you learned then maybe we can follow the trail.
Thanks for the followup @apparentlymart. Let me respond to your points/questions.
I have a single Variable Set. It contains the four variables required for the Azure RM client. The variables are defined as env variables. This Variable Set is assigned to the Workspace.
I have dived into the precedence rules carefully, prior to this post, to understand them. There are no other Variable Sets assigned to the Workspace in question. I have reviewed the Workspace settings to ensure that there are no other Variables overriding the variables from the Variable Set.
I did some triage work to try and isolate the issue following my post.
If I create the four Variables directly on the Workspace, without the Variable Set assigned, the Azure Client behaves as expected and TFC is able to auth with the Azure RM API.
If I create the four Variables directly on the Workspace, WITH the Variable Set assigned, the Azure Client behaves as expected (it can login) and TFC is able to auth with the Azure RM API. The Workspace variables page displays the Variables in the Variable Set as shown in this picture.
Interestingly, if I rename one of the Workspace variables like this (note the DIS_ARM_CLIENT_ID)
So, based on this, any thoughts about what else to do to try and isolate this? Without an official support mechanism in place I dont really have any way to officially raise this as a proper bug with TFC.
a few hours later
I have tried to isolate this behaviour/issue a little further. The following Variables configuration on the Workspace produces a working Azure client authentication.
If I delete the sensitive Workspace Variable named ARM_CLIENT_SECRET, the same Variable in the Variable Set becomes active and the Azure client authentication fails.
some more time later
Just confirming the behaviour im seeing here.
When the ARM_CLIENT_SECRET variable is defined as a Workspace Variable, the Azure client authentication succeeds.
When the ARM_CLIENT_SECRET variable is defined as part of a Variable Set which is applied to the Workspace, the Azure client authentication fails.
In my TF code which defines the Variable Set and the Variables it contains, I was not putting the actual value into the ARM_CLIENT_SECRET Variable. It was left blank. On purpose. With the intent that the operator would use the TFC GUI to add the secret value to the Variable in the Variable Set. That GUI part was never done, hence, when the Variable Set was used for Azure Client authentication, it was trying to auth with a blank secret.
