Any plans for supporting user namespaces? #3318
Replies: 1 comment 4 replies
-
The security guidance is a bit confusing on account of "user namespace support" being somewhat overloaded and confused with "rootless" containers which also require user namespaces. For the kernel feature specifically, user namespaces are supported today but disabled by default, meaning that In the specific case of Crossplane, it looks like increasing For "rootless" containers, where the goal is usually something along the lines of running another container manager that will also run containers - such as running docker-in-docker or podman in a Kubernetes pod - user namespaces aren't supported. That would require the pod spec to set The major blocker to this is the "alpha" state of the feature in Kubernetes; as that feature moves toward GA, we'll add support to Bottlerocket. That's a longer road since we need a 6.3+ kernel (for idmapped mounts), updated versions of containerd and runc with idmapped mount support, and some additional host tools for runc. |
Beta Was this translation helpful? Give feedback.
-
Security docs say it's currently not supported: https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_GUIDANCE.md#do-not-run-containers-as-uid-0
Moving forward, it seems like a good security improvement for containerized workloads, and I suppose it would be good for Bottlerocket to support it.
One example of new stuff that relies on user namespaces is Crossplane's default implementation of its functions runtime, XFN: crossplane/crossplane#3899
Unfortunately, this does not currently work on Bottlerocket and it's making us consider a different distro just for these nodes that will run Crossplane.
Beta Was this translation helpful? Give feedback.
All reactions