[Feature Request]: allow access to external Docker Registries, i.e. VMWare Harbor or Artifactory authenticated

[shalberd]

Feature description

@andrewballantyne @dgutride Currently, both for BYON and for Running Worbenches image pulling, only the internal Openshift docker registry is supported, where access to container images (image pulling) happens unauthenticated.

That is fine for workbench container image download repo / registry locations such as quay.io that do not require authentication, but not for other more restricted corporate use cases.

Now, there are efforts ongoing on my side that will soon come to pass regarding support for external Docker image registry.
However, the authentication info to access such external docker repositories, most of all in corporate environments, needs to be accessible in the form the imagePullSecretName.

Both for getting the info on imagePullSecretName into a Notebook Pod Spec
as well as for linking it up to the default service account for enabling downloading from an external registry that is access-protected (BYON case) so the image can be transferred to the interal openshift registry, I request a way to define, e.g. in OdhDashboardConfig CR, the name of the image pull secret containing the access credentials for an external authenticated registry.

Describe alternatives you've considered

Currently, IBM users had an image pull secret present in dashboard namespace, but for BYON mirroring into internal registry, needed to manually link up the image pull secret name with the default service account.

oc patch --namespace opendatahub serviceaccount/default --type merge -p '{"imagePullSecrets":[{"name": "all-icr-io"}]}'

kind: ServiceAccount
metadata:
  name: default
  namespace: opendatahub
secrets:
- name: default-dockercfg-xxxxx
imagePullSecrets:
- name: all-icr-io

For users without an internal openshift registry, using an external authenticated registry, they also have image pull secret pre-defined with the access credentials, both in the central dashboard namespace as well as in all Data Science Projects namespaces. For image pulling from external registries to work, they need to patch the Notebook CR Pod section manually, i.e. with a cronjob in openshift, to make authenticated pulling possible. If we had an image pull secret reference available in i.e. OdhDashboardConfig, we could then use that image pull secret name in assembly of the Notebook CRD in dashboard.

https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-pod-that-uses-your-secret

In addition to the Notebook CRs / workbenches, this problem with authenticated registry access also occurs when specifying an authenticated repo docker location in imagestream tag.from.name:

Only if/when the image pull secret is linked to the default serviceaccount in the odh namespace does import of such an imagestream tag happen successfully. Regardless of presence of internal openshift registry. Makes sense, the imagestream tag lookup mechanism also needs to authenticate in case of private / authenticated docker repos.

Anything else?

Since this is a special corporate use case, i.e. at IBM, but also at other corporation, I propose to let customers needing authenticated access create their image pull secret for their external authenticated workbenches repo manually via their own CICD processes, not via Dashboard.
instead, Dashboard GUI and OdhDashboardConfig CRD only specify the name of an imagePullSecret, to be used in dashboard logic.

image pull secret needs to be present in all Opendatahub Namespaces ... I'd leave creation to corporate CICD and only reference it in Dashboard by name.

Global Cluster secret https://docs.openshift.com/container-platform/4.12/openshift_images/managing_images/using-image-pull-secrets.html#images-update-global-pull-secret_using-image-pull-secrets is not an option. For one thing, users may not have access to repos deemed globally accessible across namespaces by IT Security, for another thing, BYON and ODH workbench images repo is not relevant for an Openshift global repo and it is not advisable to enable access to workbench images authenticated repo to non-Opendatahub namespaces as well from a security perspective.

[shalberd]

Krzysztof Szlejter, Cloud Solution Architect and Security Specialist at IBM, can also give additional information via Slack ODH. @dgutride let me know please if I can assist in any way. I helped previously with storageClass Name support in ODH dashboard, the logic only, not the GUI aspects or Config aspects (where to put info) of it, so this case is in fact very similar. Essentially, if you decide to weigh in on this, community support is assured in the form of PRs and intense exchange.

[dgutride]

@shalberd - good morning - sorry for the disconnect on some of the issues of late. As you can see, we are migrating all of our issues into our jira boards - our internal engineering board is meant to be open to the community to see progress. The disconnect right now is I don't have direction yet on how to triage community issues or where things land in the upstream project. I am planning on keeping things in github and tagged community so I can review them with our leadership team to make sure they are considered for inclusion. I am pushing hard for an answer on how to prioritize this work so please bear with us while we get it sorted out.

[shalberd]

Hi @dgutride ok, good, that answers my question I had in another place as well. The other issue I had a problem with Jira was not Engineering, but UI, I believe, so that explains my not being able to view UI-related RHOAIUX issues in Jira.
UI is always the first step in deciding on new features, though, before any work in the background, Andrew explained to me, so maybe that could be made read-only for the community as well in Jira.
Yes, marking issues here on Github as community is a neat idea for tracking, thank you.