Support `AZURE_CLOUD` environment variable for connecting to Azure Government

[mattwelke]

Feature Request

Background

I found references online to being able to set an AZURE_ENVIRONMENT to control which cloud the SDK connects to. And you could use this to tell the SDK to connect to Azure Government.

I found content in this repo's docs about this too but it's marked as legacy.

When I tested this manually, it didn't seem to work. I wasn't able to set the env var to a value that caused it to connect to any host other than management.azure.com.

Request

It would be helpful if the SDK supported the environment variable so that it can be set to the name of the cloud to be connected to. This would mean less need to write code to make the SDK connect to the desired cloud.

Workaround

My workaround for this is to manually configure it via the options struct with added code.

First, create a credential like you would when connecting to the public Azure cloud instead of Azure Government.

cred, err := azidentity.NewDefaultAzureCredential(nil)

Then, use the credential alongside an options structs where the desired cloud is selected. This works for both the approach where you instantiate a factory and then instantiate clients from it and the approach where you instaniate clients directly. Here's a factory example where a resource groups client is instantiated from the factory.

opts := azcore.ClientOptions{Cloud: cloud.AzureGovernment}
clientFactory, _ := armresources.NewClientFactory(<subscription ID>, cred, &arm.ClientOptions{
	ClientOptions: opts,
})
resourceGroupsClient = clientFactory.NewResourceGroupsClient()

https://stackoverflow.com/questions/78872532/how-can-i-connect-the-azure-go-sdk-to-azure-government/78872533

This is easy in new projects but more tedious to do in projects where you have already created multiple components that talk to each other via env vars. With env var support, env var values can be propagated through such systems without code changes required in the component that uses the Azure Go SDK.

[tadelesh]

@jhendrixMSFT could you help to evaluate this feature ask?

[dtrejod]

I believe AZURE_ENVIRONMENT was the envvar supported by the older azure/go-autoreset SDK. You can see AZURE_ENVIRONMENT was documented in these docs: https://learn.microsoft.com/en-us/azure/developer/go/azure-sdk-authorization#use-environment-based-authentication

I think azure sdks support an AZURE_CLOUD envvar which essentially is a drop in-replcement for the old envvar. The AZURE_CLOUD envvar is documented in the generic azure-sdk docs here: https://github.com/Azure/azure-sdk/blob/main/_includes/tables/environment_variables.md

So I think the ask for this github issue is that the azure-sdk-for-go support the AZURE_CLOUD envvar?

[mattwelke]

So I think the ask for this github issue is that the azure-sdk-for-go support the AZURE_CLOUD envvar?

If this env var is the new one that's meant to replace the old one across SDKs, definitely. That would be the one that I would like supported.

I can give it a test with AZURE_CLOUD if you want. Or are you saying that as far as we know, the base repo it isn't supported yet in azure-sdk-for-go?

[dtrejod]

I can give it a test with AZURE_CLOUD if you want. Or are you saying that as far as we know, the base repo it isn't supported yet in azure-sdk-for-go?

I'm not associated with microsoft. Just saw this issue and ran into the same confusion myself as the azure-sdk-for-go doesn't appear to support any envavars for discovering cloud name.

Let's wait for MS to chime in on AZURE_ENVIRONMENT vs AZURE_CLOUD.

[jhendrixMSFT]

AZURE_CLOUD is indeed the replacement. However, we've not yet implemented support for this (I don't believe the other SDKs have either). As for when, I'm not really sure. Will discuss internally and update when we have more info.

[EronWright]

Probably the biggest value-add of the "environments" feature of autorest is that it knows the default service endpoints and prefixes, e.g. for MS Graph, KeyVault, etc. Since https://github.com/Azure/go-autorest/issues/734 links here, it is reasonable to ask what the scope of the new feature would be and whether it would handle endpoint discovery.