[Bug] OpenShift OAuth Proxy container failed to launch in default namespace

[tthvo]

Current Behavior

It seems like the Openshift OAuth proxy image does not specify a numeric non-root user. Thus, runAsNonRoot: true cannot be specified on pod.

$ podman image inspect quay.io/openshift/origin-oauth-proxy:latest --format '{{.Config.User}}'
0

Container failed to launch with status:

  - image: quay.io/openshift/origin-oauth-proxy:latest
    imageID: ""
    lastState: {}
    name: cryostat-authproxy
    ready: false
    restartCount: 0
    started: false
    state:
      waiting:
        message: 'container has runAsNonRoot and image will run as root (pod: "cryostat-579d45489-2nt7w_default(337845d4-41c2-4fbb-ab29-3882be6d771a)",
          container: cryostat-authproxy)'
        reason: CreateContainerConfigError

Expected Behavior

Openshift Oauth proxy container should launch successfully.

Steps To Reproduce

helm install cryostat --set authentication.openshift.enabled=true --set core.route.enabled=true ./charts/cryostat/

Environment

CRC version: 2.26.0+233df0
OpenShift version: 4.13.9

Anything else?

Should the chart default to set runAsUser for the proxy container?

[andrewazores]

Hmm, I've been doing all the testing in my PRs with this:

$ crc version
CRC version: 2.34.1+b470b5
OpenShift version: 4.15.3
Podman version: 4.4.4

and I haven't run into this problem. But it seems like something that should at least be configurable.

[andrewazores]

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container

Maybe it makes sense for us to apply a general Pod security context around everything, and then have optional container security contexts for each container within the Pod:

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container

Except for cases like this where we seem to know that a container will not run under the general Pod context, or at least on some common and supported k8s/OCP versions it won't, then we can provide a default for that particular container.

[andrewazores]

I tested on another 4.15 cluster and on a 4.14 cluster and the simple helm install cryostat --set authentication.openshift.enabled=true --set core.route.enabled=true ./charts/cryostat/ reproducter successfully deploys for me, no runAsNonRoot launch failure.

[tthvo]

Ahh opps, a mistake on my end, I didn't notice the chart was installed into the default namespace, in which OpenShift SCC does not apply: https://docs.openshift.com/container-platform/4.14/authentication/understanding-and-managing-pod-security-admission.html#psa-privileged-namespaces_understanding-and-managing-pod-security-admission

Thus, the pod won't be patched with runAsUser, thus giving the errors.

[tthvo]

Installing the chart into a different non-default namespace works as expected :D

helm install cryostat \
--create-namespace=true --namespace myns \
--set authentication.openshift.enabled=true \
--set core.route.enabled=true \
./charts/cryostat/

I think we can close this issue as its not really a bug. Maybe we can document/give a warning this issue somewhere instead?

[andrewazores]

Ahh makes sense, yes, I think we should have that documented somewhere. Maybe a note in the values.yaml annotations on the security context/runAsNonRoot field, so that it shows up both there as well as the generated README?

[tthvo]

Sounds good! I can help open a quick PR for that :D

[andrewazores]

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container

Maybe it makes sense for us to apply a general Pod security context around everything, and then have optional container security contexts for each container within the Pod:

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container

Except for cases like this where we seem to know that a container will not run under the general Pod context, or at least on some common and supported k8s/OCP versions it won't, then we can provide a default for that particular container.

After saying all that, I see we do have separate container security contexts:

https://github.com/cryostatio/cryostat-helm?tab=readme-ov-file#jfr-data-source-container

But the new storage and db containers don't have their own. They are mistakenly reusing the core context.

[tthvo]

Opps closed by mistake :D