Any point in running containers as non-root on openshift

Question

The openshift documentation reads :

To further protect RHCOS systems in OpenShift Container Platform clusters, most containers, except those managing or monitoring the host system itself, should run as a non-root user. Dropping the privilege level or creating containers with the least amount of privileges possible is recommended best practice for protecting your own OpenShift Container Platform clusters.

The container in question is going to run as a read-only, non-privileged, on cri-o runtime, with UID remapping, selinux, and secomp profile.

I’m wondering at this stage whether running the containers as non-root user is a cargo cult throwback from the days of docker daemon running as root.

If the container is running with all those constraints already is there any conceivable point in running as non-root user?

Answer 1

The correct approach to security should be using the minimum required privileges.

If something doesn't really need root access, it shouldn't have it.

Answer 2

One can never say there is enough security in place, some other guy will always find a way to crack that sooner or later, whether it's with technological know-how, social engineering, or some other method I'm not aware of it will happen.

It's all depends on how important it is to you and what type or level of attackers are you expecting to encounter. If you're willing to take the risk or not that's your decision (or your company's one), but since you're using Openshift, a security-focused "version\distro" of Kubernetes I think you'll be more inclined to go to the security heavy approach.

Also, think how much of an inconvenience that would be to you? If not much I think it's worth a shot, if not then consult your answer to paragraph 2.

cri-o and podman have better design when speaking security wise but they're not free of issues just as well as docker isn't.

Answer 3

Running a rootless container as root inside the container

Running as the root user is the default:

podman run --user 0:0 ...

(Adding --user 0:0 is not needed as it is the default)

If you haven't used the command-line option --uidmap, the root user will be mapped to the user's UID on the host.

The root user also has the permissions to run setuid() to change its effective UID so it has access to all the users UIDs (i.e. the user's normal UID and all the sub UIDs from the file /etc/subuid).

Running a rootless container as a non-root user inside the container

Running as a non-root user (for instance a user with UID=1000, GID=1000):

podman run --user 1000:1000 ...

If you haven't used the command-line options --uidmap or --userns=keep-id, the non-root user will not be mapped to the user's UID on the host but instead to one of the sub UIDs from user's UIDs in the file /etc/subuid.

Comparing the two alternatives (i.e. root and non-root)

In case Podman would have a security vulnerability, it would be safer if the container process would run as a non-root user that is not mapped to the user's UID on the host.

If such a container process would escape the container, it would only have file access as one of the users's sub UIDs. The process would not have any access to the directory ~/.ssh (that normally has the permission chmod 700 ~/.ssh).

Additional reading

The Red Hat blog post Running rootless Podman as a non-root user by Dan Walsh explains why it's more secure to run rootless containers as a non-root user than as the root user.