Kubernetes RBAC 权限控制从入门到实战

背景与目标

基于角色的访问控制（Role-Based Access Control，RBAC）是 Kubernetes 默认的权限模型。如果缺乏清晰的角色设计，就会出现“所有人都用 kubeconfig 管理员”的局面，既无法满足最小权限原则，也难以通过审计。本指南聚焦以下问题：

如何快速理解 ServiceAccount、Role/ClusterRole 与 (Cluster)RoleBinding 的关系
在多团队协作下如何划分命名空间和权限边界
编写 YAML/命令创建权限对象并通过 kubectl auth can-i 验证
引入审计日志与常见误区排查，确保上线安全

阅读完成后，你可以为任意团队或自动化系统设计并落地一套可审计的 RBAC 策略。

RBAC 核心概念回顾

组件	作用	作用域
ServiceAccount	Pod 或自动化任务在集群内的身份标识	命名空间内
User / Group	外部用户身份（通常由认证组件下发）	集群级
Role	一组针对命名空间资源的权限（resources + verbs）	单命名空间
ClusterRole	一组针对集群级或跨命名空间资源的权限	集群级
RoleBinding	将 Role 绑定到用户/组/ServiceAccount	绑定所在命名空间
ClusterRoleBinding	将 ClusterRole 绑定到用户/组/ServiceAccount	集群级

设计权限时遵循两个原则：

先定义身份，再授予角色 —— ServiceAccount 或用户本身只代表“谁”，只有绑定角色后才具备“可以做什么”。
最小权限 —— 仅授予完成工作所需的 verb（get/list/watch/create/update/patch/delete/impersonate 等）。

ServiceAccount 生命周期

创建 ServiceAccount

kubectl create sa developer --namespace dev

为 CI/CD 等非人工访问绑定 kubeconfig（K8s v1.24+ 默认不创建 token Secret，需要手动创建）：
```
kubectl -n dev create token developer --duration=24h
```
Pod 中挂载 ServiceAccount：Deployment/Job 的 spec.serviceAccountName 指定即可，实现“应用以特定身份运行”。

角色设计示例

命名空间级 Role

下面的 Role 允许在 dev 命名空间内只读 Pods，并读取日志：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

对应的 RoleBinding：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-readonly
  namespace: dev
subjects:
- kind: ServiceAccount
  name: developer
  namespace: dev
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

验证

kubectl auth can-i list pods --as=system:serviceaccount:dev:developer -n dev
kubectl auth can-i delete pods --as=system:serviceaccount:dev:developer -n dev   # 预期返回 "no"

集群级 ClusterRole

当需要跨命名空间查看资源（如运维 SRE）时，使用 ClusterRole：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: sre-readonly
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "pods/log", "deployments", "replicasets"]
  verbs: ["get", "list", "watch"]

绑定：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: sre-readonly-binding
subjects:
- kind: Group
  name: sre
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: sre-readonly
  apiGroup: rbac.authorization.k8s.io

将公司 LDAP/SSO 中的 sre 组映射到此 ClusterRoleBinding，即可实现“人员离职自动失效”的效果。

多团队分权实践

命名空间隔离：每个业务使用独立 Namespace，资源配额由运维控制。
角色分层：
- *-viewer 只读
- *-editor 允许创建/更新/删除常规工作负载
- *-admin 仅少量人员，具备 Namespace 范围的所有权限
临时特权：通过 ClusterRoleBinding + --timeout 自动回收，或借助 OPA/Kyverno 审批流程。
自动化生成：将角色定义托管在 GitOps 仓库，Review 通过后由 ArgoCD/Flux 推送，保障审计可追溯。

审计与验证

kubectl auth can-i：快速验证某身份是否拥有特定权限。
--as 与 --as-group：模拟外部用户、组。
API 审计日志：在 API Server 启用审计策略，记录谁在何时对哪些资源执行了何种操作。

常用排障命令：

kubectl describe rolebinding dev-readonly -n dev
kubectl get clusterrolebinding sre-readonly-binding -o yaml

错误示例：如果 roleRef 写成 Role 但引用 ClusterRole，会导致绑定失败；务必在 kubectl apply 后查看 kubectl get events -n kube-system。

总结

RBAC 是保障 Kubernetes 多租户和合规的第一道防线。通过清晰的角色命名、最小权限实践、命令行验证与审计，可以让集群既安全又高效。后续文章还将拓展 Pod 安全准入、Network Policy 和镜像准入控制，进一步完善安全基线。

背景与目标​

RBAC 核心概念回顾​

ServiceAccount 生命周期​

角色设计示例​

命名空间级 Role​

集群级 ClusterRole​

多团队分权实践​

审计与验证​

总结​