RBAC：角色、绑定、权限规则与授权排查

1. RBAC 的整体架构#

RBAC 的四个核心对象：

它们之间的关系：

flowchart TB
    S["Subjects<br/>User / Group / ServiceAccount"]
    B["RoleBinding<br/>Namespace 范围"]
    C["ClusterRoleBinding<br/>集群范围"]
    R["Role<br/>命名空间权限规则"]
    CR["ClusterRole<br/>集群级或可复用规则"]
    S -->|"作为 subjects"| B
    S -->|"作为 subjects"| C
    B -->|"roleRef：同 Namespace 的 Role"| R
    B -->|"roleRef：可复用 ClusterRole"| CR
    C -->|"roleRef：仅能引用 ClusterRole"| CR

需要特别注意：

RBAC 的核心逻辑是：

flowchart LR
    S["主体 Subject"] --> B["绑定 Binding"] --> R["角色 Role"] --> P["权限规则 Rules"]

其中，Role 和 ClusterRole 定义权限，Binding 决定谁能够使用这些权限。

2. Role：命名空间权限规则#

2.1 Role 的作用范围#

Role 是 Namespace 级别的权限定义对象。

例如：

开发人员只需要管理 dev Namespace 中的 Pod，不应该拥有其他 Namespace 的权限。

可以创建一个 Role：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: Role
3
metadata:
4
  name: pod-manager
5
  namespace: dev
6
rules:
7
  - apiGroups: [""]
8
    resources:
9
      - pods
10
    verbs:
11
      - get
12
      - list
13
      - watch
14
      - create
15
      - delete

这段配置表示：

在 dev Namespace 中，允许主体对 Pod 执行：

• 查询单个 Pod。
• 列出 Pod。
• 监听 Pod 变化。
• 创建 Pod。
• 删除 Pod。

但是不能更新 Pod，因为没有授予 update 或 patch 权限。

2.2 apiGroups：资源所属 API 组#

Kubernetes API 并不是所有资源都属于同一个 API 组。

可以通过以下命令查看：

1
kubectl api-resources

输出示例：

1
NAME         SHORTNAMES   APIVERSION
2
pods         po           v1
3
services     svc          v1
4
deployments  deploy       apps/v1
5
jobs                      batch/v1
6
ingresses    ing          networking.k8s.io/v1

注意，APIVERSION 和 RBAC 中的 apiGroups 并不完全相同。

例如：

注意：核心 API 组使用空字符串，而不是 core。

因此，允许用户查看 Deployment：

1
rules:
2
  - apiGroups: ["apps"]
3
    resources: ["deployments"]
4
    verbs: ["get", "list", "watch"]

允许用户查看 Job：

1
rules:
2
  - apiGroups: ["batch"]
3
    resources: ["jobs"]
4
    verbs: ["get", "list", "watch"]

一个 Role 可以包含多条 rules：

1
rules:
2
  - apiGroups: [""]
3
    resources: ["pods", "services"]
4
    verbs: ["get", "list", "watch"]
5

6
  - apiGroups: ["apps"]
7
    resources: ["deployments"]
8
    verbs: ["get", "list", "watch"]
9

10
  - apiGroups: ["batch"]
11
    resources: ["jobs"]
12
    verbs: ["get", "list", "watch"]

这样就可以在一个角色中定义多组不同 API 资源的访问权限。

2.3 resources：资源与子资源#

resources 指定允许操作的 Kubernetes 资源。

例如：

1
resources:
2
  - pods
3
  - services
4
  - configmaps
5
  - secrets

这里有一个重要知识点：Kubernetes 的子资源（Subresources）。

例如 Pod 不仅有自身资源，还有：

• pods/log
• pods/exec
• pods/status
• pods/portforward

它们代表不同的 API 操作入口。

假设用户只允许查看 Pod 日志：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: Role
3
metadata:
4
  name: pod-log-reader
5
  namespace: dev
6
rules:
7
  - apiGroups: [""]
8
    resources: ["pods/log"]
9
    verbs: ["get"]

这个权限只允许读取 Pod 日志，并不自动授予读取 Pod 对象本身的权限。

如果还需要查询 Pod 信息，就要另外授权：

1
rules:
2
  - apiGroups: [""]
3
    resources: ["pods"]
4
    verbs: ["get", "list"]
5

6
  - apiGroups: [""]
7
    resources: ["pods/log"]
8
    verbs: ["get"]

2.4 verbs：允许的操作#

RBAC 常见 verbs：

注意几个容易混淆的地方：

get 和 list 不一样。

1
kubectl get pod nginx -n dev

主要涉及 get 权限。

1
kubectl get pods -n dev

主要涉及 list 权限。

update 和 patch 不一样。

• update：提交完整资源对象进行更新。
• patch：只修改资源的一部分。

如果希望用户既能更新也能部分修改 Deployment：

1
verbs: ["get", "list", "watch", "update", "patch"]

不要为了方便直接使用：

1
verbs: ["*"]

因为这会扩大权限范围。

3. ClusterRole：集群级与可复用规则#

3.1 ClusterRole 与 Role 的区别#

ClusterRole 与 Role 最大的区别是权限定义的适用范围。

Role 只能定义 Namespace 范围的资源权限。

ClusterRole 除了能够定义 Namespace 资源的权限，还能定义集群级资源的权限。

例如：

查看资源作用范围：

1
kubectl api-resources

重点看：

1
NAMESPACED

true 表示属于 Namespace，false 表示属于集群级别。

3.2 创建 ClusterRole#

例如，我们希望创建一个集群监控角色，可以查看：

• Node
• Namespace
• PersistentVolume

配置：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: ClusterRole
3
metadata:
4
  name: cluster-observer
5
rules:
6
  - apiGroups: [""]
7
    resources:
8
      - nodes
9
      - namespaces
10
      - persistentvolumes
11
    verbs:
12
      - get
13
      - list
14
      - watch

这个 ClusterRole 定义了集群级资源的只读权限。

注意：

ClusterRole 也可以定义 Pod、Service、Deployment 等 Namespace 资源的权限。

它并不意味着其中所有权限都一定是集群级别的，真正的使用范围还取决于 Binding 的类型。

4. RoleBinding 与 ClusterRoleBinding：角色绑定#

前面已经知道 Role 和 ClusterRole 负责定义权限。

但是，定义了权限并不代表用户已经获得权限。

必须通过 Binding 将角色与主体关联起来。

4.1 RoleBinding#

RoleBinding 的作用是：

将 Role 或 ClusterRole 授予某个用户、用户组或 ServiceAccount，但授权范围仅限于 RoleBinding 所在的 Namespace。

例如，将前面创建的 pod-manager 授予 Alice：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: RoleBinding
3
metadata:
4
  name: alice-pod-manager
5
  namespace: dev
6
subjects:
7
  - kind: User
8
    name: alice
9
    apiGroup: rbac.authorization.k8s.io
10
roleRef:
11
  kind: Role
12
  name: pod-manager
13
  apiGroup: rbac.authorization.k8s.io

其中有两个关键字段。

subjects：授权对象

可以是三种类型：

1
subjects:
2
  - kind: User
3
    name: alice
4
    apiGroup: rbac.authorization.k8s.io
5

6
  - kind: Group
7
    name: developers
8
    apiGroup: rbac.authorization.k8s.io
9

10
  - kind: ServiceAccount
11
    name: dev-sa
12
    namespace: dev

注意：

• User：不需要填写 Namespace。
• Group：不需要填写 Namespace。
• ServiceAccount：必须指定 Namespace。

roleRef：引用的角色

1
roleRef:
2
  kind: Role
3
  name: pod-manager
4
  apiGroup: rbac.authorization.k8s.io

这里引用的是 dev Namespace 中的 Role。

roleRef 一旦创建，不能直接修改其引用对象。需要更换角色时，通常删除并重新创建 Binding。

4.2 ClusterRoleBinding#

ClusterRoleBinding 的作用是：

将 ClusterRole 授予某个主体，使其在整个集群范围内获得对应权限。

例如，允许 Alice 查看集群所有 Namespace 中的 Pod：

ClusterRole：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: ClusterRole
3
metadata:
4
  name: pod-viewer
5
rules:
6
  - apiGroups: [""]
7
    resources: ["pods"]
8
    verbs: ["get", "list", "watch"]

ClusterRoleBinding：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: ClusterRoleBinding
3
metadata:
4
  name: alice-pod-viewer
5
subjects:
6
  - kind: User
7
    name: alice
8
    apiGroup: rbac.authorization.k8s.io
9
roleRef:
10
  kind: ClusterRole
11
  name: pod-viewer
12
  apiGroup: rbac.authorization.k8s.io

这样 Alice 就可以查看所有 Namespace 中的 Pod。

4.3 最容易混淆的地方：ClusterRole + RoleBinding#

这是 RBAC 中一个非常重要的知识点。

RoleBinding 不仅可以引用 Role，也可以引用 ClusterRole。

例如：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: RoleBinding
3
metadata:
4
  name: alice-pod-viewer
5
  namespace: dev
6
subjects:
7
  - kind: User
8
    name: alice
9
    apiGroup: rbac.authorization.k8s.io
10
roleRef:
11
  kind: ClusterRole
12
  name: pod-viewer
13
  apiGroup: rbac.authorization.k8s.io

这里使用了：

• ClusterRole：定义权限。
• RoleBinding：限制授权范围。

结果是 Alice 只能在 dev Namespace 中查看 Pod。

用一张表总结：

重点理解：角色定义与权限生效范围是两个维度。

flowchart LR
    B["RoleBinding"] --> N["只能在绑定所在 Namespace 授权"]
    C["ClusterRoleBinding"] --> G["在整个集群范围授权"]

RoleBinding 引用 ClusterRole 时，只授予该 Namespace 内的资源权限，不会授予 Node 等集群级资源的访问权限。

ClusterRole 可以复用权限规则，再通过不同的 RoleBinding 实现不同 Namespace 的权限隔离。

5. RBAC 的主体：User、Group、ServiceAccount#

RBAC 不直接管理用户账户，而是根据认证阶段提供的身份信息进行授权。

5.1 User：普通用户#

例如：

1
subjects:
2
  - kind: User
3
    name: alice
4
    apiGroup: rbac.authorization.k8s.io

这里的 Alice 通常来自客户端证书的 CN 字段，或者 OIDC 等外部身份认证系统。

Kubernetes 不会因为你创建了一个叫 Alice 的 RoleBinding，就自动创建 Alice 这个用户。

5.2 Group：用户组#

假设有一个开发团队：

flowchart TB
    G["developers 用户组"] -->|"成员"| A["alice"]
    G -->|"成员"| B["bob"]
    G -->|"成员"| C["charlie"]

如果逐个授权：

1
subjects:
2
  - kind: User
3
    name: alice
4
  - kind: User
5
    name: bob
6
  - kind: User
7
    name: charlie

会比较麻烦。

可以直接给 Group 授权：

1
subjects:
2
  - kind: Group
3
    name: developers
4
    apiGroup: rbac.authorization.k8s.io

只要认证系统能够将这些用户识别为 developers 组成员，他们就可以继承该组对应的权限。

Kubernetes 常见的内置用户组包括：

特别注意：

system:masters 是具有特殊权限含义的内置组，不能将它当作普通开发组使用。

5.3 ServiceAccount：应用程序身份#

例如：

1
subjects:
2
  - kind: ServiceAccount
3
    name: prometheus
4
    namespace: monitoring

ServiceAccount 的完整身份格式：

1
system:serviceaccount:<namespace>:<name>

例如：

1
system:serviceaccount:monitoring:prometheus

它在 RBAC 中可以直接被授权，不需要创建普通 User。

5.4 一个主体可以同时拥有多个角色#

假设 Alice 同时属于：

1
developers
2
testers

那么她可能同时获得：

• developers 组的 Pod 创建权限。
• testers 组的 Pod 查看权限。
• 个人账户的日志查看权限。

RBAC 的权限是累加的。

也就是说：

多个 RoleBinding 和 ClusterRoleBinding 授予的权限会合并，而不是互相覆盖。

这意味着不能通过创建一个权限较低的 RoleBinding 来抵消另一个 Binding 已经授予的权限。

Kubernetes RBAC 本身没有显式的 Deny 规则。

6. RBAC 高级功能#

这一部分开始进入更深入的权限控制。

6.1 通配符权限#

RBAC 支持使用 * 通配符。

例如：

1
rules:
2
  - apiGroups: ["*"]
3
    resources: ["*"]
4
    verbs: ["*"]

表示：

• 所有 API 组。
• 所有资源。
• 所有操作。

这类权限非常大，生产环境中应谨慎使用。

例如：

1
rules:
2
  - apiGroups: [""]
3
    resources: ["pods", "services"]
4
    verbs: ["get", "list", "watch"]

比直接使用通配符更安全。

6.2 resourceNames：限制具体资源名称#

假设一个用户只允许读取名为 app-config 的 ConfigMap，而不能读取其他 ConfigMap。

可以使用 resourceNames：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: Role
3
metadata:
4
  name: config-reader
5
  namespace: dev
6
rules:
7
  - apiGroups: [""]
8
    resources: ["configmaps"]
9
    resourceNames: ["app-config"]
10
    verbs: ["get", "list", "watch"]

这样就限制了允许访问的资源名称。

但需要注意一个重要限制：

如果希望限制 list 或 watch，请求通常还需要携带对应的 metadata.name 字段选择器，否则无法按预期获得授权。

例如：

1
kubectl get configmaps \
2
  --field-selector metadata.name=app-config \
3
  -n dev

因此，不能简单认为配置了 resourceNames 就可以正常执行所有形式的 list 和 watch。

6.3 Role Aggregation：角色聚合#

这是 ClusterRole 的一个高级特性。

假设一个集群中有多个角色：

• 查看 Pod 的角色。
• 查看 Deployment 的角色。
• 查看 Service 的角色。

如果每次都需要将它们分别绑定给用户，会比较麻烦。

Kubernetes 支持通过 aggregationRule 将多个 ClusterRole 聚合为一个 ClusterRole。

例如：

先创建 Pod 查看角色：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: ClusterRole
3
metadata:
4
  name: pod-reader-custom
5
  labels:
6
    app: monitoring
7
rules:
8
  - apiGroups: [""]
9
    resources: ["pods"]
10
    verbs: ["get", "list", "watch"]

再创建 Deployment 查看角色：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: ClusterRole
3
metadata:
4
  name: deployment-reader-custom
5
  labels:
6
    app: monitoring
7
rules:
8
  - apiGroups: ["apps"]
9
    resources: ["deployments"]
10
    verbs: ["get", "list", "watch"]

创建聚合角色：

1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: ClusterRole
3
metadata:
4
  name: monitoring-reader
5
aggregationRule:
6
  clusterRoleSelectors:
7
    - matchLabels:
8
        app: monitoring
9
rules: []

Kubernetes 的 ClusterRole Aggregation Controller 会根据标签选择器，将符合条件的 ClusterRole 权限聚合到 monitoring-reader 中。

查看：

1
kubectl describe clusterrole monitoring-reader

原理：

flowchart TB
    S["aggregationRule<br/>标签选择器 app: monitoring"]
    P["pod-reader-custom<br/>读取 Pod"]
    D["deployment-reader-custom<br/>读取 Deployment"]
    M["monitoring-reader<br/>聚合角色"]
    S -->|"匹配标签"| P
    S -->|"匹配标签"| D
    P -->|"控制器聚合权限"| M
    D -->|"控制器聚合权限"| M

实际使用中，聚合角色的 rules 由控制器管理，不建议手动维护聚合后的规则。

Kubernetes 内置的 view、edit、admin 等 ClusterRole 也使用了角色聚合机制。

6.4 内置 ClusterRole#

查看 Kubernetes 内置角色：

1
kubectl get clusterroles

其中几个重要角色：

例如，将 view 角色授予某个用户：

1
kubectl create rolebinding alice-view \
2
  --clusterrole=view \
3
  --user=alice \
4
  -n dev

这里虽然引用的是 ClusterRole，但使用的是 RoleBinding。

因此 Alice 只能在 dev Namespace 使用 view 权限。

7. RBAC 的安全边界与权限提升风险#

在生产环境中，RBAC 不仅要解决用户能做什么，还要防止用户通过间接方式获得更高权限。

7.1 为什么不能随便授予 edit？#

Kubernetes 内置的 edit 角色允许用户在 Namespace 中管理大量资源。

但是，它并不等于只允许修改业务应用。

例如，用户可能具有创建 Pod 的权限。

如果这个用户能够创建任意 Pod，就可能创建一个挂载敏感 Secret 或使用高权限 ServiceAccount 的 Pod。

因此：

允许创建 Pod，不一定意味着用户只能操作普通业务资源。

例如：

1
spec:
2
  serviceAccountName: privileged-sa

如果 privileged-sa 拥有读取 Secret 或管理 Deployment 的权限，那么能够使用它创建 Pod 的用户，可能间接获得这些权限。

这也是为什么生产环境需要结合以下机制：

• RBAC：限制 API 操作。
• Admission Control：限制不安全的资源配置。
• Pod Security Admission：限制 Pod 的安全配置。
• NetworkPolicy：限制网络通信。
• Secret 管理：保护敏感凭据。

7.2 RBAC 权限提升保护#

Kubernetes 对 Role 和 ClusterRole 的创建、修改有特殊保护。

例如，普通用户不能随意创建一个比自己权限更大的角色，再把这个角色绑定给自己。

相关特殊权限：

例如：

1
rules:
2
  - apiGroups: ["rbac.authorization.k8s.io"]
3
    resources: ["clusterroles"]
4
    verbs: ["bind"]

这类授权具有较高风险。

另外，能够管理 RoleBinding 的用户也可能改变其他主体的权限，所以必须谨慎授权。

7.3 Impersonation：身份模拟#

在 Kubernetes 中，管理员可以模拟其他用户，测试其权限。

例如：

1
kubectl auth can-i get pods --as=alice -n dev

这里的 --as=alice 就涉及用户模拟。

如果想直接以模拟身份执行命令：

1
kubectl get pods \
2
  -n dev \
3
  --as=alice

如果模拟用户组：

1
kubectl get pods \
2
  -n dev \
3
  --as=alice \
4
  --as-group=developers

注意：

执行身份模拟需要当前认证身份具有相应的 impersonate 权限。

8. RBAC 权限排查方法#

实际生产中，经常会遇到：

1
Error from server (Forbidden):
2
pods is forbidden:
3
User "alice" cannot list resource "pods"
4
in API group "" in the namespace "dev"

遇到这种错误，不要马上修改 YAML。

应该先判断到底是哪一层出了问题。

8.1 第一步：确认当前身份#

1
kubectl auth whoami

查看当前 kubeconfig：

1
kubectl config current-context
2
kubectl config view

8.2 第二步：检查权限#

1
kubectl auth can-i list pods -n dev

模拟 Alice：

1
kubectl auth can-i list pods \
2
  --as=alice \
3
  -n dev

如果返回：

1
no

说明当前授权配置没有允许该请求。

8.3 第三步：查看 Role#

1
kubectl get role -n dev

1
kubectl describe role pod-manager -n dev

重点检查：

• apiGroups 是否正确。
• resources 是否正确。
• verbs 是否包含当前操作。
• Role 是否位于正确 Namespace。

8.4 第四步：查看 RoleBinding#

1
kubectl get rolebinding -n dev

1
kubectl describe rolebinding alice-pod-manager -n dev

重点检查：

• subjects 是否正确。
• User、Group、ServiceAccount 类型是否正确。
• ServiceAccount Namespace 是否正确。
• roleRef 是否指向正确的角色。

8.5 第五步：检查是否存在其他授权#

1
kubectl get clusterrolebindings

1
kubectl get rolebindings -A

因为 RBAC 权限是累加的，所以必须检查该主体是否通过其他绑定获得了额外权限。

8.6 一个常见排查误区#

假设：

1
kubectl auth can-i get pods \
2
  --as=alice \
3
  -n dev

返回：

1
yes

但 Alice 实际访问仍然返回：

1
403 Forbidden

这时需要检查：

1. Alice 实际请求是否使用了预期身份。
2. 请求的 Namespace 是否一致。
3. 实际操作是 get 还是 list。
4. 实际资源是否是 pods 或 pods/log。
5. 请求是否访问了不同 API 组或子资源。
6. 是否存在其他授权机制，例如 Webhook 或外部身份系统问题。

kubectl auth can-i 是非常有用的排查工具，但不能代替对真实请求上下文的检查。

9. RBAC 常用命令#

9.1 创建 Role#

1
kubectl create role pod-reader \
2
  --verb=get,list,watch \
3
  --resource=pods \
4
  -n dev

创建多个资源的权限：

1
kubectl create role app-reader \
2
  --verb=get,list,watch \
3
  --resource=pods,services,configmaps \
4
  -n dev

9.2 创建 RoleBinding#

绑定 User：

1
kubectl create rolebinding alice-reader \
2
  --role=pod-reader \
3
  --user=alice \
4
  -n dev

绑定 Group：

1
kubectl create rolebinding dev-reader \
2
  --role=pod-reader \
3
  --group=developers \
4
  -n dev

绑定 ServiceAccount：

1
kubectl create rolebinding sa-reader \
2
  --role=pod-reader \
3
  --serviceaccount=dev:dev-sa \
4
  -n dev

9.3 创建 ClusterRole#

1
kubectl create clusterrole node-reader \
2
  --verb=get,list,watch \
3
  --resource=nodes

9.4 创建 ClusterRoleBinding#

1
kubectl create clusterrolebinding alice-node-reader \
2
  --clusterrole=node-reader \
3
  --user=alice

9.5 使用 ClusterRole 授予 Namespace 权限#

1
kubectl create rolebinding alice-view \
2
  --clusterrole=view \
3
  --user=alice \
4
  -n dev

9.6 查看权限#

1
kubectl auth can-i get pods --as=alice -n dev
2

3
kubectl auth can-i delete pods --as=alice -n dev
4

5
kubectl auth can-i --list --as=alice -n dev

9.7 查看 RBAC 对象#

1
kubectl get roles -A
2

3
kubectl get rolebindings -A
4

5
kubectl get clusterroles
6

7
kubectl get clusterrolebindings