From d3b6fc6aa85c6264070883eabbe02046bedc3cf8 Mon Sep 17 00:00:00 2001 From: Michael Burke Date: Mon, 13 Oct 2025 15:41:18 -0400 Subject: [PATCH] Linux User Namespace ID-mapped mount inforation --- nodes/pods/nodes-pods-user-namespaces.adoc | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/nodes/pods/nodes-pods-user-namespaces.adoc b/nodes/pods/nodes-pods-user-namespaces.adoc index 70bf338e1747..798b0d60ca69 100644 --- a/nodes/pods/nodes-pods-user-namespaces.adoc +++ b/nodes/pods/nodes-pods-user-namespaces.adoc @@ -12,6 +12,13 @@ By default, a container runs in the host user namespace. Running a container in Running containers in individual user namespaces can mitigate container breakouts and several other vulnerabilities that a compromised container can pose to other pods and the node itself. +When running a pod in an isolated user namespace, the UID/GID inside a pod container no longer matches the UID/GID on the host. In order for file system ownership to work correctly, the Linux kernel uses ID-mapped mounts, which translate user IDs between the container and the host at the virtual file system (VFS) layer. + +[IMPORTANT] +==== +Not all file systems currently support ID-mapped mounts, such as Network File Systems (NFS) and other network/distributed file systems. Any pod that is using an NFS-backed persistent volume from a vendor that does not support ID-mapped mounts might experience access or permission issues when running in a user namespace. This behavior is not specific to {product-title}. It applies to all Kubernetes distributions from Kubernetes v1.33 onward. +==== + // The following include statements pull in the module files that comprise // the assembly. Include any combination of concept, procedure, or reference // modules required to cover the user story. You can also include other