<p>Docker supports <a href="https://docs.docker.com/engine/security/userns-remap/" rel="nofollow noreferrer">user namespace remapping</a>, so that the user namespace is completely separated from the host.</p>
<p>The current default behavior ensures that containers get their own user and group management, i.e. their own version of <code>/etc/passwd</code> and <code>/etc/group</code>, but container processes are run under the same identical UIDs on the host system. This means if your container runs with UID 1 (root), it will also run as root on the host. By the same token, if your container has user &quot;john&quot; with UID 1001 installed and starts its main process with that user, on the host it will also run with UID 1001, which might belong to user &quot;Will&quot; and could also have admin rights.</p>
<p>To make user namespace isolation complete, one needs to enable <strong>remapping</strong>, which maps the UIDs in the container to different UIDs on the host. So, UID 1 on the container would be mapped to a &quot;non-privileged&quot; UID on the host.</p>
<p>Is there any support in Kubernetes for this feature to be enabled on the underlying Container Runtime? Will it work out of the box without issues?</p>

<p>So, it's not supported yet like <a href="https://docs.docker.com/engine/security/userns-remap/" rel="noreferrer">Docker</a> as per <a href="https://github.com/kubernetes/enhancements/issues/127" rel="noreferrer">this</a> (as alluded in the comments) and <a href="https://github.com/kubernetes/kubernetes/issues/59152" rel="noreferrer">this</a>.</p>

<p>However, if you are looking at isolating your workloads there are other alternatives (it's not the same, but the options are pretty good):</p>

<p>You can use <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy" rel="noreferrer">Pod Security Policies</a> and specifically you can use <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/#users-and-groups" rel="noreferrer">RunAsUser</a>, together with <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/#privilege-escalation" rel="noreferrer">AllowPrivilegeEscalation=false</a>. Pod Security Policies can be tied to RBAC so you can restrict how users run their pods.</p>

<p>In other words, you can force your users to run pods only as 'youruser' and disable the <code>privileged</code> flag in the pod <a href="https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" rel="noreferrer"><code>securityContext</code></a>. You can also disable <code>sudo</code> and in your container images.</p>

<p>Furthermore, you can drop Linux <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/#capabilities" rel="noreferrer">Capabilities</a>, specifically <code>CAP_SETUID</code>. And even more advanced use a <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp" rel="noreferrer">seccomp</a> profile, use <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/#selinux" rel="noreferrer">SElinux</a> or an <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/#apparmor" rel="noreferrer">Apparmor</a> profile. </p>

<p>Other alternatives to run untrusted workloads (in alpha as of this writing):</p>

<ul>
<li><a href="https://katacontainers.io/" rel="noreferrer">Kata Containers</a></li>
<li><a href="https://nabla-containers.github.io/" rel="noreferrer">Nabla Containers</a></li>
<li><a href="https://github.com/google/gvisor" rel="noreferrer">gVisor</a></li>
</ul>
