[feature] Allow juju to bootstrap on Azure via managed identity credentials

[Diko Parvanov]

Seems the current auth types are interactive, service-principal-secret, but no way to use managed identity (https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview) - it would be good to have this option, as we do with IAM roles in AWS - where we don't have to manually manage credentials, but the applications themselves trying to interact with bootstrapping a juju controller on Azure can extract such via the metadata service in an instance.

This will be particularly useful when automating the bootstrapping of juju controller on Azure without any user intervention.

[John A Meinel (jameinel)]

As a feature, this gets put into Wishlist, but we are evaluating our roadmap and figuring out how we can pull this in.

[Ian Booth (wallyworld)]

Referencing the Juju AWS IAM support, can you confirm the workflow you would prefer to use?
Note: we would be reusing the term "instance-role" to refer to the managed identity name, since this is the name of the constraint attribute already chosen and constraint attributes are used across providers.

For AWS we support 2 workflows. So we could do the same for Azure...

1. Have Juju create a suitable managed identity similar to what we do AWS:

$ juju bootstrap --bootstrap-constraints="instance-role=auto" azure

2. Create a user assigned managed identity "foo" in resource group "myrg", assign permissions, then

$ juju bootstrap -bootstrap-constraints="instance-role=foo" --config resource-group-name=myrg azure

I guess you'd want to be able to use either workflow?

[Ian Booth (wallyworld)]

The other thing is that we already have a "Juju" Enterprise Application set up, with relevant roles defined. We could look at simply assigning the required role to the controller vms when they are provisioned (if "auto" is specified for the constraint). I am not 100% sure, but maybe this is all we'd need to do to allow a zero config ManagedIdentityCredential to be used by the controller to operate the cloud.

[Ian Booth (wallyworld)]

https://github.com/juju/juju/pull/17563

Note: as with AWS, we do not support bootstrapping from a jump host using a managed identity credential.
You still need to bootstrap the original controller with a "conventional" credential (for aws, that's key secret, for Azure, service principal).

After the original controller is bootstrapped, the user credential used to do the bootstrap is NOT copied to the controller - it remains on the user's machine. The controller vms all get attached to a user managed identity so they can do what they need to do.

As with AWS, trust and credential-get for charms will not be supported in this mode.

[Manthan Purohit (v-mpurohit)]

Hi, we also have the same requirement to use User Managed identity with Azure for Cluster provisioning of Canonical Cluster. We see that only Service Principals method is only available for authentication in the Public Documentation. Can you please add support to use Managed Identity as other option. We are blocked to setup juju cluster due to security constraint from Azure.

[Ian Booth (wallyworld)]

As per comment #4, and the bug status, the planned work for this feature has landed in the 3.6 branch. We expect to release 3.6 around end of July. Doc updates are in progress.

The linked PR describes the feature pending the doc being done.