[bitnami/postgresql] Security context issues on Openshift Online (init-chmod-data fails)

[l0rn]

Which chart:

The affected chart is the postgresql chart. (stable/postgresql)

Description

I stumbled across issues regarding the SecurityContext using developer trial at openshift online: https://www.openshift.com/trial/

It basically disallows root containers (Openshift default) and applies a SecurityContextConstraint on you assigning you a range of usable uids. So if you do a

helm install stable/postgresql --set volumePermissions.securityContext.runAsUser=1001 --set securityContext.runAsUser=1001 --set persistence.size=1Gi

You'll yield this error on the StatefulSet

  Warning  FailedCreate      11s (x13 over 29s)  statefulset-controller  create Pod your-dog-postgresql-0 in StatefulSet your-dog-postgresql failed error: pods "your-dog-postgresql-0" is forbidden: unable to validate against any security context constraint: [spec.initContainers[0].securityContext.securityContext.runAsUser: Invalid value: 1001: must be in the ranges: [1033980000, 1033989999] spec.containers[0].securityContext.securityContext.runAsUser: Invalid value: 1001: must be in the ranges: [1033980000, 1033989999]]

So easy fix:

helm install stable/postgresql --set volumePermissions.securityContext.runAsUser=1033980001 --set securityContext.runAsUser=1033980001  --set persistence.size=1Gi

Next issue in the statefulset:

create Pod washing-olm-postgresql-0 in StatefulSet washing-olm-postgresql failed error: pods "washing-olm-postgresql-0" is forbidden: unable to validate against any security context constraint: [fsGroup: Invalid value: []int64{1001}: 1001 is not an allowed group]

No hint which fsGroup is allowed nowhere - I just assumed it could as well omit it for my use case since all processes share the same uid?! (That would be my first question)

So try again without fsGroup set:

helm install stable/postgresql --set volumePermissions.securityContext.runAsUser=1033980001 --set securityContext.runAsUser=1033980001 --set securityContext.fsGroup= --set persistence.size=1Gi

Yay, the pvc gets created, as well as a pod running the init-chmod-data init pod.
But that fails because of

➜  ~ oc logs -f iron-duck-postgresql-0 -c init-chmod-data
chown: invalid spec: '1.033980001e+09:'

So it looks like its taking my long uid and converts it to a scientific notation and results to chown failing. Any idea i can work around that? On a shared platform like openshift online you don't have the option to take differen uids.

Steps to reproduce the issue:

1. Create developer account at openshift online
2. Create a postgres cluster with commands described above
3. run into errors

Describe the results you received:

The init-chmod-data pod fails with long uids assigned by openshift online

Describe the results you expected:

init-chmod-data container executing with long uids

Additional information you deem important (e.g. issue happens only occasionally):

Version of Helm and Kubernetes:

• Output of helm version:

➜  ~ helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}

• Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.0", GitCommit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", GitTreeState:"clean", BuildDate:"2019-06-19T16:40:16Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.4+8560dd6", GitCommit:"8560dd6", GitTreeState:"clean", BuildDate:"2019-07-31T21:30:54Z", GoVersion:"go1.11.6", Compiler:"gc", Platform:"linux/amd64"}

[tompizmor]

Can you try using --set-string as suggested here helm/helm#1707

[l0rn]

THAT was helpful, i didn't thought of a parsing issue in helm, or at least i didn't find that issue. so that worked - container's running fine.... It somehow bothers me that it'd only work with an empty fsGroup.... although it seemingly works fine without i'd like to understand the issue.... Anyway thanks for that hint!

[tompizmor]

I am glad it was helpful for you! I already hit that same issue with the bitnami/kafka chart in the past but in that case, the workaround was different as the conflictive values were set by default in the values.yaml.
Basically we define the values as "24235435646_" (so it is a string), and later on when consuming the big number we replace "_" by "". (Example here: https://github.com/bitnami/charts/blob/master/bitnami/kafka/templates/statefulset.yaml#L185)

This workaround was also proposed at helm/helm#1707

[stale]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[stale]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.