多租户集群防越权的实测排错步骤

很多人对多租户隔离有个朴素理解：给每个租户分一个命名空间，事情就成了。可真动手测一遍就会发现，命名空间只是把东西分堆放，不构成安全边界。真正决定租户之间能不能越界的，是三处开关——谁能调什么、能用多少资源、能不能互相访问。配置清单写得漂亮不代表生效，得实测。

权限这关，先拿低权限账户去撞墙

在租户 A 的命名空间里建一个低权限账户，只给读本命名空间 Secret 的权限，然后拿它去读租户 B 的 Secret。预期是被拒绝。如果居然读到了，通常不是权限系统坏了，而是默认的 ClusterRole 绑定没收紧，或者跨命名空间的引用没受控。顺手再试两件事：能不能在 A 里建特权 Pod，能不能访问 B 的 Service。最后对一遍审计日志，看那些被拒的调用是真的被拦在门外，还是只是命令回显了错误。

配额和网络，误判最多的地方

资源这关相对直白：在租户 B 设好 ResourceQuota，部署一个明显超限的 Pod，看是否返回配额不足；再看 LimitRange 有没有给容器补上默认请求。这里有个容易忽略的边界——配额只拦新建，已经跑起来的资源不会被强制回收。

网络这关最容易翻车。写一条拒绝所有进出的策略，不等于流量真的断了，结果取决于底层 CNI。原文提到，Calico 默认拒绝，Cilium 可能需要额外配置，Flannel 可能保留部分全通行为。所以别只看策略对象存在与否，从 A 的 Pod 用 curl 打 B 的 Service，看是超时还是通了。同时记得确认 DNS 还能解析——把 CoreDNS 的流量一起掐掉，是常见的事故。

失败了按什么顺序查

排错顺序比排错本身更重要：先确认 RBAC 的 Role 绑定有没有遗漏，再回头调配额，最后才回滚 NetworkPolicy 并更新 CNI 配置。每次变更前备份 YAML，用金丝雀的方式小范围验证。

这套流程真正的价值，是把"看起来隔离了"变成"能重复证明隔离了"。毕竟越权这种事，从来不会提前打招呼。