Kubernetes Security Feature Request: support for user namespaces/id mapped mounts

[Lennie]

This is maybe more of a long term vision question/idea. Maybe it's out-of-scope.

For better security for tenants, the recommendation is to have user namespace:

https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/127-user-namespaces/README.md#motivation

That's important for security, so extra important for multi-tenant environments.

If you have a workload which has to share volumes for example, you will need something like this to be efficient/effective:

https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/127-user-namespaces/README.md#handling-of-volumes

Also if you want root inside of the container, which isn't root 'on the outside', then you also want this. So you can have a limited 'fake privileged' container.

Seems like the Linux kernel, the container runtimes and other parts in between and Kubernetes are getting these features now (they've been in development for a few years, with what seems like slow progress).

I wondered how would it best fit in with Capsule ? Does Capsule need to keep track of user IDs per tenant or something like that ?

[prometherion]

Thanks for opening this feature request, @Lennie!

Of course, this feature is definitely interesting for the multi-tenancy scope, and Capsule aims to cover the use-cases.

If I understood correctly, v1.29 will introduce this feature via Pod Security Standard and Pod Security Admission.

We need to think how we'd like to implement this, such as:

• blocking any Pod which is not running with the desired value
• enforcing any pod by running with the desired value (thanks to Mutating Webhook?)
• anything else

@MaxFedotov @oliverbaehler @bsctl please, jump in the discussion, and also remember Lennie that we can book a community call to elaborate a bit more: as a community, we're open hearing to new proposals!

[oliverbaehler]

Freature will be landing in Kubernetes 1.30!