[Bug] OpenShift OAuth Proxy can't run in default namespace

[ebaron]

I believe this happens because the default namespace doesn't use SecurityContextConstraints. A fix would be adding something like USER 1001 to the Containerfile.

  Warning  Failed                  3m30s                  kubelet                  Error: container has runAsNonRoot and image will run as root (pod: "cryostat-sample-6769cdb9c9-m8ldf_default(c975eee4-58e8-4643-b5a6-ae0d2c343270)", container: cryostat-sample-auth-proxy)

[tthvo]

I guess after this is resolved, we can also remove the note here about setting runAsUser in default namespace (i.e. The oauth2-proxy container image also has USER set):

https://github.com/cryostatio/cryostat-helm/blob/5bda8443d8a41b8f259aae607e88054edce92992/charts/cryostat/values.yaml#L276

[ebaron]

I guess after this is resolved, we can also remove the note here about setting runAsUser in default namespace (i.e. The oauth2-proxy container image also has USER set):

https://github.com/cryostatio/cryostat-helm/blob/5bda8443d8a41b8f259aae607e88054edce92992/charts/cryostat/values.yaml#L276

Indeed! I missed that comment initially.

[andrewazores]

https://github.com/oauth2-proxy/oauth2-proxy/blob/master/Dockerfile

          "User": "",

It looks like the oauth2-proxy does not have USER set. Since we're already maintaining a small fork of the OpenShift OAuth Proxy I think it makes sense that we can set the USER in our downstream Containerfile, but it doesn't look like we are in a position to do the same thing for the oauth2-proxy.

[ebaron]

https://github.com/oauth2-proxy/oauth2-proxy/blob/master/Dockerfile

          "User": "",

It looks like the oauth2-proxy does not have USER set. Since we're already maintaining a small fork of the OpenShift OAuth Proxy I think it makes sense that we can set the USER in our downstream Containerfile, but it doesn't look like we are in a position to do the same thing for the oauth2-proxy.

I suppose that's okay as we allow users to set a UID in the container's security context through the CRD. I think that's the only way this container will work in Kubernetes in a namespace with the restricted pod security level. It would be ideal if both images had explicit USER directives though so this extra step for users isn't needed.

[tthvo]

https://github.com/oauth2-proxy/oauth2-proxy/blob/master/Dockerfile

          "User": "",

It looks like the oauth2-proxy does not have USER set. Since we're already maintaining a small fork of the OpenShift OAuth Proxy I think it makes sense that we can set the USER in our downstream Containerfile, but it doesn't look like we are in a position to do the same thing for the oauth2-proxy.

I wonder if the oauth2-proxy on Quay is built differently than that Dockerfile above? I am inspecting the quay.io/oauth2-proxy/oauth2-proxy:latest and it seems it has set the user to 65532?

podman inspect quay.io/oauth2-proxy/oauth2-proxy | jq .[].User
"65532"

[andrewazores]

Ah, I was inspecting a different tag: latest-alpine instead of just alpine. So I guess the oauth2-proxy does run as-is in the default namespace, without any customizations to its securityContext?

[tthvo]

Oh actually, the USER is set from the base image that they use: gcr.io/distroless/static:nonroot.

[tthvo]

Ah, I was inspecting a different tag: latest-alpine instead of just alpine. So I guess the oauth2-proxy does run as-is in the default namespace, without any customizations to its securityContext?

Oh yep, I just did a quick test and it seems to run without issue^^ Probably need a double check :D

[ebaron]

I suppose one cool way we know this works is our Scorecard tests running in CI. The namespace is labeled as restricted pod security level:

cryostat-operator/Makefile

Line 231 in 0ec9a84

$(CLUSTER_CLIENT) label --overwrite namespace $(SCORECARD_NAMESPACE) pod-security.kubernetes.io/warn=restricted pod-security.kubernetes.io/audit=restricted