Support Azure Workload Identity for Microsoft Entra SSO

[Bailey-T]

Summary

When using Microsoft Entra (Azure AD) for SSO, the steps call for a CLIENT_ID and CLIENT_SECRET:
https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/microsoft/

and the OIDC code, only seems to allow for lookup for the CLIENT_SECRET via the argocd-cm configMap:

argo-cd/util/oidc/oidc.go

Line 105 in 1c938e2

clientSecret: settings.OAuth2ClientSecret(),

However, "Workload Identity" is a valid authentication pattern for Entra Applications, especially when using AKS:
https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust?pivots=identity-wif-apps-methods-azp

Generally this mounts a short lived JWT token to the given container, and creates an ENV entry to point to the location $AZURE_FEDERATED_TOKEN_FILE (this often defaults to /var/run/secrets/azure/tokens/azure-identity-token)

This would probably apply to DEX as well, but due to it requiring excessive permissions is not in use by us.

Motivation

Workload Identity is generally considered the best approach for Entra/AzureAD as it doesn't require the exchange or storage of secrets. I believe the other major CSPs also offer similar functionality for their managed K8s platforms as well.

Proposal

Something like:

• An optional AzureFederatedIdentity flag in $argocd-cm:data.oidc.config to allow for lookup of the token value in $AZURE_FEDERATED_TOKEN_FILE

[avo-sepp]

Since many orgs require very short-lived client-secrets, this enhancement is especially valuable. Enabling our teams to move away from manually rotating client-secrets every n days.

[imjoseangel]

+1