Kubernetes 容器多租户隔离验证：从 RBAC、资源配额到 NetworkPolicy 的边界实测

在云原生环境中，同一 Kubernetes 集群为多个租户提供服务时，确保资源隔离至关重要。命名空间提供逻辑隔离，但并非安全边界。RBAC、ResourceQuota 和 NetworkPolicy 是构建真实隔离的主要控制点。这些控制点共同构成了多租户隔离的边界，需通过可复现的验证来确认其是否真实有效。

准备工作

创建测试集群后，首先在同一集群内部署多个命名空间作为租户边界。推荐使用官方提供的 ServiceAccount 模板生成低权限账户，并在每个命名空间内创建专用账户。配置 RBAC Role 或 ClusterRole，限制账户仅能操作特定命名空间内的资源（如 Pod、ConfigMap 或 Secret），并禁用跨命名空间的权限绑定。ResourceQuota 则需在目标命名空间中定义，用于限制 CPU 和内存使用量，避免“ noisy neighbor”问题。NetworkPolicy 应提前规划，默认采用 DenyAll 策略，并明确放行必要的 DNS 流量（通过 CoreDNS 服务）。

验证前建议记录当前集群的 CNI 插件版本（如 Cilium、Calico 或 Flannel），因为 NetworkPolicy 实现依赖底层网络代理，这直接影响默认行为和策略生效条件。使用 kubectl 命令批量创建测试资源，包括低权限 ServiceAccount、跨命名空间的 Secret、测试 Pod 以及网络测试工具（如 curl）。

RBAC 权限边界验证

RBAC 通过 rbac.authorization.k8s.io API 组驱动授权决策，是第一道权限边界。以下是具体验证步骤：

1. 在租户命名空间 A 创建低权限 ServiceAccount，绑定 Role 仅授予读取该命名空间 Secret 的权限。
2. 从命名空间 A 的 ServiceAccount 尝试读取命名空间 B 的 Secret，预期应被拒绝。
3. 尝试在命名空间 A 创建特权 Pod 或访问其他租户的 Service，记录结果。
4. 对比审计日志，确认拒绝操作的 API 调用是否被正确拦截。

如果验证通过，说明 RBAC 成功将权限边界锁定在命名空间级别。失败常见于默认 ClusterRole 绑定未正确限制或 ServiceAccount 跨命名空间的 Secret 引用未受控。

ResourceQuota 与 LimitRange 资源配额验证

ResourceQuota 工具可强制租户在资源使用上保持公平份额，避免单租户资源饥饿。实施验证如下：

1. 在命名空间 B 创建 ResourceQuota 对象，设置 CPU 请求上限和内存限制。
2. 尝试从租户 Pod 创建资源（例如部署一个内存占用超限的 Pod），观察是否返回配额不足错误。
3. 同时测试 LimitRange 对 Pod 容器的默认资源请求设置是否生效。
4. 记录资源使用指标（如 kubectl top pod），确认超出配额时是否被 kube-scheduler 拒绝。

此验证强调边界条件：配额仅影响新资源创建，对已存在的资源无强制回收作用。资源配额与 LimitRange 共同解决“noisy neighbor”风险，但需结合实际负载测试，避免过度限制导致租户资源浪费。

NetworkPolicy 网络边界验证

NetworkPolicy 实现网络流量隔离，依赖底层 CNI 插件的 NetworkPolicy 控制器。验证重点在于确认隔离是否“真实有效”，而非仅看配置清单。

1. 在命名空间 A 创建 NetworkPolicy，拒绝所有 ingress 和 egress 流量。
2. 从命名空间 A 的 Pod 使用 curl 访问命名空间 B 的 Service，预期返回连接超时或拒绝。
3. 测试 DNS 放行：确保 CoreDNS 服务仍能解析其他命名空间的域名（默认策略通常允许此流量）。
4. 对比不同 CNI 实现的结果：Calico 默认 DenyAll，Cilium 可能需额外配置，Flannel 则可能保留部分全通行为。

常见误判包括：以为默认策略是拒绝所有，实际因 CNI 不同导致全通；或 DNS 流量被意外阻挡，需额外在 NetworkPolicy 中放行 kube-dns 服务。验证失败时，优先排查 CNI 插件日志，再回滚 NetworkPolicy 到默认拒绝状态。

验证结果核对与复盘

将各测试项的预期与实际结果汇总如下表：

验证通过后，建议启用审计日志（kubectl -n kube-system edit deployment kubernetes-dashboard 等方式监控），并定期执行此套测试用例。失败时，按以下顺序排查：先确认 RBAC Role 绑定是否遗漏，再调整 ResourceQuota 配额，最后回滚 NetworkPolicy 策略并更新 CNI 配置。变更后务必备份 YAML 文件，采用金丝雀部署验证稳定性。

此验证方法可将多租户隔离从静态配置清单转为可复现的越权测试流程，强调边界条件与失败回滚。实际应用中，结合具体云平台（如 AKS、EKS）经验调整策略，但避免将单一 CNI 行为泛化成普遍结论。