-
Notifications
You must be signed in to change notification settings - Fork 244
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
Could not get tags from Google Artifact Registry #579
Comments
We are also running into this issue after migrating from GCR to Artifact Registry. @jannfis This is going to need to be patched anyway for the merge to ArgoCD, and with GCR being sunset in favour of Artifact Registry. If I was to take the time to submit a PR patching this, would it get merged? |
Same here with WorkloadIdentity enabled from within GKE cluster:
Another pod with |
Ran into the same issue with the latest version of Argo (following this bug). Looking in the logs, the identity is not passed to the
Also a bit odd to see
|
We've also encountered this issue after switching to Artifacts Registry. Did anyone find a solution to this yet? Update: My solution was to update the configMap as follows:
In my case, we use a script for authentication using workload identity, but it should also work if you create a service account key file, package it into a secret and reference it as shown in the documentation.
|
Thx @ralphotowo for pointing me to the right answer. Works for me now. For everyone else using WorkloadIdentity one hint which cost me some hours of investigation and head-on-the-table-moments: A script getting an token from the metadata api eg. So to be clear: Hope this helps. |
Thanks @jaykay !
Now I need to figure out how to incorporate this into my ArgoCD configuration. |
I have the same issue but with helm charts instead of the docker images, so I guess I can not use the |
I finally seem to have figured it out by debugging the oras-go client. It turns out the provided credentials in the Repository setting where not used because oras-go compares the target with the registry to see if it can use they match. If they do not match - chart: my-repository/my-helm/my-x
repoURL: europe-docker.pkg.dev Which just feels wrong. Should I create another issue for this? I am guessing it's the same exact case for the argocd-image-updater? I have not checked though. |
@stefangluszek Thank you for the details!
Did you manage to configure ArgoCD Image Updater to make it working with container images (not Helm charts) stored in GAR? Could you please share your solution? |
Nevermind, I found the solution here: #319 (comment) (thanks to @bkanuka! 🎉 ) In case if ArgoCD Image Updater is installed using a Helm chart, the setup for GAR auth via Workload Identity will look like this (example of your custom helm values for argocd-image-updater chart): # values.yaml
config:
registries:
- name: Google Artifacts Registry - eu-west1
api_url: https://europe-docker.pkg.dev
prefix: europe-docker.pkg.dev
credentials: ext:/scripts/gke-workload-identity-auth.sh
credsexpire: 30m
authScripts:
enabled: true
scripts:
gke-workload-identity-auth.sh: |
#!/bin/sh
ACCESS_TOKEN=$(wget --header 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token -q -O - | grep -Eo '"access_token":.*?[^\\]",' | cut -d '"' -f 4)
echo "oauth2accesstoken:$ACCESS_TOKEN"
|
thank you very much @legal90 you save my time. |
@legal90 You saved me at least a day's work messing around with this, thank you! |
@legal90 Thanks for your solution here. I have added this to my helm chart because I'm trying to get this argocd-image-updater but am still hitting this issue: denied: Permission "artifactregistry.repositories.downloadArtifacts" denied on resource "projects/t-computer-410410/locations/europe-west4/repositories/boutique-app" (or it may not exist) When I exec into my argo-cd-image-updater pod I can't see a /scripts directory which I'm assuming the script should get mounted to. I've checked other things like the permissions on my SA itself and that is set to Artifact Registry Owner, along with the annotation on my GKE SA to map it to my GCP IAM one. Do I need to mount a volume as mentioned here by @bkanuk: #319 (comment) ? |
Figured this out - I had to delete the whole deployment and not just the pod for this to show in the containers file system. But when I use your script to get an access token, it retrieves a much longer token which doesn't work when accessing my registry: I've changed these tokens so they won't work ;) But does anyone know why the shorter token would work, but the longer one would give a permission issue?? |
In the script, the command used for token invocation (wget --header 'Metadata-Flavor: Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token) is exploiting an API call. It achieves two things:
On the other hand "gcloud auth print-access-token" command doesn't directly interact with an API endpoint. It utilizes the Google Cloud SDK libraries installed on your local machine to fetch and print an access token. So In essence, there's no single API endpoint involved. The gcloud tool and the local SDK libraries handle the entire process of fetching and printing the access token using established Google Cloud authentication mechanisms. I hope this sheds some light on the matter. |
Example for multiregion
I wrote an article here with more instructions in case someone needs further troubleshooting, I hope it saves you time since I didn't find a comprehensive resource for authenticating |
Describe the bug
argocd-image-updater is unable to get the tag list from Google Artifact Registry.
Behaviour can be reproduced running the binary locally or on Kubernetes.
Getting the image tags list using the podman CLI ( podman image search --list-tags ) returns the expected results.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The tag list is successfully fetched.
Version
local: v0.12.2
k8s: quay.io/argoprojlabs/argocd-image-updater:v0.12.0
Logs
From the Kubernetes pod:
The text was updated successfully, but these errors were encountered: