pgadmin chart not deployable on ocp4 with non root

[enibache]

Describe the bug I can't deploy this chart in k8s ocp4 because root is forbidden. So after some reading, i got to understand that turning the "VolumePermissions" flag on resolves this issue, but unfortunately it doesn't, namely because the "group:user" is hard-coded in the chart and so I'm bound/obliged to use the same "550" as in the values. Question: Is there a reason to hard-code this value instead of using e.g environment variables ?

Version of Helm and Kubernetes: ❯ helm version
version.BuildInfo{Version:"v3.8.0", GitCommit:"d14138609b01886f544b2025f5000351c9eb092e", GitTreeState:"clean", GoVersion:"go1.17.5"}

K8s Version: 1.21

Which chart:

https://github.com/rowanruseler/helm-charts/tree/master/charts/pgadmin4

What happened: Pod won't create due to reason in bug description

What you expected to happen: pod should run and i should be able to use pgadmin on browser

How to reproduce it (as minimally and precisely as possible): You can only reproduce this if you're running on my specific OCP4 cluster which generates such error:

pods "pg-pgadmin4-6d887d69db-" is forbidden: unable to validate against any security context constraint: [provider "anyuid": Forbidden: not usable by user or serviceaccount, provider "check-mk": Forbidden: not usable by user or serviceaccount, provider restricted: .spec.securityContext.fsGroup: Invalid value: []int64{5050}: 5050 is not an allowed group, spec.initContainers[0].securityContext.runAsUser: Invalid value: 0: must be in the ranges: [1003930000, 1003939999], spec.containers[0].securityContext.runAsUser: Invalid value: 5050: must be in the ranges: [1003930000, 1003939999], provider "nonroot": Forbidden: not usable by user or serviceaccount, provider "noobaa": Forbidden: not usable by user or serviceaccount, provider "noobaa-endpoint": Forbidden: not usable by user or serviceaccount, provid

Anything else we need to know: that would be all for now, please do lemme know if further input is required !

[bozyman3000]

You can override the helm chart default setting with custom values.yaml file ( in attachments) : pgadmin-config.zip

and pass it to helm install command :

i.e: helm install pgadmin4 runix/pgadmin4 -f pgadmin-config.yaml

[feraudt]

Hi there!

I'm having the same issue on Openshift Container Platform v4.12.5 with the restricted (or restricted-v2) securityContextConstraint (which restricts running containers as root or with UID/GID outside of a pre-allocated range, also requires to run with pre-allocated FSGroup)

As stated above, the default securityContext to run as 5050 (pgadmin) also results in an error due to the SCC being violated.

Finally, I couldn't really test the proposed solution suggesting to set runAsUser and fsGroup to a specific UID within the allowed range, since setting fsGroup also gives the Invalid value error.

So running the container without any securityContext allows the pod to pass the SCC & be created, but then the image entrypoint script gives the following error:

/entrypoint.sh: line 52: /venv/bin/python3: Operation not permitted
/entrypoint.sh: line 73: /venv/bin/python3: Operation not permitted
/entrypoint.sh: line 85: /venv/bin/python3: Operation not permitted
sudo: The "no new privileges" flag is set, which prevents sudo from running as root.
sudo: If sudo is running in a container, you may need to adjust the container configuration to disable the flag.
/entrypoint.sh: line 108: /venv/bin/python3: Operation not permitted
/entrypoint.sh: exec: line 126: /venv/bin/gunicorn: Operation not permitted

I wonder if using the nonroot (or nonroot-v2) Openshift SCC could solve the problem by allowing runAsUser: 5050 & runAsGroup: 5050 but the fsGroup: 5050 would still be forbidden so I believe this would not help much. If this is the case, the only SCC allowing to run the image would be the privileged one, which should not be granted unless for administration clusters (according to RedHat docs).

So I'm kind of stuck there, can anyone think of a solution that does not put the cluster at risk ? I guess this will come to adapting the image so it can run with unprivileged users...

Thanks for any further contribution to this issue!

EDIT: After some other tests I was able to run the pgadmin pod with VolumePermissions.enabled: true which unfortunately requires the anyuid SCC to run as root. I'm not sure why this initContainer is required though (see also issues #17 & #18), as the above error does not seem directly related...