2. Kubernetes Namespace 与 RBAC：多租户隔离的基石

在多租户集群中，Namespace 提供逻辑上的资源隔离边界，而 RBAC（基于角色的访问控制） 则定义谁能在这些边界内执行哪些操作。两者结合，构成了 Kubernetes 多租户隔离的第一道防线。

2.1 Namespace：逻辑隔离单元

Namespace 将集群内的资源划分为互不干扰的虚拟分组。每个 Namespace 拥有独立的资源配额、网络策略和权限控制，但底层共享同一个物理集群。

2.1.1 核心隔离能力

2.1.2 创建与使用

# 创建 Namespace
kubectl create namespace tenant-alpha

# 在 Namespace 中部署资源
kubectl run nginx --image=nginx -n tenant-alpha

# 查看 Namespace 资源配额
kubectl get resourcequota -n tenant-alpha

2.2 RBAC 权限模型：谁能在 Namespace 内做什么

RBAC 通过四个核心对象定义权限：Subject（谁）、Resource（什么资源）、Verb（什么操作）、Role/ClusterRole（权限集合）。

2.2.1 核心概念对比

2.2.2 权限绑定流程

1. 定义 Role：声明对哪些资源拥有哪些操作权限。
2. 创建 Subject：确定用户、用户组或 ServiceAccount。
3. 建立绑定：通过 RoleBinding 或 ClusterRoleBinding 将 Role 赋予 Subject。
4. 验证权限：使用 kubectl auth can-i 检查。

# 1. 创建 Namespace 只读 Role
kubectl create role namespace-reader --verb=get,list,watch --resource=pods,services -n tenant-alpha

# 2. 创建 ServiceAccount
kubectl create serviceaccount tenant-user -n tenant-alpha

# 3. 绑定 Role 到 ServiceAccount
kubectl create rolebinding tenant-reader-binding --role=namespace-reader --serviceaccount=tenant-alpha:tenant-user -n tenant-alpha

# 4. 验证权限
kubectl auth can-i list pods --as=system:serviceaccount:tenant-alpha:tenant-user -n tenant-alpha

2.3 多租户 RBAC 架构设计

生产级多租户集群通常采用 分层 RBAC 模型：集群级 ClusterRole 管理基础设施，Namespace 级 Role 管理租户资源。

2.4 实战：为租户配置最小权限

遵循 最小权限原则，每个租户只获得完成工作所需的最小权限集。

2.4.1 租户管理员权限模板

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: tenant-alpha
  name: tenant-admin
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "secrets", "persistentvolumeclaims"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets", "daemonsets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["autoscaling"]
  resources: ["horizontalpodautoscalers"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant-alpha
  name: tenant-admin-binding
subjects:
- kind: ServiceAccount
  name: alpha-admin-sa
  namespace: tenant-alpha
roleRef:
  kind: Role
  name: tenant-admin
  apiGroup: rbac.authorization.k8s.io

2.4.2 权限粒度对照表

2.5 常见陷阱与避坑指南

• 陷阱 1： 忘记在 Role 中定义 apiGroups，导致资源匹配失败。例如，Deployment 属于 apps 组，而非核心组。
• 陷阱 2： 多个 RoleBinding 叠加时，权限取 并集。若一个绑定授予 delete 权限，另一个绑定限制只读，最终用户仍可 delete。
• 陷阱 3： ServiceAccount 的 泄露。生产环境应使用 短期 或集成 OIDC，避免将长期 硬编码在配置文件中。

2.6 验证与审计

使用以下命令定期审计租户权限配置：

# 查看指定 Namespace 的所有 RoleBinding
kubectl get rolebinding -n tenant-alpha -o wide

# 查看指定用户的有效权限
kubectl auth can-i --list --as=system:serviceaccount:tenant-alpha:alpha-admin-sa -n tenant-alpha

# 使用 kubectl-who-can 插件查看谁有权操作特定资源
kubectl who-can delete pods -n tenant-alpha