3.2 Container process UIDs in OpenShift

Root-user is not allowed in containers

By default, OpenShift randomly chooses the UID for the user running a process inside a container from a certain number space. On Tike shared container platform this security feature will not be disabled for a customer project without proper reasoning.

This means that containers running in OpenShift can't be ran as root or any other predetermined UID. USER definitions in Dockerfiles are overwritten: OpenShift will choose the UIDs randomly despite these definitions.

The random process UID sometimes poses challenges for file rights and ports opened by processes. Processes can not open all container-Image files or open ports with numbers under 1024. Often Images from software projects or Dockerhub expect root-user inside containers to be possible, which is why these Images can not be used in OpenShift.

Advice:

• Check if there is a version of the application that can be run on OpenShift. Sometimes suppliers of ready-made software offer changes for OpenShift. Additionally some Images have an official version with limited access, for example: https://hub.docker.com/r/nginxinc/nginx-unprivileged
  • The container platform administration aims to give working examples for common projects/programming languages here. However, this is a work in progress.
• File access within a container should be given with GID 0. OpenShift automatically sets group membership GID=0 (root) for processes inside containers. If your application wants to use files within the container, the group 0 should be given appropriate access.
• Make sure your application accepts traffic from port ≥1024. Traffic outside the cluster through ports 80 or 443 is done by using Services and Routes. The easiest and most useful way to achieve this if the open port can be defined for the application with environment values or a configuration file outside the container.

More information and instructions:

• https://docs.openshift.com/container-platform/4.5/openshift_images/create-images.html#images-create-guide-openshift_create-images
• https://www.openshift.com/blog/a-guide-to-openshift-and-uids
• https://developers.redhat.com/blog/2020/10/26/adapting-docker-and-kubernetes-containers-to-run-on-red-hat-openshift-container-platform/

Podman

If you wish to use Podman for development instead of Docker and leave behing root privileges for container, you can find more information below:

• https://www.redhat.com/sysadmin/rootless-podman-makes-sense

Podman has four configurations related to privileges inside and outside containers.

• Root podman, root container
• Non-root podman, root container
• Root podman, non-root container
• Non-root podman, non-root container.

Of these, the top one is clearly the worst for security and the bottom one the best. The top two are impossible on the shared container platform, since root access within containers is disabled. The benefit in using Podman is its ability to map UID/GID through the container barrier, which enables it to give processes within containers to for example use the users home directory.

With the third configuration, there is also the possible danger of a process within a container to seem to belong to someone else to the OpenShift container platform. An example would be that inside the container we have UID 4000 (Mikko) and outside the container we have a different user with UID 4000 (Tiina). Now every process inside a container with Mikko's UID would be shown to run as Tiina's UID from OpenShift's perspective. This is another reason why only the bottom example is recommended.

More detailed about using Podman: https://www.tutorialworks.com/podman-rootless-volumes/