Ability to select different Azure clouds

[wbreza]

Today Azd assumes the use of Azure public cloud. Add ability to select other clouds like govt cloud, Azure China, etc.

[jrudley]

Any update when we can select Azure Gov cloud?

[savannahostrowski]

@ellismg @rajeshkamal5050 Would be good for us to do a preliminary investigation to get a sense of the level of effort here/if there would be any UX changes required to support gov cloud (e.g. introduction of new prompts, etc.). Could we spike in August/September?

[danieljurek]

A few things came up in local testing against Gov Cloud... Azure Stack will require separate testing:

1. The az CLI app id seems to be the same across the clouds so I don't think it needs to change.
2. Using az (legacy) auth provides tokens (after setting the cloud using az cloud set --name) so you can authenticate
   1. Auth outside of the az CLI needs changes to auth manager
3. Deployment to app service has a hardcoded URL that should change based on the cloud environment (other deployment methods may have similar issues... testing will help find those here)

Running az cloud list locally will give an idea of some of the URLs which are different (note: app service isn't among those, perhaps we should use outputs from the deployment or ARM to figure that URL out?).

Supporting US Gov Cloud and China Cloud should be more straightforward as those have existing configurations ... Looks like service-specific values are populated at runtime based on the module being used. However, an instance like Azure Stack may require more explicit configuration. We'd need an Azure Stack test environment to ensure that this is done correctly.

Thoughts on implementation:

Well-known sovereign cloud support is pretty straightforward, but a user on Azure Stack would need to bring their own set of endpoints and domain suffixes (see az cloud list for an idea of what would need to be provided).

Config should allow for a user to specify the name of the cloud (e.g. AzureUSGovernment) or, to support Azure Stack, specify the particular set of endpoints (see az cloud list). How we specify endpoints for things like App Service should probably happen at runtime on the resource as opposed to a hardcoded string or configurable variable.

[danieljurek]

Chatting with @wbreza:

Places config could live:

• ~/.azd/config.json (set by azd config set)
• azure.yaml (per-project configuration)
• <project>/.azure/<environment name>/config.json

Feature should look like:

• Set the target cloud by setting a name
• Allow overrides for endpoints/suffixes (see az cloud list)

Support all places where config could be provided (see list above)

MISC

• Fetch deployment URLs from resources (e.g. app service)
• Get cloud name from environment variable (just cloud name, no endpoint/suffix configs)

Other things to consider:

• Endpoint overrides for remote environments (defaults to public cloud today, user can specify endpoint using a config)
• Commands not impacted
• Ensure eastus2 default is only for public cloud (do we want to do defaults for sovereign clouds?)

Open questions:

• Do clouds vary based on environment? (e.g. use public cloud for dev, use gov cloud for staging/prod)

Notes:

• Look at ADE branch for examples of configs (like platform.go)

[danieljurek]

Ensure that the azd AAD Client ID is consistent across the clouds.

[danieljurek]

Also, the auth experience when switching among clouds is not smooth.

Current approach:

1. Set cloud A
2. azd auth
3. Do azd things in cloud A
4. Set cloud B
5. azd auth
6. Do things in cloud B
7. Set cloud A
8. azd auth <--- This step is extra because auth is not saved between clouds
9. Do azd things in cloud A

The approach that the az CLI takes is that auth is persisted across clouds so one's workflow looks like:

1. Set cloud A
2. az login
3. Do things in cloud A
4. Set cloud B
5. az login
6. Do things in cloud B
7. Set cloud A
8. Do things in cloud A

(note how step 8 in the az CLI doesn't require running az login)

To do this we'll need to associate auth information with clouds and then retrieve the appropriate auth given the cloud requested. This would make it easier to, for example, switch between clouds when deploying to different "environments" like public for "beta" and sovereign cloud for "prod"

[rajeshkamal5050]

https://devblogs.microsoft.com/azure-sdk/azure-developer-cli-azd-march-2024-release/#sovereign-cloud-support