云原生安全最佳实践：从开发到运维的全链路防护

云原生让部署变快了，也让攻击面变多了：镜像来自哪里、依赖里有什么、容器跑起来后能碰到什么，每一环都可能出事。这篇讲我们在项目里按什么顺序补这些洞——先做最容易被利用的，再谈平台建设。

供应链：从镜像和依赖开始

绝大多数云原生入侵不是从漏洞利用开始的，而是从"你信任了一个不该信任的东西"开始的。2024 年 3 月的 xz-utils 后门事件就是典型：一个被广泛依赖的压缩库差点带着后门进入大量 Linux 发行版的生产环境。它提醒我们两件事——依赖越深越要能追溯，发布前的检查不能只靠人工。

我们的做法按成本从低到高排：

• 基础镜像只用官方或自建的，并在流水线里固定 digest（而不是 latest），保证"构建两次得到同一个环境"。
• 镜像与依赖都扫：镜像扫描 + 依赖漏洞扫描（Trivy、Snyk 这类工具接进 CI），把"高危且可修复"设为门禁，其余进清单定期处理——全量卡死会让团队直接绕开流程。
• 生成并保留 SBOM（软件物料清单）：出了新漏洞，能在一小时内回答"我们哪些服务受影响"，而不是连夜翻 Dockerfile。
• 私有仓库（Harbor 这类）统一存放与扫描，禁止生产直接拉公网镜像。

运行时：最小权限 + 异常可见

容器跑起来之后，攻击者的横向移动最难被发现。我们在集群里落三件事：

1. 最小权限。Pod 按安全标准配置（禁止特权模式、只读根文件系统、非 root 用户运行），并用 NetworkPolicy 限制"只能访问它必须访问的服务"。
2. 异常检测。用 Falco 这类基于 eBPF 的工具监控异常行为——容器里起了 shell、访问了不该访问的文件、外连陌生地址。这类告警比事后审计有用得多。
3. 响应流程要编排好。告警之后谁做什么必须写清楚：隔离（摘掉 Service 或替换 Pod）→ 保留现场（快照镜像与日志）→ 通知责任人 → 建事件工单。我们把它做成自动化链路，目标是把第一个动作压进 30 秒内。

密钥：别再放环境变量和配置文件里

密钥（数据库口令、第三方 API Key、证书私钥）最常见的三个问题是：进了 Git 历史、写死在镜像里、永远不轮换。我们的做法是：

• 统一从密钥管理服务取（Vault 或云厂商 KMS），应用启动时注入，仓库里零密钥。
• 定期轮换，并把轮换做成流程而不是事故后的补救——先让"能轮换"这件事本身可用。
• 密钥读取要有审计日志：谁、什么时候、取了哪个密钥。出事时这条线索比什么都值钱。

上线前的五问

每次发版前，我们会确认这五件事——它们覆盖了绝大多数"低级但致命"的问题：

1. 镜像与依赖的高危漏洞处理了吗？有没有遗留项与责任人？
2. 这个服务需要哪些权限和网络访问？多余的开通了吗？
3. 密钥来自哪里？是否进过代码仓库？
4. 日志里会不会打印敏感数据（手机号、身份证、token）？
5. 出异常时如何隔离与取证？值班的人知道流程吗？

安全这件事，顺序比工具重要：先把容易被利用的洞补上，再谈平台与自动化。我们帮客户做过云原生环境的安全基线与合规整改，如果你正在准备等保或上云评审，欢迎联系我们先做一次现状盘点。