argocd-image-updater
argocd-image-updater copied to clipboard
running as service account in gcr
Is your feature request related to a problem? Please describe. running as service account in gke
Describe the solution you'd like get the account token if possible and use it to access gcr so we need to check if we can get the token with http request and if we do, we may use it to connect to gcr without putting any creads in config
(i think same may go for aws)
Describe alternatives you've considered workarond for now is to mount configmap as script and run it as ext:SCRIPT
configmap is like this:
data:
registries.conf: |
registries:
- name: Google Container Registry
api_url: https://gcr.io
prefix: gcr.io
ping: no
credentials: ext:/app/config/script.sh
credsexpire: 5m
script.sh: |
#!/bin/sh
echo "_token:$(wget -qO- "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" --header="Metadata-Flavor: Google" | cut -d"\"" -f 4 |rev | sed -rn 's/[.]*(.*)/\1/p' | rev)"
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
patchesJson6902:
- target:
group: apps
version: v1
kind: Deployment
name: argocd-image-updater
patch: |-
- op: add
path: /spec/template/spec/volumes/0/configMap/defaultMode
value: 0777
- target:
group: apps
version: v1
kind: Deployment
name: argocd-image-updater
patch: |-
- op: add
path: /spec/template/spec/volumes/0/configMap/items/2
value:
key: script.sh
path: script.sh
I do understand this requirement, but it will most likely not be implemented in the code. I am not very familiar with GCE, and also don't have a test bed for it. Can you just modify the manifests to run it as a GCE Service account?
What we may want to do instead is to ship the gcloud SDK CLI with the image, similar to how we ship the AWS CLI since 0.10.2.
Can you just modify the manifests to run it as a GCE Service account?
this does not help, unfortunately. even testing the executable locally shows it can't work w/ GCR (google container registry) with default GCP service account i'm logged in as.
What we may want to do instead is to ship the gcloud SDK CLI with the image, similar to how we ship the AWS CLI since 0.10.2.
google cloud sdk cli is quite heavy :/
google cloud sdk cli is quite heavy :/
AWS cli already adds 187MB to this container (python + awscli + dependencies) so it's not that far fetched if awscli is already there, but it's true that the image would grow comically after adding a couple of cloud tools. Maybe it's interesting to have a bunch of images with and without cloud tools, i.e. argocd-image-updater:0.12
and argocd-image-updater:0.12-gcp
or argocd-image-updater:0.12-cloud
.
this does not help, unfortunately. even testing the executable locally shows it can't work w/ GCR (google container registry) with default GCP service account i'm logged in as.
Seems like you could add a Workload Identity linked to a service account with GCR permissions and get the token for said WI to login into GCR. I'll be testing it on Monday as I'm right in the middle of configuing argocd-image-updater
.
The process is a bit convoluted first time you do it (at least today that I haven't had any coffee) , but some docs could help greatly. I can volunteer to those docs if I'm successful next week.
How do you feel about this, @jannfis ?
I've succesfully applied a workload identity to the deployment, and now it can query our Google Cloud Registry. I would to "translate" it, as we have that part made in Terraform with custom modules, but I could make a brief doc explaining the process.
The feature to pull the secret without the script would be very simple, but my golang habilities are... limited :grimacing: :D
Is there an accepted solution to this? The linked WI has the correct permissions, and the k8s serviceaccount can list images, but image-updater still cannot...
Have you seen this? I (and others) have been able to use Workload Identity with GKE to pull images: https://github.com/argoproj-labs/argocd-image-updater/issues/319#issuecomment-1130547057