az login support for Azure AD workload identity with Azure Kubernetes Service

[arsnyder16]

Related command
az login

Is your feature request related to a problem? Please describe.
Currently if using workload identity and azure cli, az login must be specifically configured for login

Describe the solution you'd like
similar to az login --identity, maybe something like az login --workflow-identity
Describe alternatives you've considered
You can work around it currently using
az login --federated-token "$(cat $AZURE_FEDERATED_TOKEN_FILE)" --service-principal -u $AZURE_CLIENT_ID -t $AZURE_TENANT_ID

Additional context
For the client libraries a specific class is available WorkloadIdentityCredential

More generally it would be nice if az login had a way to use something similar to DefaultAzureCredential which would allow scripts to be more portable depending on execution context

[yonzhan]

Thank you for opening this issue, we will look into it.

[RickardTaran]

Same issue, thanks for posting a workaround! Hope to see this fixed

[jiasli]

A similar feature request has been raised for Azure PowerShell: Azure/azure-powershell#22213

• MSAL Python supported client_assertion with JWT in Add support for acquiring a token with a pre-signed JWT AzureAD/microsoft-authentication-library-for-python#271
• Azure CLI supported --federated-token in az login in [Core] ADAL to MSAL migration #19853
• Azure Identity Python implemented WorkloadIdentityCredential in Token exchange support for ManagedIdentityCredential  azure-sdk-for-python#19902. Azure Identity Python doesn't utilize MSAL for making the token exchange request. Instead, it developed its own implementation.

Supporting workload identity requires reading from these environment variables:

• AZURE_AUTHORITY_HOST
• AZURE_CLIENT_ID
• AZURE_TENANT_ID
• AZURE_FEDERATED_TOKEN_FILE

(Documented at https://azure.github.io/azure-workload-identity/docs/quick-start.html?highlight=AZURE_FEDERATED_TOKEN_FILE#7-deploy-workload)

The AKS document https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview#microsoft-authentication-library-msal provides samples that directly use MSAL for workload identity authentication. For example, the MSAL Python sample reads values from environment variables first:

https://github.com/Azure/azure-workload-identity/blob/a5fc57dd72e5fe2d85a21072d47eb3aa2b316407/examples/msal-python/main.py#L9-L12

    azure_client_id = os.getenv('AZURE_CLIENT_ID', '')
    azure_tenant_id = os.getenv('AZURE_TENANT_ID', '')
    azure_authority_host = os.getenv('AZURE_AUTHORITY_HOST', '')
    azure_federated_token_file = os.getenv('AZURE_FEDERATED_TOKEN_FILE', '')

Then it uses the same mechanism as Azure CLI - creating ConfidentialClientApplication instance with client_assertion:

https://github.com/Azure/azure-workload-identity/blob/a5fc57dd72e5fe2d85a21072d47eb3aa2b316407/examples/msal-python/token_credential.py#L14-L20

        self.app = ConfidentialClientApplication(
            azure_client_id,
            client_credential={
                'client_assertion': f.read().decode("utf-8")
            },
            authority="{}{}".format(azure_authority_host, azure_tenant_id)
        )

Azure CLI's code:

azure-cli/src/azure-cli-core/azure/cli/core/auth/msal_authentication.py

Lines 127 to 132 in 21266e0

	# client_assertion
	client_assertion = getattr(service_principal_auth, _CLIENT_ASSERTION, None)
	if client_assertion:
	client_credential = {'client_assertion': client_assertion}
	super().__init__(service_principal_auth.client_id, client_credential=client_credential, **kwargs)

The workaround provided in the issue description is the right path. In order for Azure CLI to natively support workload identity, it has to read those environment variables as the workaround does. But, we still need to work with MSAL team to decide whether this logic should be done by Azure CLI or MSAL.

A prerequisite is to support environment credentials first: #10241

[wba-josh-hetland]

I'm interested in this as well, for the use case i am interested in, it would be to host azure devops agents in a k8s environment and use the workload identity for the service connection vs having to script this out and tightly couple the pipeline tasks to its hosting environment