4. 多租户模型设计：命名空间(Namespace)作为租户边界，RBAC与网络策略的协同

在多租户 Kubernetes 集群中，命名空间（Namespace）是最基础、最自然的租户隔离边界。每个租户独占一个或多个命名空间，所有工作负载、配置和网络资源都在该边界内运行。然而，仅靠命名空间无法实现真正的安全隔离——必须将 RBAC（基于角色的访问控制）与 NetworkPolicy（网络策略）深度协同，才能构建从“管理平面”到“数据平面”的完整租户隔离体系。

4.1 命名空间作为租户边界的核心原则

将命名空间视为租户边界时，需遵循以下设计原则：

4.2 RBAC 与 NetworkPolicy 的协同模型

RBAC 控制“谁能做什么”（管理平面），NetworkPolicy 控制“哪个 Pod 能与哪个 Pod 通信”（数据平面）。两者协同才能形成完整的租户隔离矩阵：

4.2.1 协同层次结构

1. 第一层：RBAC 命名空间准入 — 租户管理员只能看到和操作自己命名空间内的 Deployment、Service、Pod 等资源。
2. 第二层：NetworkPolicy 默认拒绝 — 在租户命名空间内创建默认拒绝所有入站/出站流量的策略，防止 Pod 被意外暴露。
3. 第三层：显式允许策略 — 根据业务需求，通过 NetworkPolicy 开放特定端口和标签选择器，允许跨命名空间通信（如共享数据库服务）。
4. 第四层：审计与监控 — 结合 RBAC 审计日志和网络流量日志，验证隔离策略是否被绕过。

4.3 典型多租户网络策略设计模式

以下 SVG 图展示了三个租户（Tenant-A、Tenant-B、Tenant-C）在共享集群中的网络隔离架构，以及 RBAC 与 NetworkPolicy 的协同作用点：

4.4 RBAC 与 NetworkPolicy 协同配置示例

以下是一个完整的 Helm Chart 模板片段，展示如何在部署时同时创建 RBAC 角色和网络策略：

{{- /* templates/tenant-isolation.yaml */ -}}
{{- range .Values.tenants }}
---
apiVersion: v1
kind: Namespace
metadata:
  name: {{ .name }}
  labels:
    tenant: {{ .name }}
    environment: {{ .environment | default "production" }}
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: {{ .name }}-admin
  namespace: {{ .name }}
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["networking.k8s.io"]
  resources: ["networkpolicies"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: {{ .name }}-admin-binding
  namespace: {{ .name }}
subjects:
- kind: User
  name: {{ .adminUser }}
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: {{ .name }}-admin
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: {{ .name }}
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-intra-tenant
  namespace: {{ .name }}
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          tenant: {{ .name }}
  policyTypes:
  - Ingress
{{- end }}

4.5 多租户网络策略命中与隔离验证矩阵

下表总结了不同场景下 RBAC 与 NetworkPolicy 的协同效果：

4.6 最佳实践与避坑指南

• 标签标准化： 所有命名空间必须包含统一的租户标签（如 tenant-id），NetworkPolicy 的 namespaceSelector 依赖此标签进行跨命名空间授权。
• 默认拒绝策略先行： 在创建任何允许策略之前，先部署 default-deny-ingress 和 default-deny-egress，避免策略生效前的窗口期暴露。
• RBAC 最小权限： 租户管理员角色只授予其命名空间内的 NetworkPolicy 管理权限，禁止修改集群级别的 ClusterNetworkPolicy（如果使用 Cilium 等 CNI）。
• 审计与告警： 开启 Kubernetes 审计日志，监控 NetworkPolicy 的创建/更新/删除操作，并设置告警规则检测非预期的策略变更。
• Helm 模板化： 将租户配置抽象为 values.yaml 中的列表，通过 range 循环生成命名空间、RBAC 和 NetworkPolicy，确保一致性并减少手工错误。