Open k-wall opened 5 years ago
I think this issue relates to https://docs.openshift.com/container-platform/4.1/authentication/managing-security-context-constraints.html. Testing shows me that when EnMasse installed into openshift-operators the behaviour with respect to UID and the FS Group that owns the persistent volume is different. I expect that this will somehow relate the SCC annotations on the openshift-operators namespace, but I don't understand these properly yet.
$ oc describe namespace openshift-operators
Name: openshift-operators
Labels: openshift.io/run-level=1
Annotations: openshift.io/node-selector=
openshift.io/sa.scc.mcs=s0:c20,c15
openshift.io/sa.scc.supplemental-groups=1000410000/10000
openshift.io/sa.scc.uid-range=1000410000/10000
Status: Active
No resource quota.
oc describe namespace enmasse-infra
Name: enmasse-infra
Labels: <none>
Annotations: openshift.io/description=
openshift.io/display-name=
openshift.io/requester=admin
openshift.io/sa.scc.mcs=s0:c22,c14
openshift.io/sa.scc.supplemental-groups=1000490000/10000
openshift.io/sa.scc.uid-range=1000490000/10000
Status: Active
No resource quota.
No resource limits.
If https://github.com/operator-framework/operator-lifecycle-manager/issues/927 were to be resolved, this issue would be fixed.
Describe the bug
If EnMasse 0.28.1 is installed in openshift-operators (as is the case when installing from OLM on OpenShift 4.1), the Broker runs as
root
. Whilst this doesn't give a functional problem, running as root is against security best practice. Also, the journal files etc on the persistent storage become root owned.When installed in another namespace in OpenShift 4.1 (for instance, enmasse-infra), the Broker process runs as a UID drawn from a range, assigned by SCC, I think). The journal files on the persistent storage are owned by this user too.
To Reproduce Steps to reproduce the behavior:
oc rsh
into the Broker podps -ef
. Observe that the Broker is running as root.Expected behavior
Non root user should be executing the Broker.
Additional context
I notice that root is chosen because this is Dockerfile default.