RBAC 权限控制

集群是多人共用的基础设施，若人人都能 delete Pod、看 Secret，事故与泄密只是时间问题。RBAC（基于角色的访问控制）用「角色」定义权限、用「绑定」把角色授给主体，让每个用户或程序只拥有完成任务所需的最小权限。

核心概念与关系

RBAC 由四类对象组成：

• 主体（Subject）：User（人）、Group（用户组）或 ServiceAccount（Pod 内程序）。
• Role / ClusterRole：一组权限规则，如「可 get/list pods」。
• RoleBinding / ClusterRoleBinding：把角色授予主体。

关系可理解为「谁(主体) + 能做什么(角色) + 在哪(作用域)」：

RoleBinding(命名空间内) ──绑定──> Role(限某命名空间)
       │                        ClusterRole(全局)
ClusterRoleBinding(全局) ──绑定──> ClusterRole(全局)

Role 与 ClusterRole 的区别

• Role 只作用于某个命名空间；ClusterRole 作用于整个集群（可用于所有命名空间或集群级资源）。
• 跨命名空间复用角色、管理集群级资源（节点、PV、Namespace）时必须用 ClusterRole。

示例：只读 Pod 权限

先建一个可查看 Pod 的 ClusterRole，再通过 RoleBinding 授给某命名空间内的用户：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]              # 核心组：Pod、Service 等
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: alice-pod-read
  namespace: default             # 只对 default 生效
subjects:
  - kind: User
    name: alice                  # 主体：用户 alice
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

verbs 常用 get/list/watch/create/update/patch/delete；把 roleRef 换成 Role 即把命名空间内角色授给集群内所有用户。

验证权限

绑定完成后用 auth can-i 模拟检查某主体能否执行某操作：

kubectl auth can-i list pods --as=alice -n default
# 输出：yes
kubectl auth can-i delete pods --as=alice -n default
# 输出：no

ServiceAccount 与自动挂载 Token

ServiceAccount（SA）是 Pod 内程序访问 API 的身份，每个命名空间有默认的 default SA。Pod 创建时会自动挂载该 SA 的 Token 用于认证；若应用不需要访问 API，建议关闭自动挂载以减小泄露面：

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  automountServiceAccountToken: false   # 不自动挂载 Token
  containers:
    - name: app
      image: nginx

需要访问 API 时再单独创建 SA、授予最小权限并显式引用。

最小权限建议

• 只授予完成工作必需的最小 verbs 与 resources。
• 能限定命名空间就用 Role + RoleBinding，确需全局才用 ClusterRole/ClusterRoleBinding。
• 定期用 auth can-i 复核权限，清理闲置的绑定。
• 注意 roleRef 一旦创建不可修改，调整角色只能删除重建绑定。

小结：RBAC 用 Role/ClusterRole 定义规则、RoleBinding/ClusterRoleBinding 把规则授给 User/ServiceAccount；先想清主体要对哪些资源做哪些操作，再按最小权限落地，并用 auth can-i 随时验证。