Podman - Rootless Container Persistent Storage Question

[craig109]

How does one determine the correct permissions for the host directory when configuring a rootless container?

For example, if setting up a mysql database container, you can use the UID:GID of the mysql user in the container.

But what does one use otherwise?

Are we supposed to glean that information from the output of:

podman unshare cat /proc/self/uid_map

and

podman unshare cat /proc/self/gid_map ?

This topic was not well-covered in the class or the accompanying ebook.

[abbashussain]

I am always getting error 

WARN[0000] Failed to mount subcription , skipping entry in /usr/share/container/mounts.conf.................................... permission denied.

Please help how to get fix the issue with rootless container.

[craig109]

@abbashussain Please delete your response and post on a separate thread instead of hi-jacking mine.

[flozano]

Container images that require a fixed uid do not work well on rootless podman. These images also present security issues when used with Kubernetes and would not be allowed to run on hardened Kubernetes distributions such as OpenShift.

It is recommended that container images are designed to run under a "random" uid (random here means that it is not fixed but set at the time you start a container) and file access permissions are set to the group zero (wheel).

Rootless containers run as the invoking user's uid for the host but a different user inside the container. To find the permissions required for host folders you need to understand how the user inside the container is mapped to the users in the host.

By default, the invoking user is mapped to zero (root) inside the container and any other user is mapped to the range set at /etc/subuid, and similar to groups using /etc/gsubuid.

You can find more details at:

https://www.redhat.com/sysadmin/debug-rootless-podman-mounted-volumes

[gclaborn]

This is grossly inaccurate. 

Podman is designed to both run containers and containerized processes as specific users.

If OpenShift is failing to take advantage of this, then OpenShift is not actually hardened as one would expect. Our Kubernetes is able to support this no problem and it provides great security assurances.

With this method, you lose much of the benefit of running rootless in the first place. May as well just use chroot at that point. This is absurd methodology.

[flozano]

It is not innacurate at all. First because OpenShift does not use podman to run containers, as upstream Kubernetes does not use Docker anymore. The needs and requirements of a general-purpose local container engine are different from a container engine for Kubernetes.

JFYI OpenShift runs CRI-O as its container engines, and upstream Kubernetes offers containerd as an alternative.

Local container engines are standardized by the OCI specification. Kubernetes needs are dedined by the CRI API. Many features available from OCI, thus available from podman, docker, and other container engines, are not available from CRI.

You can configure OpenShift to run a pod as a specific user, as you can with Kubernetes, but that comes with securty concerns because containers and pods are not isolated, by Kubernetes and the CRI, at a host level.

Kubernetes is not able to use uid namespaces so different pods, from different namespaces, that share the same uid actually share it at the host level and that increases the potential impact of a container engine leak where a container gets access to its host.

With any Kubernetes it is a security recommendation that you run pods with different uids than each other. OpenShift just provides mechanisms to enforce that by default while upstream Kubernetes does not.

This is not hypotetical, there are a number of CVEs that affect a "vanilla" Kubernetes deployment, and many products such as Rancher and EKS, but do not affect OpenShift under its default settings only because OpenShift will not run pods as the uid specificied on their container images.

This is so true that what we consider nowadays as good qualtity container images and helm charts, such as the ones from the Bitnami community, don't require that you run containers with a fixed uid and they work as-is with OpenShift.

If you considered all risks and implications and wish to run a pod with a specific uid, you can take explict action to allow that and manage that pod as an exception. Learn about configuring SecurityServiceContraints (SCCs) on OpenShift. With upstream Kubernetes, you can do that with no explicit action and unaware of the risks, with no assessment of whether the risks are acceptable or not to you.

Outside of Kubernetes and OpenShift, running rootless containers properly require knowing how uid and gid mapping affects the inside of the container and its host. Uid and other namespaces do not come free and seamless. This is tricky to get right if you expect a container to use a volume from the host or different networking settings.

It looked easy for rootfull containers because the container engine operatated under no constraints. For rootless, the invoking user and the container engine have to consider many special cases and usually the easiest path is just to configure the container image to work well as any uid instead of a fixed one, which makes the image automatically "good" for OpenShift.