Support for Azure AD workload identity

[rouke-broersma]

Summary

More and more cloud providers are supporting the concept of workload identity. I believe this is also already supported in argocd for GCP. It would be great if ArgoCD also implemented the token exchange for azure.

Motivation

This would allow for password-less authentication with remote-clusters but also azure devops repositories and azure container registry (helm charts).

See:

• https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/service-principal-managed-identity?toc=%2Fazure%2Fdevops%2Fmarketplace-extensibility%2Ftoc.json&view=azure-devops
• https://learn.microsoft.com/en-us/azure/aks/workload-identity-overview
• https://github.com/AzureAD/microsoft-authentication-library-for-go

Proposal

Support for kubelogin would already satisfy password-less authentication with k8s clusters (#9460 && #10700) To complete workload identity support repositories need an implementation of an AzureCreds which probably uses MSAL for token exchange. This could be used by both git and helm repos because both now support service principal and managed identity with federated credentials.

Since more and more cloud providers are adding support for workload identity it might make sense to design a shared authentication package implementing workload identity token exchange which can be implemented for specific cloud providers and can be shared by different parts of argocd that need to implement this authentication. This would make it easier to add support for workload identity across the board, since currently you would need to implement the token exchange for cluster access and repo access separately.

[tibers]

Workaround for the poor souls who found this through google and are stuck in the same place:

export ACR_NAME="targetacr"
# The username of the TARGET account
export USER_NAME="argocd-helm-token-$ACR_NAME"
# Creates a token
export PASSWORD=$(az acr token create -n $USER_NAME \
                  -r $ACR_NAME \
                  --scope-map _repositories_pull \
                  --only-show-errors \
                  --query "credentials.passwords[0].value" -o tsv)
# add the repo to argo
 argocd repo add $ACR_NAME.azurecr.io/helm --username $USER_NAME --password $PASSWORD --enable-oci --type helm --name helm --project default

[fbueno]

I have the same issue, but doing what @tibers suggested works, however only for a few hours. It requires new password from time to time. Any idea how to avoid that?

[tibers]

I have the same issue, but doing what @tibers suggested works, however only for a few hours. It requires new password from time to time. Any idea how to avoid that?

Your organization probably has some sort of policy or enforcement mechanism which is preventing you from having a token that never expires. Per the docs, the token should not expire unless you explicitly set that.

[dchittibala]

I have been using External secrets as an alternative to circumvent this problem. hope this helps

[EppO]

that would be great to have, having to manage the secrets to access git repos or helm chart registries (and their expiration when dealing with tokens) is quite a pain

[avo-sepp]

This is supported for AKS Cluster Administration, see docs here

I have not seen it supported for Azure DevOps Repositories and Azure Container Registries yet. Which would be a nice addition. One account to rule them all.

EDIT: We use External Secrets Azure Container Registry generator to create docker pull keys for ArgoCD. That works very well and refreshes the tokens automatically.

[cveld]

Has work already been started to allow for workload identity based federation against azure repos? I am not too familiar yet with the argocd architecture, but maybe we can leverage the service account of the argocd pod to provide federated access. Thus far we were using ssh rsa sha1 keys and due to azure repos' deprecation of sha1 and the relating browning out, I became aware that we have these git repo secrets in our argocd config. Would be great to move to secretfree auth.

[ebuildy]

Password less auth with JWT token is the futur!

I love what argo team have done for image updater project:

https://argocd-image-updater.readthedocs.io/en/stable/basics/authentication/#using-a-script-to-generate-credentials

Example with Azure:

We can copy code from https://github.com/argoproj-labs/argocd-image-updater/issues/473

Please copy/paste this into argocd!

[omaraladin]

I hope Argoteam considers this, since AKS already created with a system-assigned managed identity, Argocd can work on leveraging Azure AD authentication

[cveld]

@omaraladin well workload identity is even more powerful. Service accounts become token providers and with federation configured on the azure managed identity you can request an entra id token with a service account token.

As this provides much more granularity and a security boundary colliding with your pod, you should not use the cluster's system identity but prefer workload identity.

[cveld]

I have started exploring the argocd repo. I am motivated to implement this feature request. I don't have much experience with golang, let alone the argocd repo. I'll ask some questions on the cncf Slack in the #argo-cd-contributors channel.

My current plan is to leverage the argocd-k8s-auth command that can be configured to be executed as part of an aks cluster connection directed by the property execProviderConfig. We need to extend Repository and RepoCreds structs so that we can instruct argocd to make the call to argocd-k8s-auth.

I have also seen gcpServiceAccountKey for google cloud repositories which seems very related to the oidc federation flow argocd-k8s-auth is providing.

[pascal-kratz]

@cveld

Would you be able to implement workload identity support for Entra ID (Azure AD) SSO as well? All options for configuring SSO (Dex and OIDC) require either a certificate or a secret, and it would be great to eliminate the possibility of expiring secrets or certificates.

https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust?pivots=identity-wif-apps-methods-azp#kubernetes

[cveld]

@pascal-kratz I believe connecting with kubernetes with aks workload identity is already supported through the kubelogin plugin: https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#aks

[rouke-broersma]

@pascal-kratz I believe connecting with kubernetes with aks workload identity is already supported through the kubelogin plugin: https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#aks

That's for kubectl not for sso with argocd.

[cveld]

@rouke-broersma now I get it! I will look into it when I have time.

[dewolfs]

Please consider to bring this feature request higher in the roadmap. Practicing GitOps with long standing secrets is counterintuitive which bring operational overhead.