在了解到这个问题并参考此指南后，我想进一步探索。该仓库包含几个 Pod 部署和辅助 Shell 脚本，以最简单的方式演示了攻击机制，使 Kubernetes 管理员和运维人员能够充分理解其严重性和潜在风险。您必须是已认证用户，或者能够在创建 Pod 时控制其 spec/template，因此这种逃逸不太可能以匿名方式发生，除非与其他攻击（如这个）结合使用。
当 Kubelet 挂载卷/密钥/配置映射等时，它会错误地跟随卷内部的符号链接，访问到本应限制范围之外的位置。由于 Kubelet 以 root 身份运行，这意味着它可能被欺骗，将主机文件系统的特权部分挂载到非特权 Pod 的容器内。
我的方法是使用一个包含两个“普通”容器的 Pod。一个容器创建指向 / 或 /home/ubuntu 的符号链接，另一个容器持续崩溃重启直到操作成功（强制重新挂载卷并跟随该符号链接路径），从而允许用户通过 exec 进入第二个容器并访问挂载点。
注意：这些示例在 Ubuntu 16.04 主机上无需修改即可运行，但也可轻松调整以适用于其他环境。
./run-as-root.sh。./run-as-root-no-chroot.sh 或 ./run-as-user-1000.sh 以查看其他变体。
这确实是一个“必须修补”的情况。遗憾的是，此处列出的变通方案对大多数人来说并不实用。几乎所有早期版本都存在漏洞。