上个月，一个客户的容器集群出了事。

某天凌晨，监控告警响个不停——CPU 异常飙高，网络流量暴涨。运维登录一看，几十个容器在疯狂挖矿。追溯来源，发现是某个开发同学从公开仓库拉了一个基础镜像，里面被人植入了挖矿程序。那个镜像在 Docker Hub 上有上百万下载，藏得极深，普通扫描根本没发现。

挖矿程序跑了三天，账单多了两万美金。更麻烦的是，客户数据有没有外泄？不知道。要排查多久？不知道。

事后复盘，他们发现一个扎心的事实：容器化做了一年，CI/CD 跑得挺欢，但安全从来没跟上。镜像随便拉、容器特权随便给、网络策略没开过。出事只是时间问题。

今天聊聊云上容器安全。不是那种“安全很重要”的废话，而是帮你理清楚：从镜像构建到运行时，到底该怎么一步步把安全防线搭起来。

01 先认清一个现实：容器不是虚拟机

很多人刚接触容器时，会不自觉地把它当虚拟机用——ssh 进去、装软件、改配置。这是最危险的想法。

容器和虚拟机的本质区别在于内核共享。虚拟机有独立内核，虚拟化层隔离了 Guest OS 和 Host OS。容器直接共享宿主机内核，一旦容器突破隔离，就能直接影响宿主机，甚至攻击其他容器。

这意味着什么？容器逃逸漏洞的杀伤力，比虚拟机逃逸大得多。

2019 年爆发的 RunC 漏洞 CVE-2019-5736，攻击者可以在容器内覆盖宿主机上的 RunC 二进制文件，从而获得宿主机 root 权限。这漏洞在 Docker、Kubernetes 上都存在，影响面极广。

所以容器安全的第一个原则是：别把容器当虚拟机用，也别指望内核隔离能挡住所有攻击。

02 镜像安全：从源头堵住漏洞

容器安全的第一道防线，在镜像构建阶段。

基础镜像选谁？

很多人图方便，直接从 Docker Hub 拉 latest。这是最大的坑。Docker Hub 上有大量官方镜像，但更多是第三方上传的，质量参差不齐，甚至有人故意上传带后门的镜像。

基本原则：用官方镜像，或者用你信得过的镜像仓库。 如果必须用第三方，先扫描。

镜像扫描工具

Trivy、Clair、Anchore 这些工具可以扫描镜像里的已知漏洞。把它们集成到 CI/CD 流水线里，镜像构建完自动扫，有高危漏洞直接阻断发布。

有个客户实践：他们在 Jenkins 里加了 Trivy 扫描，阈值设为“存在高危漏洞就失败”。刚开始天天构建失败，因为基础镜像里一堆老漏洞。后来逼着团队换基础镜像、升级依赖包，三个月后镜像质量明显提升。

镜像签名

怎么确保拉下来的镜像是你构建的那个，没人改过？镜像签名。

Docker Content Trust 和 Notary 可以实现镜像签名，拉取时可以验证。虽然配置复杂点，但对核心业务系统来说值得。

03 配置安全：别给攻击者开后门

镜像没问题，不代表容器安全。运行时配置不当，照样能捅娄子。

别给特权

最危险的配置是 privileged: true。给了特权，容器就几乎等同于宿主机 root，逃逸是分分钟的事。

另一个是 allowPrivilegeEscalation: true，允许进程获得比父进程更多的权限。大部分场景用不上，关掉。

只读根文件系统

如果容器不需要写文件系统，设成 readOnlyRootFilesystem: true。攻击者想往容器里写东西就没门了。

禁止跑 root

容器内默认用 root 跑进程，这是历史遗留问题。最佳实践是：创建镜像时指定非 root 用户，运行时也用这个用户。

Kubernetes 里可以设 runAsNonRoot: true，强制容器不以 root 运行。

Seccomp 和 AppArmor

这些是 Linux 内核的安全机制，可以限制容器能调用的系统调用。默认配置已经很严格，但你可以根据自己的应用进一步收紧。

04 运行时安全：盯着异常行为

镜像扫了，配置锁了，容器跑起来了。然后呢？得盯着它。

Falco：云原生运行时安全标准

Falco 是 CNCF 孵化项目，专门做运行时行为监控。它会监控系统调用，发现异常就告警。

比如：

• 容器里启动了新的 shell（可能是入侵者在反弹 shell）

• 读写敏感文件（/etc/shadow）

• 网络连接异常

Falco 的规则可以自定义，告警可以发到 Slack、钉钉、邮件。部署简单，DaemonSet 一装就行。

异常检测

有条件的可以用商业方案，比如 Aqua、Prisma Cloud，带机器学习行为分析，能发现更隐蔽的异常。

05 网络安全：隔离是第一原则

容器之间默认可以互通。这不是好事——一个容器被攻破，攻击者可以横向移动去扫其他容器。

Kubernetes NetworkPolicy

NetworkPolicy 是 K8s 的网络隔离机制。可以定义哪些 Pod 能互相通信，哪些不能。

最佳实践：默认拒绝所有流量，再按需放开。 比如只允许前端 Pod 访问后端 Pod 的 8080 端口，别的都拒绝。

Cilium、Calico 这些 CNI 插件都支持 NetworkPolicy，功能更强，还能做七层策略。

服务网格

Istio、Linkerd 这类服务网格，可以在应用层做 mTLS 加密和访问控制。对安全要求高的场景，值得上。

06 供应链安全：别被第三方坑了

镜像里的漏洞可以扫，但有些风险扫不出来——比如依赖的第三方库有没有恶意代码？

SBOM：软件物料清单

SBOM 就是你的应用用了哪些组件、什么版本的清单。出事的时候，能快速定位哪些组件受影响，需不需要升级。

镜像来源可信

拉镜像时检查签名，前面说过了。还有一点：尽量用私有镜像仓库，别从公网直接拉。至少要在中间加一层代理镜像仓库，做统一扫描和缓存。

07 一个真实案例

去年帮一个金融客户做容器安全加固。他们的应用跑在 K8s 上，几百个 Pod，但安全几乎是裸奔。

我们做了四件事：

第一，CI/CD 里加 Trivy 扫描，有高危漏洞阻断发布。刚开始 70% 的镜像都不合格，花了三个月清理基础镜像和依赖，现在通过率 95% 以上。

第二，Pod 安全配置标准化。所有新部署必须符合一系列规则：禁止特权、只读根文件系统、非 root 用户。不符合的不让上线。

第三，部署 Falco，配置关键告警规则。上线第一个月就抓到两次异常：一次是开发调试时在容器里开了 shell，一次是某容器试图读 /etc/shadow（后来发现是配置问题）。

第四，NetworkPolicy 落地。先给核心业务加，再逐步推广。现在 90% 的命名空间都有默认拒绝策略。

半年后再看，再也没有发生过运行时安全事件。安全团队从“天天救火”变成了“定期看报表”。

写在最后

那个挖矿的客户，后来把容器安全从头做了一遍。前前后后花了三个月，换来了什么？

安全负责人说：“最大的收获不是省了多少钱，是晚上能睡着了。”

这话挺实在。容器跑起来容易，跑得安全难。镜像扫描、配置加固、运行时监控、网络隔离、供应链验证——每一层都不能少。

但也不用一口吃成胖子。从镜像扫描开始，先堵住最明显的漏洞。再慢慢加配置策略，加运行时监控，加网络隔离。一步步走，总能走到。

你的容器集群，现在跑到第几步了？