Kubernetes RBAC 对象详解

1. 概述

RBAC（Role-Based Access Control）是 Kubernetes 的授权机制，基于“角色”来授予权限。核心模型是：

主体（Subject） → 绑定（Binding） → 角色（Role/ClusterRole） → 规则（Rules）

RBAC 是纯允许模型：

没有显式拒绝规则。
默认拒绝。
多个角色/绑定的权限是并集。
只要有一条规则允许，请求就通过。
认证（Authentication）解决“你是谁”，RBAC 解决“你能做什么”。

2. 核心对象

RBAC 有四个核心对象，API 组为 rbac.authorization.k8s.io/v1。

对象	作用域	作用
`Role`	命名空间	定义命名空间内资源的权限规则
`ClusterRole`	集群	定义集群范围、所有命名空间或非资源 URL 的权限规则
`RoleBinding`	命名空间	将 `Role` 或 `ClusterRole` 绑定到主体，权限限制在命名空间内
`ClusterRoleBinding`	集群	将 `ClusterRole` 绑定到主体，授予集群范围权限

2.1 Role

命名空间级别，只能授予该命名空间内资源的权限。

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

2.2 ClusterRole

集群级别，可用于：

集群范围资源，如 nodes、persistentvolumes、namespaces。
所有命名空间中的命名空间资源，如 pods、configmaps。
非资源 URL，如 /healthz、/metrics。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

2.3 RoleBinding

命名空间级别，把主体绑定到 Role 或 ClusterRole。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: ServiceAccount
  name: my-sa
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

注意：

RoleBinding 可以引用 Role，也可以引用 ClusterRole。
引用 ClusterRole 时，权限仍只在该 RoleBinding 所在命名空间内生效。
不能通过 RoleBinding 授予集群范围资源权限。

2.4 ClusterRoleBinding

集群级别，只能引用 ClusterRole，授予集群范围权限。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-nodes
subjects:
- kind: ServiceAccount
  name: my-sa
  namespace: default
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

3. 主体 Subject

绑定中的 subjects 可以是：

类型	说明
`User`	由认证系统提供，不是 Kubernetes 对象
`Group`	由认证系统提供，不是 Kubernetes 对象
`ServiceAccount`	Kubernetes 对象，格式为 `namespace:name`

常见组：

system:authenticated：所有已认证用户。
system:unauthenticated：未认证用户。
system:masters：超级管理员组。
system:serviceaccounts：所有 ServiceAccount。
system:serviceaccounts:<namespace>：某命名空间下所有 ServiceAccount。

ServiceAccount 的用户名格式：

system:serviceaccount:<namespace>:<name>

4. 规则字段

RBAC 规则主要包含以下字段：

字段	说明
`apiGroups`	API 组，核心组为空字符串 `""`
`resources`	资源名，如 `pods`、`deployments`、`configmaps`
`verbs`	操作，如 `get`、`list`、`watch`、`create`、`update`、`patch`、`delete`
`resourceNames`	可选，限制特定资源名称，通常用于单个资源操作
`nonResourceURLs`	非资源 URL，仅用于 `ClusterRole`

常见 apiGroups：

""：核心组，如 Pod、Service、ConfigMap、Secret。
apps：Deployment、StatefulSet、DaemonSet。
batch：Job、CronJob。
networking.k8s.io：Ingress、NetworkPolicy。
rbac.authorization.k8s.io：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

子资源写法：

resources: ["pods/log", "pods/exec", "deployments/scale"]

5. 作用域与绑定关系

角色	绑定	效果
`Role`	`RoleBinding`	授予命名空间内权限
`ClusterRole`	`ClusterRoleBinding`	授予集群范围权限
`ClusterRole`	`RoleBinding`	授予该命名空间内权限，不能授予集群范围资源
`Role`	`ClusterRoleBinding`	不允许

关键点：

ClusterRole + RoleBinding 很常用：定义通用权限，只在指定命名空间生效。
ClusterRoleBinding 权限大，慎用。
RoleBinding 不能授予 nonResourceURLs 权限。

6. 授权流程

请求到达 API Server。
认证组件确定用户、组、ServiceAccount。
授权组件检查所有适用的 RoleBinding / ClusterRoleBinding。
合并所有允许规则。
如果任一规则允许，则通过；否则拒绝。
没有拒绝规则，不能显式禁止某个主体。

7. 默认角色

Kubernetes 自带一些默认 ClusterRole：

角色	说明
`cluster-admin`	超级管理员，所有权限
`admin`	命名空间管理员，可管理大多数资源，包括 RBAC
`edit`	可编辑大多数资源，不能管理 RBAC
`view`	只读大多数资源，不能查看 Secret
`system:discovery`	允许访问 API 发现接口
`system:basic-user`	允许用户查看自己的信息

默认绑定：

cluster-admin 绑定到 system:masters 组。
system:discovery 绑定到 system:authenticated 组。

8. 常用命令

# 创建 Role
kubectl create role pod-reader --verb=get,list,watch --resource=pods

# 创建 ClusterRole
kubectl create clusterrole node-reader --verb=get,list,watch --resource=nodes

# 创建 RoleBinding
kubectl create rolebinding read-pods \
  --role=pod-reader \
  --serviceaccount=default:my-sa \
  --namespace=default

# 创建 ClusterRoleBinding
kubectl create clusterrolebinding read-nodes \
  --clusterrole=node-reader \
  --serviceaccount=default:my-sa

# 检查权限
kubectl auth can-i get pods \
  --as=system:serviceaccount:default:my-sa \
  -n default

# 列出某主体所有权限
kubectl auth can-i --list \
  --as=system:serviceaccount:default:my-sa \
  -n default

# 应用并协调 RBAC
kubectl auth reconcile -f rbac.yaml

9. 最佳实践

最小权限原则：只授予必需的资源和动词。
优先使用 RoleBinding：尽量避免 ClusterRoleBinding。
绑定到 ServiceAccount：应用权限通过 ServiceAccount 授予，而不是 User。
避免给 default ServiceAccount 授权：每个命名空间都有 default SA，容易误用。
使用 resourceNames 限制：对单个资源操作可精确限制。
不要直接修改默认 ClusterRole：使用聚合或自定义 ClusterRole。
定期审计：检查高权限绑定、cluster-admin、system:masters。
GitOps 管理：RBAC 配置纳入版本控制。
使用聚合 ClusterRole：通过标签选择器组合规则，便于扩展。

10. 常见误区

误区	正确理解
RBAC 可以拒绝权限	RBAC 没有拒绝规则，只有允许和默认拒绝
RoleBinding 引用 ClusterRole 就能获得集群权限	只能获得该命名空间内权限
ClusterRoleBinding 可以绑定 Role	只能绑定 ClusterRole
ConfigMap 更新会触发 RBAC 更新	RBAC 是独立授权对象，不会自动触发 Pod 滚动
认证通过就有权限	认证解决身份，授权解决权限
多个角色权限会冲突	权限是并集，没有优先级

11. 总结

Kubernetes RBAC 通过四个核心对象工作：

Role：命名空间内权限。
ClusterRole：集群范围或跨命名空间权限。
RoleBinding：命名空间内绑定。
ClusterRoleBinding：集群范围绑定。

核心原则：

主体通过绑定获得角色，角色包含规则；规则是纯允许，默认拒绝，权限取并集。
设计时坚持最小权限，优先 RoleBinding，谨慎使用 ClusterRoleBinding。

posted @ 2026-10-15 10:40 ignibera 阅读(13) 评论(0) 收藏举报

刷新页面返回顶部

ignibera