argocd-image-updater icon indicating copy to clipboard operation
argocd-image-updater copied to clipboard

Pull secrets in multi-cluster environments

Open giftkugel opened this issue 10 months ago • 1 comments

Hey there,

I don't know whether this describes a bug, or a feature request. Hope someone can categorize this correctly. 🙈

We have issues to use ArgoCD Image Updater in a multi-cluster environment with pull secrets for a private container registry.

Current setup:

  • Kubernetes cluster a, with ArgoCD and ArgoCD Image Updater installed
  • Kubernetes cluster b, where ArgoCD applications are deployed
  • Resources in cluster a can access cluster b
  • A secret named regcred-b defined in cluster b (e.g. in the namespace example)

When defining an ArgoCD application, we are providing the name of the cluster where the Application should be deployed. Works as expected.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    argocd-image-updater.argoproj.io/image-list: container.foo.com:0.1
    argocd-image-updater.argoproj.io/pull-secret: pullsecret:example/regcred-b
  name: foo
  namespace: argocd
spec:
  ...
  destination:
    namespace: example
    name: b
  ...

In the deployed application on cluster b we are providing ArgoCD Image Updater annotations to define the image list, update strategy and of course a pull secret to fetch images from a private container registry.

argocd-image-updater.argoproj.io/pull-secret: pullsecret:example/regcred-b

Unfortunately the ArgoCD Image Updater tries to find the pull secret in the same cluster it is up and running, and not in the cluster the application is deployed to. So it tries to find it in cluster a not in cluster b.

We would expect ArgoCD Image Updater to look up the secret in the cluster where the application is deployed, as all related informations are located in that cluster (e.g pods, config maps, persisted volumes, etc.)

Or it should be possible (then this is a feature request) to define a pull secret like pullsecret:<cluster>/<namespace>/<secret_name> or an annotation to point to the cluster like argocd-image-updater.argoproj.io/cluster

How should we deal with that?

giftkugel avatar Jan 19 '25 12:01 giftkugel

So it is somehow a known limitation described here: https://argocd-image-updater.readthedocs.io/en/stable/#limitations

Image pull secrets must exist in the same Kubernetes cluster where Argo CD Image Updater is running in (or has access to). It is currently not possible to fetch those secrets from other clusters.

But what does or has access to mean? In our example ArgoCD and ArgoCD Image Updater has to access cluster b.

giftkugel avatar Jan 20 '25 09:01 giftkugel

I'd love this feature as well, since the applications already have their registry secrets and I wouldn't need to create a new one just for argocd-image-updater. The secret that argocd-image-updater uses must also have access to all namespaces in a registry which does not follow the least privilege principle. For example, GitLab registry has a different namespace for each project and project access token, that is used as registry pull secret, can access only project's namespace. Although I understand why this might be hard to do.

Blarc avatar Sep 24 '25 05:09 Blarc