📚 课程目录第3章租户隔离模型

3、租户隔离模型：Namespace隔离、RBAC权限模型、NetworkPolicy网络策略

在控制平面升级后，租户隔离的通信机制验证依赖于三层纵深防御模型：Namespace 提供资源边界，RBAC 控制用户与 ServiceAccount 的操作权限，NetworkPolicy 实现 Pod 粒度的网络访问控制。三者协同构成 Kubernetes 多租户隔离的基石。

3.1 Namespace 隔离：资源边界与逻辑分区

Namespace 是 Kubernetes 中实现租户逻辑隔离的第一层。每个 Namespace 拥有独立的资源配额、服务发现域名和资源对象集合。控制平面升级后，需验证 Namespace 的创建、删除以及资源隔离是否正常。

隔离维度	说明	升级后验证要点
资源对象隔离	Pod、Service、ConfigMap 等资源仅在同一 Namespace 内可见	跨 Namespace 访问资源是否被拒绝
服务发现隔离	DNS 格式为 `<service>.<namespace>.svc.cluster.local`	跨 Namespace 服务解析是否正常
资源配额隔离	ResourceQuota 和 LimitRange 按 Namespace 生效	配额限制是否在升级后仍生效
网络命名空间隔离	每个 Pod 拥有独立网络命名空间	Pod 间通信是否受 Namespace 边界影响

验证提示： 使用 kubectl get pods -n <namespace> 确认资源隔离；使用 kubectl run --image=busybox test -- nslookup <service>.<namespace>.svc.cluster.local 验证跨 Namespace 服务发现。

3.2 RBAC 权限模型：用户与 ServiceAccount 的访问控制

RBAC（Role-Based Access Control）是 Kubernetes 中管理用户、ServiceAccount 和 API 资源访问权限的核心机制。控制平面升级后，需验证 RBAC 规则是否被正确保留，以及权限校验逻辑是否正常。

3.2.1 RBAC 核心组件

Role / ClusterRole：定义一组权限规则，Role 作用于特定 Namespace，ClusterRole 作用于集群范围。
RoleBinding / ClusterRoleBinding：将 Role 或 ClusterRole 绑定到用户、组或 ServiceAccount。
Subject：权限的授予对象，包括 User、Group、ServiceAccount。

3.2.2 升级后验证清单

验证项	预期行为	验证命令示例
Role 权限保留	升级前创建的 Role 规则不变	`kubectl describe role <name> -n <ns>`
RoleBinding 绑定有效	Subject 仍能获取对应权限	`kubectl auth can-i list pods --as=system:serviceaccount:ns:sa`
ClusterRole 集群范围生效	ClusterRole 规则在所有 Namespace 生效	`kubectl describe clusterrole <name>`
ServiceAccount 权限隔离	不同 SA 的权限互不影响	使用不同 SA 执行 `kubectl auth can-i`
聚合 ClusterRole 正常	通过 aggregationRule 聚合的权限正确合并	`kubectl get clusterrole <name> -o yaml`

升级风险提示： 控制平面升级可能导致 RBAC 控制器重启，需确认 kube-controller-manager 的 RBAC 相关参数（如 --authorization-mode=RBAC）未被修改。建议升级后对所有关键 ServiceAccount 执行权限冒烟测试。

3.3 NetworkPolicy 网络策略：Pod 粒度的网络访问控制

NetworkPolicy 是 Kubernetes 中实现 Pod 网络隔离的关键资源。它通过标签选择器定义 Pod 的入站（Ingress）和出站（Egress）规则。控制平面升级后，需验证 NetworkPolicy 的规则是否被 CNI 插件正确解析和执行。

3.3.1 NetworkPolicy 规则结构

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tenant-isolation
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    - namespaceSelector:
        matchLabels:
          tenant: tenant-a
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

3.3.2 升级后验证要点

规则持久性：升级前创建的 NetworkPolicy 在升级后仍被 CNI 插件加载。
默认拒绝：未匹配规则的 Pod 应被默认拒绝（取决于 CNI 实现）。
标签选择器：基于 Pod 标签和 Namespace 标签的匹配逻辑正确。
端口与协议：TCP/UDP/SCTP 端口规则生效。
双向策略：Ingress 和 Egress 规则同时生效时，通信路径完整。

  验证方法： 使用 kubectl run --image=busybox test-pod --rm -it -- sh 进入测试 Pod，通过 wget 或 nc 测试目标 Pod 的端口可达性。结合 kubectl describe networkpolicy <name> 确认规则状态。

3.4 三层隔离模型协同验证

在控制平面升级后，需对三层隔离模型进行端到端验证，确保 Namespace、RBAC、NetworkPolicy 协同工作正常。

验证场景	Namespace 隔离	RBAC 权限	NetworkPolicy	预期结果
同 Namespace 内 Pod 通信	允许	不涉及	按规则放行	通信正常或按策略限制
跨 Namespace Pod 通信	需显式放行	不涉及	需允许跨 Namespace 规则	默认拒绝，策略放行后正常
ServiceAccount 访问 API	不涉及	按 RoleBinding 授权	不涉及	授权操作成功，未授权操作拒绝
外部客户端访问 Pod	不涉及	不涉及	Ingress 规则控制	按 NetworkPolicy 放行或拒绝
Pod 访问外部服务	不涉及	不涉及	Egress 规则控制	按 NetworkPolicy 放行或拒绝

最佳实践： 建议在升级前导出所有 Namespace、RBAC 和 NetworkPolicy 资源清单（kubectl get --export -o yaml），升级后使用 kubectl diff 或 kubectl apply --dry-run=server 验证资源一致性。对于 NetworkPolicy，可使用 kubectl run 创建临时 Pod 进行连通性测试。