Support for setting AZURE_CONFIG_DIR variable for AzureCLICredential via AzureCLICredentialOptions

[juljaeg]

Feature Request

To better support multiple azure cli instances separated using the AZURE_CONFIG_DIR this variable should be passable using the options. It should be set when interacting with the azure cli.

In the long shot this will enable better integration with e.g. terraform provider and the azure cli when using multiple service principals logged into the azure cli but also in other automation processes.

The variable can be injected here:

azure-sdk-for-go/sdk/azidentity/azure_cli_credential.go

Line 144 in 9f4c149

cliCmd.Env = os.Environ()

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[chlowell]

Just to make sure I understand, you want to write code like this:

cred, err := azidentity.NewAzureCLICredential(&azidentity.AzureCLICredentialOptions{
	ConfigDir: "~/.config/azfoo",
})

and then we'd set AZURE_CONFIG_DIR for the az subprocess with the value of that field?

[juljaeg]

Yes, exactly :)

[chlowell]

🤔 off the top of my head the only potential problem I see with adding this option is that it depends on the credential acquiring tokens from a subprocess, because the underlying Azure CLI feature is controlled by an environment variable. The subprocess is an implementation detail today. I'm wary of making it an implicit part of the API because we could someday develop a better way to get tokens from the CLI, and I wouldn't want to choose between that and this option.

Can you share some details about the scenario this option would enable? You can of course set AZURE_CONFIG_DIR before running your Go program, so the unsupported feature here is instances of AzureCLICredential referencing different config files. What's blocked without that feature and how painful is it to work around its absence?

[juljaeg]

Thanks for your response and feedback 😀 Well for the use-case I have to take the long route and cover some technologies when explaining how this feature request became a viable solution for our problem:

We are doing infrastructure deployments to azure and additionally to aks using terraform and the azurerm/kubernetes provider. We are doing this over Azure Pipelines and are authenticating using service connections configured with service principal and their secret key. We have multiple service principals e.g. per subscription/purpose.

From time to time some deployments are spanning multiple subscriptions to e.g. open firewall rules, configure something else or put e.g. vnet peerings. For that we are spinning up multiple instances of the azurerm provider using the alias feature of terraform and just give it the different service principal credentials so that we can work with multiple service principals at the same time. We extract the credentials from the service connection in the pipeline using the given example for the AzureCLI task in the documentation.

We are currently migrating to workload identity federation as advertised by Azure DevOps to make the credentials mangement more future proof. We are executing our deployments using a couple of terraform applies in one pipeline step which might take some time when there is e.g. an aks to create or some database to provision. The id tokens offered by Azure DevOps and extracted as described above are valid for only 10 minutes. This leads to authentication issues when following terraform applies in the same step try to use the previously extracted - but now invalid - id token.

HOWEVER we noticed that when doing an az login beforehand using the id token and point terraform to use the azure cli (internally this uses this sdk) we can authenticate more reliably and for longer amount of times, as it also automatically refreshes the acces token. I am not aware of any way to sign into azure cli with multiple identities at the same time besides using a different config directory, which resulted in this feature request: Being able to make the azure go sdk azure cli credentials account for different config directories to enable using the refresh and access token capabilities after logging in using a short lived id token. And all this from one process.

I hope everything was understandable and one can follow the explanation. If there are any further questiond please just ask :) Of course we encounter the same problem with other tools like e.g. kubelogin, but they all use the sdk at its core.

For your concern regarding a potential future implementation: I can not give a fully valid opinion on this as I dont have every view on this topic, BUT I see config/instance separation as an essential feature for azure cli installations. Its inherently a part of how the/a CLIs concept imo. So a future implementation might just change the technical way how you get the token but a similar conceptual mechanism will very likely remain. Maybe there is a way to mark this as experimental or in the future provide a backwards compatible parameter name/structure?

What do you think? If you have any alternatives feel free to bring them up :)

[chlowell]

Thanks for all the details! Let me summarize to make sure I understand what you're trying to do (please correct my mistakes):

• you're deploying ARM resources in an Azure DevOps Pipeline
• you tried using a service connection authenticated with workload identity federation
  • I guess you didn't use azidentity for this because it isn't directly supported? (though I think you could do it with ClientAssertionCredential)
• the OIDC token provided by the Pipeline, which you exchange for access tokens, expires after 10 minutes
• this is a problem because a task sometimes needs an access token after 10 minutes have passed
• as a workaround you acquire access tokens from the Azure CLI instead
  • ...which doesn't impose a time limit because it authenticates with a long-lived secret

Service connections look like the right approach, if not for the 10 minute limit. There may be a caching solution. Within 10 minutes, can your tasks determine all the Azure service APIs they will need to access?