容器运行时安全：防止容器逃逸与内核攻击实战
去年一个客户，K8s集群被入侵了。攻击者不是从应用漏洞进来的，是攻破了一个容器，然后从容器里逃逸到了宿主机，拿到了整个集群的控制权。起因是该容器挂载了宿主机的docker.sock。攻击者在容器里执行docker命令，创建新容器，挂载宿主机根目录，然后chroot进去，主机沦陷。
这是容器安全最可怕的场景：一个容器被攻破，整个集群陪葬。
今天聊聊容器运行时安全。不是那种“安全很重要”的入门课，而是帮你理清楚：容器逃逸怎么发生的？怎么加固？怎么在不影响业务的前提下提高隔离性？
01 容器为什么容易逃逸？
容器和虚拟机的最大区别：共享内核。
虚拟机有独立的Guest OS，逃逸需要突破hypervisor，难度极高。容器直接共享宿主机内核，攻击者只要找到内核漏洞或错误配置，就能从容器跳出来。
常见逃逸路径：
内核漏洞：脏牛、CVE-2016-5195等，攻击者在容器内触发，获取宿主机权限
危险挂载：/proc、/sys、docker.sock挂载到容器内，容器可操作宿主机
特权容器：privileged: true，容器几乎等同于宿主机root
用户命名空间配置不当
那家客户就是挂载了docker.sock，让容器内的进程可以控制宿主机docker，直接创建特权容器逃逸。
02 第一道防线：Pod安全配置
很多逃逸是可以靠正确配置防御的。
禁止特权容器：privileged: true等于把宿主机交给容器。K8s中可用PodSecurityPolicy或PodSecurity admission（v1.21+）强制禁止特权容器，也可以直接用OPA Gatekeeper写规则。
只读根文件系统：readOnlyRootFilesystem: true，攻击者无法在容器内写文件。报错时排查一下哪些路径需要写，单独挂载可写卷。
非root用户运行：runAsNonRoot: true，指定runAsUser: 1000（非0）。即使容器被攻破，也是低权限用户，逃逸难度大增。
禁止allowPrivilegeEscalation：设为false，禁止进程获得比父进程更多的权限。
那家客户复盘时发现，如果pod.spec.containers[].securityContext.allowPrivilegeEscalation设为false，即使容器被攻破，也无法提权到root。
03 第二道防线：Linux内核安全机制
Seccomp（系统调用过滤）
限制容器能调用的系统调用，默认不开启，容器可用300+个系统调用，攻击面大。
配置：在Pod中指定securityContext.seccompProfile.type: RuntimeDefault。K8s v1.19开始默认使用RuntimeDefault。可以写自定义Seccomp Profile，只允许业务需要的系统调用。
AppArmor / SELinux
限制容器对文件、网络、能力的访问。多数云K8s发行版默认不加载AppArmor Profile，需要手动配置。
限制capabilities
DROP ALL，再按需添加。默认容器有很多capabilities：CHOWN、NET_ADMIN、SYS_ADMIN等。保留必要capabilities如NET_RAW（ping）即可，SYS_ADMIN这种高危能力不要留。
04 第三道防线：安全沙箱
对于多租户、运行不可信代码的场景，普通容器隔离不够，需要安全沙箱。
gVisor（Google开源）
用户态内核，拦截应用的系统调用，由gVisor内核处理。兼容性好，性能损失约10-20%。适合大多数场景。
Kata Containers
轻量级虚拟机，每个Pod跑在独立VM中，硬件虚拟化隔离。隔离性极强，性能损失较高，适合极高安全要求的场景。
AWS Firecracker
轻量级VMM，用于Lambda和Fargate。微VM，启动快，内存占用小。普通用户不易直接使用。
那家客户后来对敏感服务启用gVisor运行时。虽然CPU开销增加了15%，但再也没发生过容器逃逸。
05 检测与响应：假设已经被攻破
没有绝对的安全。假设容器终将被攻破，提前做好检测。
Falco：CNCF项目，监控容器异常行为。检测规则：容器内执行敏感命令、读取/etc/shadow、挂载敏感路径、启动新进程。检测到异常可触发告警或自动执行措施（如暂停容器）。
审计日志：K8s审计日志记录谁在什么时间对资源做了什么操作。开启，集中存储，定期检查。
那家客户事后部署了Falco，监控容器内的docker命令执行。下次再有人挂载docker.sock，Falco会秒级告警。
06 一个真实案例：一个挂载引发的血案
一个客户，为了方便CI/CD，在Pod里挂载了宿主机的docker.sock。Jenkins Pod里可以直接执行docker命令构建镜像。
攻击者通过一个漏洞进入该Pod，发现docker.sock已挂载，执行docker run -it -v /:/host ubuntu chroot /host，获取宿主机完全控制权。然后从宿主机进入其他Pod，窃取数据库凭证，拖库。
事后修复：
删除docker.sock挂载，改用Kaniko（无需docker.sock）构建镜像
启用Pod Security Admission，禁止特权容器
部署Falco，监控容器内docker命令
安全负责人说：“以前觉得容器安全就是镜像扫描，现在知道了，运行时才是真战场。”
写在最后
容器运行时安全，核心不是跑起来再补，是跑起来之前就加固好。
那家客户的安全负责人后来总结：“禁止特权、非root跑、只读根文件；Seccomp限制系统调用，capabilities能少就少；敏感业务上沙箱；Falco盯着异常行为。”
你的容器，跑在裸核上，还是穿了铠甲？
