4C — 外层救不了内层
一句话总结
Cloud → Cluster → Container → Code。这四层 外层包裹着内层，却替代不了内层。云防火墙再完美，如果代码里没有授权检查，正常用户也能看到别人的数据。
为什么需要它
“加强安全”这句话没有指向任何方向。是收紧防火墙，是整顿 RBAC，是扫描镜像，还是增加代码评审——全都是安全，但 它们防范的威胁完全不同。
4C 模型整理了这种混乱。因为它说清楚了每一层能防住什么，以及 哪些事在原理上防不住。
工作原理
四层及各自的管辖范围
| 层 | 控制手段 | 在这一层能防住的 | 在这一层防不住的 |
|---|---|---|---|
| Cloud/基础设施 | 网络边界、IAM、节点操作系统、物理安全 | 从互联网直接连到 apiserver、etcd | 持有合法凭据的内部人员 |
| Cluster | 认证/授权（RBAC）、准入、网络策略、审计日志 | 无权限的 API 调用、危险的 Pod 规格 | 在权限范围内发生的滥用 |
| Container | 镜像来源与扫描、最小权限运行、只读根文件系统 | 有漏洞的基础镜像、以 root 运行 | 应用逻辑缺陷 |
| Code | 授权检查、输入验证、Secret 处理、依赖管理 | IDOR、注入、硬编码的密钥 | 上面各层的配置失误 |
为什么外层救不了内层
有三个原因。
第一，外层不知道请求的含义。云防火墙只看到“谁向哪里打开了 TCP”。合法登录的用户调用 GET /v1/orders/10422，这是他自己的订单还是别人的订单，防火墙没有判断的依据。做出这个判断所需的信息在数据库里。
第二，内层的缺陷在外层看来是正常流量。IDOR 攻击的请求能通过认证，响应码也是 200。没有一个失败的请求，所以也不会触发告警。
第三，各层依赖彼此的假设。容器即使以最小权限运行，只要节点被攻陷，该节点上所有容器会一起沦陷。反过来，节点再牢固，如果代码把凭据转储到日志里，这个值就会流进日志索引。
所以该怎么用
4C 不是“全都做”，而是用来追问 “这个威胁在哪一层防范最便宜也最可靠” 的工具。
- 互联网上开放了 etcd 的 2379 端口 → Cloud 层的问题。用防火墙把它关掉才是正解，加强 etcd 认证只是次优。
- 开发者读取生产环境的 Secret → Cluster 层（RBAC）的问题。靠代码防不住。
- Pod 以 root 运行 → Container 层。用 PSA 或准入来防。
- 能看到别人的订单 → Code 层。任何基础设施控制都防不住。
在现场相遇的样子
作者的家庭实验室里，出现过一起让 4C 的层间依赖原样显露出来的事件。DHCP 续租使控制平面节点的 IP 从 .111 变成了 .120，整个集群就停了。IP 地址分配这个 Cloud/基础设施层的一件事，就让 Cluster 层整个失灵。
更准确地说，问题出在证书上。apiserver.crt 的 Subject Alternative Name 里只有 .111，没有 .120。由于 TLS 信任绑定在 IP 上，基础设施层里一个地址的改变，破坏了集群层的身份体系。
把同一个集群扩大到 7 个节点之后，也得出了类似的教训。虽然靠 3 个 etcd 成员确保了 quorum，但 controlPlaneEndpoint 被写死成 cp-1 的物理 IP，所以 cp-1 一挂，数据是安全的，却没有人能连上去。“数据可用性和访问可用性是两回事”——这同样是各层无法互相替代的同一个道理。
接下来阅读什么
在后续的阅读材料里，会把每一层的攻击面展开成具体的入口清单。从下一个模块开始，会下沉到 Cluster 层，把 apiserver、etcd、kubelet 一个个拆开来看。