以 root 身份运行容器是生产环境中最常见且最危险的错误配置之一。它悄悄扩大了每个工作负载的攻击面，大多数团队直到发生安全事件才意识到这个问题。
"以 Root 身份运行"的实际含义
默认情况下，许多容器镜像（尤其是最小化或遗留镜像）在容器内以 UID 0 执行主进程。由于容器与其他容器和主机共享主机内核，容器内的 root 与完全隔离虚拟机上的 root 不同——但仍然拥有远超其应有的权限。如果攻击者在 root 拥有的容器内实现了代码执行，他们将继承：
- 对挂载到容器中的任何文件的完全读写访问权限，无论预期的权限如何
- 安装软件包、修改二进制文件或篡改应用程序状态的能力
- 在内核或运行时漏洞可被利用时，更容易实现容器逃逸
- 当与配置不当的卷（如挂载的 Docker socket 或主机文件系统路径）结合时，提升的利用杠杆
即使没有内核漏洞，容器内的 root 访问权限也会大幅增加任何应用层漏洞（SSRF、反序列化漏洞、任意文件写入等）的影响范围。
为什么这在编排环境中更为重要
在 Kubernetes 集群中，root 容器加上过度的 Linux 能力或宽松的安全上下文可以让攻击者：
- 以影响主机的方式修改
/proc或/sys - 在启用
hostPID、hostNetwork或hostIPC时提升权限 - 滥用挂载的服务账户令牌以在集群中进行横向移动
- 在设置
privileged: true时或授予SYS_ADMIN等危险能力时逃逸到节点
root 用户本身不总是漏洞——真正的问题是 root 加上过度宽松的内核能力、主机挂载或命名空间共享的组合，将容器内的妥协转变为集群范围的妥协。
实际加固步骤
1. 在镜像中设置非 Root 用户
在 Dockerfile 中显式定义非 root 用户，而不是依赖默认值：
FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser2. 在编排器级别实施策略
不要仅仅信任镜像——在运行时在编排器级别实施策略。在 Kubernetes 中，使用 securityContext：
securityContext:
runAsNonRoot: true
runAsUser: 10001
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]runAsNonRoot: true 会导致 Pod 在镜像尝试以 UID 0 运行时在准入时失败，为你提供硬保证而不是尽力而为的约定。
3. 删除不必要的 Linux 能力
大多数应用程序不需要授予容器的默认 Linux 能力中的任何一个。删除所有能力，仅添加回绝对必需的能力（少数情况下，如绑定到低端口的应用可能需要 NET_BIND_SERVICE）。
4. 避免特权模式和主机命名空间共享
privileged: true、hostNetwork: true 和 hostPID: true 应保留用于非常特定的基础设施工作负载（如某些 CNI 或监控代理）——绝不用于通用应用容器。
5. 使用策略工具扫描和实施
使用准入控制器或策略引擎（如 Kyverno、OPA/Gatekeeper）自动拒绝违反这些规则的部署，而不是依赖手动代码审查。结合 CI 中的镜像扫描，在 root 用户镜像到达集群之前将其捕获。
分层而非完美的防御
以非 root 身份运行不会完全消除风险——内核级容器逃逸独立于容器内用户存在——但它消除了大量低成本的权限提升和横向移动技术。结合只读文件系统、删除的 Linux 能力和限制性网络策略，它在防御深度容器安全策略中形成了最便宜且最有效的层之一。
想要深入了解云原生工作负载的加固？探索相关的 Korra Studio 段落，涵盖云安全和 DevOps 管道加固，以完成你的防御深度战略。
