如何防止容器内部运行的进程获得root权限

关于是否需要卸载su程序 #

卸载su属于镜像攻击面收敛的可选操作，不是核心解决方案。即便移除了su，攻击者仍然可能通过其他带SUID位的程序、内核漏洞等路径完成提权，仅靠卸载su无法从根本上解决风险。

核心防范措施 #

• 开启用户命名空间（User Namespace）映射
  配置Docker daemon开启用户命名空间，将容器内的root用户映射为宿主机上的无特权普通UID/GID，这样即便容器内进程拿到root权限，在宿主机层面也仅对应用户权限，无法读写宿主机高权限资源，也无法执行root级操作。
• 运行容器时添加--security-opt no-new-privileges参数
  该参数会禁止容器内进程获得比启动进程更高的权限，所有SUID/SGID程序都会失效，哪怕su命令保留在镜像中，普通用户也无法通过su切换到root，是成本最低、效果最明显的防护手段。
• 移除容器所有不必要的特权能力
  运行容器时添加--cap-drop ALL参数，丢弃Docker默认给容器开放的所有Linux capabilities，即便攻击者拿到容器内root权限，也没有执行挂载、修改文件权限、操作网络栈等特权操作的权限。如果业务需要特定能力，可以单独用--cap-add添加必要的能力。
• 严格控制挂载卷的权限与范围
  • 非必要场景下，挂载宿主机目录时指定readonly参数，禁止容器对宿主机目录的写入权限
  • 宿主机层面给待挂载的目录设置最小权限，仅开放容器运行用户对应的UID/GID的必要访问权限，其他用户无权限
  • 禁止挂载/dev、/sys、/proc、/etc、/var/run/docker.sock等敏感宿主机路径
• 镜像最小化加固
  优先使用distroless、alpine等精简基础镜像，不安装业务不需要的工具；可以选择移除su、sudo等提权工具，或者移除su的SUID位（执行chmod u-s /bin/su），进一步收敛攻击面。
• 指定数字UID/GID运行容器
  运行容器时使用-u <UID>:<GID>的格式指定用户，而非容器内的用户名，避免容器内用户名和宿主机权限映射冲突导致的越权问题。

内容的提问来源于stack exchange，提问作者mnj