Kubernetes 对 docker 用户命名空间重映射的支持答案

【问题标题】：Kubernetes support for docker user namespace remappingKubernetes 对 docker 用户命名空间重映射的支持
【发布时间】：2019-04-01 03:53:57
【问题描述】：

Docker支持user namespace remapping，使用户命名空间与主机完全分离。

当前的默认行为确保容器拥有自己的用户和组管理，即它们自己的/etc/passwd 和/etc/group 版本，但容器进程在主机系统上以相同的 UID 运行。这意味着如果您的容器使用 UID 1（root）运行，它也将以 root 身份在主机上运行。同样，如果您的容器安装了 UID 1001 的用户“john”并使用该用户启动其主进程，则在主机上它还将使用 UID 1001 运行，该 UID 可能属于用户“Will”并且也可能有管理员权利。

要使用户命名空间隔离完整，需要启用重新映射，它将容器中的 UID 映射到主机上的不同 UID。因此，容器上的 UID 1 将映射到主机上的“非特权”UID。

Kubernetes 是否支持在底层容器运行时启用此功能？开箱即用是否没有问题？

【问题讨论】：

您可能需要这个的用例是什么？（在我使用过的 Kubernetes 集群上，我从未访问过主机的文件系统，也无法访问任何形式的主机 uid。）
如果没有用户名空间那么用户可以运行 pods/container 为 uid 0 ，root ，这与主机上的 root 相同，并且可以打开所有可能的破坏，而无需启用 uer ns docker引擎，容器中的root是主机上的root
github.com/kubernetes/enhancements/issues/127
看起来正在进行中github.com/kubernetes/enhancements/issues/127
@johnharris85 似乎在 1.14 或 1.15 中可用:)

标签： docker kubernetes namespaces kubernetes-security

【解决方案1】：

因此，根据 this（在 cmets 中提到）和 this，它还不支持 Docker。

但是，如果您正在考虑隔离您的工作负载，还有其他选择（虽然不一样，但选项非常好）：

您可以使用Pod Security Policies，特别是您可以使用RunAsUser，以及AllowPrivilegeEscalation=false。 Pod 安全策略可以绑定到 RBAC，因此您可以限制用户运行其 Pod 的方式。

换句话说，您可以强制您的用户仅以“您的用户”身份运行 pod，并禁用 pod securityContext 中的 privileged 标志。您还可以禁用 sudo 并在您的容器映像中。

此外，您可以删除 Linux Capabilities，特别是 CAP_SETUID。甚至更高级的使用seccomp 配置文件、使用SElinux 或Apparmor 配置文件。

运行不受信任的工作负载的其他替代方案（在撰写本文时处于 alpha 阶段）：

【讨论】：

作为集群管理员，我想保护节点免受在具有 root 权限的 pod 容器中运行的恶意容器进程的影响。如果这样的进程能够突破到节点中，则可能是一个安全问题。作为集群管理员，我想支持所有图像，而不管该图像使用的是什么用户/组。作为集群管理员，如果某些 Pod 需要提升权限，我希望允许它们禁用用户命名空间。
精心设计的 seccomp 配置文件与其他配置文件（caps、selinux、apparmor）可以做到，但很难（非常先进）。在 alpha 中发布了其他替代方案，但还没有完全准备好。 Docker EE 会使用 docker swarm（不是 k8s）来完成。如果不想处理，就等 k8s 或其他 alpha 项目中的用户命名空间成熟。欢迎投稿:-)