https://github.com/opendatahub-io/odh-manifests/search?q=ose-oauth-proxy

In the ODH-Dashboard, there currently is an oauth sidecar with version 4.8

registry.redhat.io/openshift4/ose-oauth-proxy:v4.8

This is just for the route to ODH dashboard and authentication, not for jupyter notebooks / kubeflow notebooks in

odh-notebook-controller

registry.redhat.io/openshift4/ose-oauth-proxy:v4.10

odh-prometheus

registry.redhat.io/openshift4/ose-oauth-proxy@sha256:4bef31eb993feb6f1096b51b4876c65a6fb1f4401fee97fa4f4542b6b7c9bc46

data science pipelines ui

registry.redhat.io/openshift4/ose-oauth-proxy:v4.8

It is not good for reproducability if there are different oauth-proxy images used.

You can look up versions and tags/sha256 digest values here

https://catalog.redhat.com/software/containers/search?q=ose-oauth-proxy

• select architecture AMD64

• search for a tag, e.g. v4.10 (or 4.12?) what is your Openshift target currently?

• get the "Manifest List Digest" value, that is architecture-neutral. @Jooho I assume in the image digest value, the manifest list images by digest value must be used, but I could be wrong.

Describe the solution you'd like
To summarize:

• if using tags, think about using a tag that is congruent with primarily supported openshift version

• if using digests, first look up the tag and then fill in the digest value (Manifest List Digest)

containerStatuses of a pod resolves like this, so I think using the full string and digest from "Manifest List Digest" is the way to go

imageID: >-
        registry.redhat.io/openshift4/ose-oauth-proxy@sha256:792f9e2db2d25c63ceb2169e38209622062f5c431522cfe85976ca23b1dc8c57
      image: 'registry.redhat.io/openshift4/ose-oauth-proxy:v4.10' 

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
For airgapped and disconnected, using sha256 digest format is a must. Also, with sha256 digest format, it is always guaranteed to be exactly the same image. That is not the case with tags, as e.g. tag v4.10 is continously moved to new builds / image behind is changed.