Argo: Parameterize imagePullSecrets for private authenticated repositories

Created on 21 May 2018  路  6Comments  路  Source: argoproj/argo

Is this a BUG REPORT or FEATURE REQUEST?:

FEATURE REQUEST

What happened:

Attempted to install argo in an offline environment against an authenticated private repository and had to edit the deployments manually for it to work.

Additionally, attempting to run a workflow pulling containers from an authenticated repository does not appear to work. Specifying imagePullSecret in the template does not appear to be respected.

What you expected to happen:

Allow for a flag to supply a imagePullSecrets name to properly pull from the Docker registry at installation time. Workflows should also respect imagePullSecret in the template.

How to reproduce it (as minimally and precisely as possible):

  1. Set up a private repository that requires authentication (Harbor, etc.)
  2. Run the following command pointing to the private repo:
    argo install --controller-image private-registry.io/argo/workflow-controller:latest --executor-image private-registry.io/argo/argoexec:latest --ui-image private-registry.io/argo/argoui:latest --ui-base-href /argo/ --enable-web-console -n argo

Anything else we need to know?:

Environment:

  • Argo version:
$ argo version
argo: v2.1.0
  BuildDate: 2018-05-01T20:04:30Z
  GitCommit: 9379638189cc194f1b34ff7295f0832eac1c1651
  GitTreeState: clean
  GitTag: v2.1.0
  GoVersion: go1.9.3
  Compiler: gc
  Platform: linux/amd64
  • Kubernetes version :
$ kubectl version -o yaml
clientVersion:
  buildDate: 2018-04-12T14:26:04Z
  compiler: gc
  gitCommit: d4ab47518836c750f9949b9e0d387f20fb92260b
  gitTreeState: clean
  gitVersion: v1.10.1
  goVersion: go1.9.3
  major: "1"
  minor: "10"
  platform: linux/amd64
serverVersion:
  buildDate: 2018-04-12T14:14:26Z
  compiler: gc
  gitCommit: d4ab47518836c750f9949b9e0d387f20fb92260b
  gitTreeState: clean
  gitVersion: v1.10.1
  goVersion: go1.9.3
  major: "1"
  minor: "10"
  platform: linux/amd64

Most helpful comment

@jessesuen Thank you for the pointer in the right direction. This works for us. Really enjoying working with argo!

All 6 comments

Specifying imagePullSecret in the template does not appear to be respected

ImagePullSecrets is actually at the workflow spec, and not at the template level. So if you specify spec.imagePullSecrets, it will be carried forward to the pod.

Additionally, I believe kubernetes provides ways to supply image pull secrets at a namespace level, so that you don't have to always specify imagePullSecrets per pod.

Do the above techniques work for you?

Additionally, I believe kubernetes provides ways to supply image pull secrets at a namespace level, so that you don't have to always specify imagePullSecrets per pod.

Correction -- it is at a service account level, not namespace. But you can attach it to the default service account in a namespace such that the default behavior is that the pods in that namespace will have the image pull secret:

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account

Closing this since imagePullSecrets is already in the workflow sepc at the spec.imagePullSecrets level (not a template level).

@jessesuen Thank you for the pointer in the right direction. This works for us. Really enjoying working with argo!

Any plan to support the template level imagepullsecrets?

Closing this since imagePullSecrets is already in the workflow sepc at the spec.imagePullSecrets level (not a template level).

Does this mean that all container images must use the same secrets?

Was this page helpful?
0 / 5 - 0 ratings