Linux user mapping in Kubernetes with containerd

I have a question about how kubernetes maps the host users with the containers’ usernamespace user.

Basically, when I create a securityContext with runAsUser set to a uid which exists in the host usernamespace, I can see in the host ps -aux output that the process is started with this specific uid (and therefore the same username). This leads to weird things such as sshd running sleep command when I pass runAsUser: 106 in the pod securityContext.
sshdSleepingImage

Therefore, I think that Kubernetes (or containerd ?) maps the host uid 106 to the container usernamespace userid 106. Is it the expected behaviour?

Wouldn’t it be more logical to map the nobody user of the host (or at least an other user or uid) with the user in the container usernamespace?

Thanks in advance for the answers

There’s a KEP in progress to add users to k8s. It’s not as simple as just mapping to nobody, though.

1 Like

Thank you for the answer.

Why isn’t it a solution to map the nobody user (or an other created user for this purpose) to the user in the container namespace if we don’t want privileged containers ?

I invite you to review the KEP, and if you want more details, you can read the PR history of it :slight_smile:

https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/127-user-namespaces

2 Likes