Need to set openshift: false to deploy on OpenShift?

[Lars Kellogg-Stedman]

We have installed the crunchy postgres operator via operatorhub (which gets us version 5.4.3). When creating a new postgrescluster, the database pod would fail to come up, failing with this error:

Initializing ...
::postgres-operator: uid::26
::postgres-operator: gid::26
::postgres-operator: postgres path::/usr/pgsql-15/bin/postgres
::postgres-operator: postgres version::postgres (PostgreSQL) 15.4
::postgres-operator: config directory::/pgdata/pg15
::postgres-operator: data directory::/pgdata/pg15
install: cannot change permissions of ‘/pgdata/pg15’: No such file or directory
stat: cannot statx '/pgdata/pg15': No such file or directory

The "cannot change permissions of ‘/pgdata/pg15'" error crops up because the postgres-data volume is mounted on /pgdata with root:root ownership. The postgres user (uid 26) cannot create files or directories there.

The solution would appear to be setting "fsGroup: 26" in the pod securityContext. I was trying to figure out how to do that in the postgrescluster manifest, and the answer appears to be that we should set "openshift: false".

Since we're deploying on openshift, that leaves me confused:

- Why does setting "openshift: true" remove the fsGroup setting from the securityContext?

- Why do we need to set "openshift: false" to use this operator on our openshift cluster?

Thanks!

[Andrew L'Ecuyer]

Hi Lars,

The behavior you are seeing with the spec.openshift setting is related to compatibility with OpenShift's restricted-v2 (and previously restricted) SecurityContextConstraint (SCC).  Crunchy Postgres for Kubernetes (CPK) aims to be compatible with the most restrictive SCC available by default, which per the OpenShift SCC documentation is restricted-v2.

And to tie this to your question about fsGroup, when using restricted-v2, OpenShift handles all fsGroup configuration for the various Pods created by CPK, specifically based on the random UID OpenShift assigns to the Pod.  For instance, in the following commands (which are being run against a Postgres instance Pod) you can see that OpenShift has assigned a random UID to the Pod, specifically based on UID range allocated to the namespace:

$ oc get pod -n postgres-operator hippo-instance1-g7cz-0 -o yaml | grep runAsUser
      runAsUser: 1000760000

$ oc get ns postgres-operator -o yaml | grep uid-range
    openshift.io/sa.scc.uid-range: 1000760000/10000

And then looking in that same Pod, you can see that OpenShift has also set the fsGroup accordingly:

$ oc get pod -n postgres-operator hippo-instance1-g7cz-0 -o yaml | grep fsGroup
    fsGroup: 1000760000

I also note that since the restricted-v2 SCC is used for any new namespace within a standard/baseline OpenShift installation, CPK aligns accordingly (i.e, to maximize compatibility with most OpenShift installations and namespaces).  This also aligns with the security-first principles of CPK, i.e. to be compatible with OpenShift's baseline security recommendations (and associated Kubernetes guidelines).  That being said, we do expose the openshift setting for situations where this behavior may not be desired (so that it can be set to false if/when needed, as you are currently doing).

Do you know which SCC you are currently using for the Pods comprising your various Postgres deployments?  My guess is something other than restricted-v2, such as anyuid, etc.  To check, you can specifically run the following command against one of your Postgres Pods:

$ oc describe pod -n postgres-operator hippo-instance1-bs5m-0 | grep scc
                  openshift.io/scc: restricted-v2

My recommendation is first to verify the desired SCC for your various Postgres deployments.  Considering CPK is able to run under the restricted-v2 SCC, we do recommend doing so considering the security benefits.  You might also want to try creating in a brand new namespace to see if that gives you the SCC behavior that CPK expects by default (e.g. in the event that your current namespace has been misconfigured).

Hope this helps!

Thanks,

Andrew