-
Notifications
You must be signed in to change notification settings - Fork 5.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Azure AD workload identity #13334
Comments
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 |
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. |
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. |
I have been using External secrets as an alternative to circumvent this problem. hope this helps |
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 |
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. |
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. |
Password less auth with JWT token is the futur! I love what argo team have done for image updater project: Example with Azure: We can copy code from argoproj-labs/argocd-image-updater#473 Please copy/paste this into argocd! |
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:
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.
The text was updated successfully, but these errors were encountered: