无特权构建Docker镜像时seccomp/apparmor放开与容器内root安全性对比

结论 #

你的判断是正确的，kaniko方案的安全性显著高于img方案，核心原因是内核级强制访问控制和系统调用过滤的防护优先级，远高于容器内用户权限层级。

核心安全逻辑分析 #

• 内核级防护的价值远高于容器内用户权限限制
  Docker默认启用的seccomp过滤规则会禁用超过400个存在风险的系统调用，覆盖了绝大多数容器逃逸、内核提权漏洞依赖的调用入口；默认AppArmor规则会限制容器进程访问宿主机敏感文件、跨进程通信、修改系统配置等危险操作。这两层是内核层面的强制兜底防护，一旦禁用相当于给容器进程开放了所有内核能力的调用入口，即使是普通用户权限的进程也可以利用未被拦截的系统调用漏洞完成提权和宿主机逃逸。

• 两种方案的风险面对比

  • img方案虽然用非root用户运行，但直接禁用了seccomp和AppArmor防护，相当于放弃了最核心的内核安全兜底。目前公开的多个Linux内核漏洞（例如部分user namespace相关漏洞、脏页提权漏洞）都不需要root权限即可触发，攻击者只要拿到容器内普通用户的执行权限，就有大概率直接获取宿主机root权限。
  • kaniko方案虽然进程在容器内以root身份运行，但仅开放了构建镜像必须的chown、fowner、setgid、setuid、dac_override5个最小权限capability，同时保留了默认seccomp和AppArmor防护。即使容器内的root权限被攻击者控制，也无法调用被seccomp拦截的危险系统调用，也突破不了AppArmor的访问限制，完成容器逃逸的难度要高数个量级。

行业落地参考 #

目前公有云CI/CD服务、企业内部符合安全合规要求的镜像构建场景，几乎都选择kaniko作为无特权构建方案，核心原因就是安全团队普遍评估「禁用seccomp/AppArmor」属于不可接受的高风险配置。

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