Namespace隔离的常见误区

很多团队把 Kubernetes 里的 Namespace 当成“安全保险箱”，觉得只要把不同业务、不同环境塞进不同的 Namespace，彼此就彻底隔离开了。这种想法就像在办公室用玻璃隔板区分工位——能看见彼此，甚至能递纸条，但总觉得有块玻璃就安全了。Namespace 的设计初衷是逻辑分组，不是安全边界，这一点经常被忽略。

误区一：Namespace 默认提供网络隔离

Kubernetes 默认网络模型允许所有 Pod 互相通信，无论它们属于哪个 Namespace。这意味着，只要你知道目标 Pod 的 IP 或 Service 名称，就可以跨 Namespace 发起连接。我曾见过一个案例：测试环境的 Pod 直接访问了生产环境的数据库，就是因为两个 Namespace 之间没有配置 NetworkPolicy，而开发者想当然地以为“不在同一个 Namespace 就访问不了”。实际上，没有显式网络策略时，整个集群就是一个扁平网络。Namespace 只是把资源归类到不同文件夹，并没有拉起防火墙。

误区二：RBAC 权限只在本 Namespace 生效

另一个常见隐患是 RoleBinding 的范围理解错误。Role 可以限定在某个 Namespace，但 ClusterRoleBinding 能跨 Namespace 授予权限。很多团队只检查了 Role 本身，却忽略了 ClusterRole 被绑定到 ServiceAccount 后，可以在所有 Namespace 内读取 Secret、修改 Deployment。曾经有个团队把监控 ServiceAccount 绑定了 cluster-admin 权限，理由是“方便采集指标”，结果这个 ServiceAccount 被一个存在漏洞的 Pod 窃取，攻击者直接拿到了整个集群的控制权。Namespace 隔离在这里形同虚设。

误区三：资源配额只影响性能，不影响安全

很多人把 ResourceQuota 和 LimitRange 当作“防止某个 Namespace 吃光资源”的工具，却忘了它们也是隔离的一部分。如果某个 Namespace 没有设置配额，一个恶意或失控的 Pod 可以耗尽节点资源，导致同一节点上其他 Namespace 的 Pod 被驱逐。这种“资源饥饿”攻击并不需要突破网络或 RBAC，仅仅靠抢占 CPU 和内存就能造成服务中断。Namespace 隔离若没有资源限制兜底，就像小区没有门禁卡——谁都能进来抢车位。

误区四：Secret 放在 Namespace 里就安全了

Secret 本身只做了 Base64 编码，不是加密。真正保护 Secret 的是 RBAC 和 etcd 加密。但很多团队把 Secret 当作“存进去就万事大吉”，结果因为 RoleBinding 配置过宽，开发 Namespace 的 Pod 也能读取生产 Namespace 的 Secret。更隐蔽的问题是：Secret 默认不加密存储在 etcd 中，如果 etcd 被访问，所有 Namespace 的 Secret 都会暴露。Namespace 隔离无法阻止 etcd 层面的数据泄露。

更务实的做法

Namespace 应该被当作“组织单元”，而非“安全单元”。真正的隔离需要组合 NetworkPolicy（限制网络流量）、RBAC（限制权限）、ResourceQuota（限制资源）以及 etcd 加密（保护静态数据）。每加一层，隔离的可靠性就上升一级。别再指望 Namespace 替你挡子弹了——它只是个文件夹标签，真正的安全要靠显式配置来堆叠。