RBAC 是什么
RBAC 用三要素描述权限：主体（User、Group、ServiceAccount）、角色（Role 或 ClusterRole）与绑定（RoleBinding 或 ClusterRoleBinding）。Role 只在命名空间内有效，ClusterRole 既可授予集群级资源（节点、PV、CRD）的权限，也能被多个命名空间的 RoleBinding 复用作角色模板。Pod 内程序调用 API 时使用的身份是 ServiceAccount。授权的原则是最小必要：限定命名空间与动词，而不是图省事给通配符。
基本信息
| ServiceAccount | Pod 在集群内的身份，默认 SA 的权限应尽可能小 |
|---|---|
| Role | 命名空间内的权限，由 apiGroups、resources、verbs 三部分描述 |
| ClusterRole | 集群级资源权限，或被跨命名空间复用的角色模板 |
| 绑定 | RoleBinding 授权到主体；ClusterRoleBinding 在全集群范围生效 |
| 权限审计 | kubectl auth can-i --as=system:serviceaccount:<ns>:<sa> 反查某身份能否执行某操作 |
典型使用场景
- 给 CI 机器人只授予目标命名空间的部署权限，避免误改其他业务
- 给监控组件只读权限：get、list、watch Pod 与节点指标即可
- 多团队共用集群时按命名空间隔离权限，各自只管自己的命名空间
- 为应用授予读取自身配置与日志的权限，避免用高权限账号跑业务
- 权限审计与收敛：批量找出谁拥有通配符权限并逐步替换为精确授权
最小权限示例
最小权限示例
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: ci-read
namespace: dev
subjects:
- kind: ServiceAccount
name: ci-bot
namespace: dev
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
验证某身份的实际权限
验证某身份的实际权限
kubectl auth can-i --list --as=system:serviceaccount:dev:ci-bot -n dev
kubectl auth can-i delete pods --as=system:serviceaccount:dev:ci-bot -n dev
kubectl get rolebinding,clusterrolebinding -A -o wide | head对象与作用范围
| 对象 | 作用范围 | 典型用途 |
|---|---|---|
| Role | 单个命名空间 | 命名空间内的用户、组或 ServiceAccount |
| ClusterRole | 集群范围或被绑定复用 | 集群级资源权限，跨命名空间统一角色 |
| RoleBinding | 单个命名空间 | 把 Role 或 ClusterRole 授予主体 |
| ClusterRoleBinding | 全集群 | 全局权限，使用前必须充分评估 |
不要用管理员级别的 ClusterRole 给 CI 或机器人账号：一个凭据泄露就等于整个集群沦陷，应按命名空间加动词做最小授权。
默认 ServiceAccount 会被自动挂载进该命名空间下的所有 Pod，只要它拥有任何权限，等于每个工作负载都继承了这份权限；不需要访问 API 的工作负载应关闭自动挂载，需要访问的则单独建 SA 并精确授权。