gid=0 will violate future Pod Security Standards Restricted Profile about docker-sonarqube

[jCOTINEAU]

Hello @jonasrutishauser thanks a lot for taking the time to participate in the community.

This is very interesting, we have actually been following gid 0 principle to be compatible with Openshift and more specifically with anyUserID setups (see https://docs.openshift.com/container-platform/3.11/creating_images/guidelines.html Support Arbitrary User IDs)

Do you have clues towards what setup in terms of permissions in the Dockerfile should be set by now to allow any UID setup ?

[jonasrutishauser]

I just found a solution which should work at the moment (no change needed in the docker image).
As there is no runAsNonRootGroup at the moment, it is enough to not set the group explicitly and only set the fsGroup to something which is not 0.
This means the chart can be configured like the following:

securityContext:
  fsGroup: 1000
containerSecurityContext:
  runAsGroup: null
initContainers:
  securityContext:
    runAsGroup: null

Eventually this could be reflected in the official chart such that is not needed to remove some values.

[jCOTINEAU]

Unfortunately, inside the Docker image we do set some permissions on file (some read only, some writeable) and we use the groupId to make sure that any user ID can be picked.

If we go to runAsGroup: null and fsGroup: any, then it means that from the docker filesystem point of vue we will have to rely on allowing read only for everyone and write for everyone.

While this looks okay to me in a container context from a security point of vue (we were in this situation for a bit) it looks like industry standards (openshift) are not going in this direction

[leobr29]

Hi @jCOTINEAU,

Some production environment already ban the use of uid or gid = 0 to run a container.

Why do not use a gid != 0 as it was the case before ? I was already able to manage Arbitrary User IDs with this kind of command :

docker run -u 9999:9999 --group-add 1000 sonarqube

Best,
Leo.

[jCOTINEAU]

Hello @leobr29, mostly to follow the Openshift guidelines.

They are dynamically at runtime fixing a random UID and gid to 0, which makes it impossible to predict the UID to use inside the Dockerfile.

We are investigating this topic again, to find the best setup. Nonetheless, it will be hard to have something working for every possible runtime and every security policy.

Thanks a lot for keeping this discussion open, if you have any other information on the topic feel free to add them here.

Best,
Jeremy