多数云原生事故不是被攻破，是被配错
容器与编排平台带来的最大变化，是基础设施变成了配置文件。这既是效率的来源，也是风险的来源：一份复制过来、没仔细看过的 YAML，可能就打开了本不该开放的端口、给了本不该给的权限、挂载了宿主机的目录。
安全事件的复盘里，一个反复出现的模式是：入侵者并没有使用什么高深漏洞，而是利用了本来就存在的错误配置——暴露了未鉴权的管理接口、容器以特权模式运行、密钥以明文形式写在环境变量里。这也决定了云原生安全的投入优先级：先做基线加固，再谈漏洞扫描。
四层落点
第一层：镜像。 镜像是供应链的产物，也是攻击面的一部分。要做三件事：使用最小基础镜像（减少无用组件与工具链）、对镜像做漏洞与恶意文件扫描、只允许从受信任的镜像仓库拉取。要特别避免“把构建工具和凭据打进生产镜像”这类做法。
第二层：编排。 编排层的重点在权限与策略：
- RBAC 最小化：服务账号不要绑定过宽的集群权限，尤其是涉及跨命名空间读取密钥的权限；
- 准入控制：通过准入策略禁止特权容器、禁止直接使用宿主机网络与路径、要求资源限制；
- 密钥与配置分离：敏感信息进入专用密钥管理，不要留在镜像、代码库或普通配置项里。
这一层最容易出问题的地方是etcd 与 API Server 的暴露面：控制面组件一旦可达，攻击者可以直接读取集群内的全部密钥。
第三层：运行时。 运行时的核心原则是能力最小化：只读根文件系统、移除不需要的 Linux 能力、禁止特权模式、对系统调用做必要限制。同时要检测异常行为——例如容器内突然启动 shell、出现提权尝试、或者进程开始批量访问文件系统。运行时的价值在于：即使镜像里带了恶意内容，也能在执行阶段被拦住。
第四层：网络。 网络策略应当默认拒绝，按需放行。容器网络默认“全通”是很常见的默认状态，而它意味着一台被攻破的容器可以直接横向访问所有其他服务。此外，服务之间的通信建议引入身份认证与加密，避免仅依赖网络位置的信任。
几个高频错误配置
- 容器以特权模式运行，或挂载了宿主机根目录；
- 控制面组件（API Server、etcd、Dashboard）暴露在非受控网络；
- 服务账号权限过宽，可读取全部命名空间的密钥；
- 敏感信息以明文环境变量或配置映射形式存在；
- 镜像使用浮动标签（如 latest），无法确定实际运行的是哪个版本；
- 缺少资源限制，单个容器可耗尽节点资源影响其他业务。
落地建议
建议的顺序是：先做基线核查与准入策略，再做镜像治理，然后是运行时检测，最后补服务间身份。基线核查通常能一次性发现大量高危配置，是投入产出比最高的一步——而且它不需要改变业务架构。
一句话总结：云原生安全的起点不是买工具，而是把“默认允许”改成“默认拒绝”，然后按业务实际需要一条条放行。