Kubernetes 原生的授权体系并没有“租户”这个概念，它提供的是一套基于角色的访问控制机制。要在同一套集群上承载多个团队、多条业务线，就需要我们基于 RBAC 自己去构造出逻辑上的隔离边界。这套边界设计得好，团队之间互不干扰，运维也省心；设计得不好，轻则有人误删别人的资源，重则一个团队拿到了集群管理员权限，整条生产环境都暴露在风险之下。这篇文章结合实际项目经验，聊聊多租户 RBAC 的设计思路、落地配置和容易踩的坑。
在展开之前，先明确本文假设的场景：多个内部团队共享一个生产集群，每个团队有自己的命名空间，团队内的成员分为管理员和普通开发者两种角色，CI 系统也需要以独立身份部署资源。这个场景覆盖了绝大多数中大型公司的实际需求。
多租户隔离的分层设计：为什么命名空间是第一道边界
Kubernetes 中没有独立的租户对象，最接近租户概念的载体就是命名空间。命名空间为资源提供了天然的名称隔离和作用域边界，不同命名空间里可以存在同名的 Deployment、Service 而互不冲突。但必须清醒地认识到，命名空间本身只是资源名称的分隔，并不是安全边界。默认情况下，任何一个有权限创建 Pod 的用户，都可以通过挂载宿主机路径、使用特权容器等方式越出命名空间的范围。所以真正的多租户隔离是分层实现的，RBAC 负责其中 API 访问这一层。
推荐的分层模型是这样的：最外层用命名空间做资源隔离，第二层用 NetworkPolicy 做网络隔离，第三层用 ResourceQuota 和 LimitRange 做资源配额隔离，最后才是 RBAC 做操作权限隔离。RBAC 虽然排在最后一层，但它决定了谁能触达这些配置本身，是整个体系的钥匙。如果一个开发者拥有命名空间内的全部权限，他理论上可以删掉 ResourceQuota 再绕过配额，这一点在角色定义时要特别小心。
在命名空间规划上，建议按照“团队+环境+用途”的规则命名，例如 team-a-prod、team-a-staging。这样的命名方式让 RBAC 绑定关系一目了然，后期做权限审计时也不需要逐个查询。切忌把多个团队混在同一个命名空间里，再指望用标签去区分权限，因为 RBAC 的最小作用域就是命名空间，做不到标签级别的资源过滤。
Role 与 ClusterRole 的选型：一个团队权限模板的完整实现
RBAC 中有四种核心对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding。多租户场景下最常见的错误用法是给每个租户都建 ClusterRoleBinding，这等于把权限放大到了全集群范围。正确的思路是：权限定义用 ClusterRole（可以复用），权限绑定用 RoleBinding（限定在命名空间内）。
ClusterRole 定义了一套权限模板，通过 RoleBinding 绑定到具体命名空间时，它只在该命名空间内生效。这样一个 team-developer 的 ClusterRole 可以被几十个命名空间复用，管理成本大大降低。下面是一个团队开发者角色的定义示例：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: team-developer
rules:
- apiGroups: ["", "apps", "batch"]
resources: ["deployments", "statefulsets", "pods", "pods/log", "services", "configmaps", "jobs", "cronjobs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list"]
- apiGroups: [""]
resources: ["resourcequotas"]
verbs: ["get", "list", "watch"]
注意上面这个角色刻意排除了几类资源：resourcequotas 只读不可改、secrets 只有读权限、没有任何集群级资源如 nodes、namespaces 的操作权。这些细节就是权限边界所在。接下来是绑定环节，为 team-a 命名空间的成员 alice 建立绑定：
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: team-a-developer-binding
namespace: team-a-prod
subjects:
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: team-developer
apiGroup: rbac.authorization.k8s.io
如果 alice 同时在 team-b 工作，只需要再建一个指向 team-b-prod 的 RoleBinding，权限模板完全复用。团队管理员的角色则可以在开发者基础上追加 resourcequotas 的修改权、RoleBinding 的管理权等，但要谨慎决定是否让租户管理员能创建新的 RoleBinding——拥有 bind 权限的用户可以给自己提权，这是 RBAC 提权链上最经典的风险点。如果必须开放，建议通过准入控制策略限制可绑定的角色范围。
对于 CI 系统这类机器身份，推荐为每条流水线创建独立的 ServiceAccount，而不是让所有流水线共用一个高权限账号。ServiceAccount 同样通过 RoleBinding 授权，作用域天然限定在命名空间内，即使 Token 泄露，影响面也可控。
权限审计与失控防护：让权限模型持续可治理
权限建好只是第一步，多租户环境真正的挑战在于权限会随着时间不断膨胀。人员变动、临时授权忘记回收、为了救急临时开的高权限没有撤销，几个月之后集群里的权限关系就成了一笔糊涂账。所以必须建立持续审计的机制。
kubectl 提供了 kubectl auth can-i 命令来模拟权限判断，这是排查权限问题的利器。例如想知道 alice 能否在 team-a-prod 里删除 Deployment，可以执行：
kubectl auth can-i delete deployments -n team-a-prod --as alice # 输出 yes 或 no，加 -v=8 可以看到具体的鉴权请求细节
更进一步，可以定期扫描集群中所有 RoleBinding 和 ClusterRoleBinding，输出一份“谁在哪个命名空间拥有什么权限”的报告。社区有现成的审计工具，例如 rakkess 可以可视化展示权限矩阵，kubectl-who-can 可以反查某个操作被哪些主体持有。把这些扫描纳入定时任务，权限膨胀就能被及时发现。
除了审计，还需要几道防护措施配合 RBAC。其一是启用审计日志，将 API Server 的授权决策记录下来，出现安全事件时可以回溯。其二是配合 Pod Security Admission 强制租户 Pod 不使用特权模式，防止通过容器逃逸绕过 RBAC。其三是把敏感权限的变更纳入审批流程，比如直接用 GitOps 管理所有 RBAC 清单，任何权限变更都需要走代码评审，集群内不允许手工创建绑定关系。这样权限模型本身也是版本化、可回滚的。
最后总结几条经验：权限跟着命名空间走，坚决不把租户用户绑到 ClusterRoleBinding 上；权限模板集中定义、按需绑定；机器身份用独立 ServiceAccount 且最小授权；定期审计加 GitOps 管控，防止权限腐化。RBAC 本身的概念并不复杂，复杂的是在组织协作过程中守住权限边界。把边界设计清楚、把变更流程管住，多租户集群才能真正跑得又稳又安全。
KubernetesRBAC多租户修改时间：2026-09-13 23:32:18