Kubernetes

Kubernetes RBAC 完整详解

·16 分钟阅读·6312 字
K8s原理高阶八股
📋 目录

Kubernetes RBAC 完整详解

核心概念 RBAC（Role-Based Access Control）是 K8s 官方标准权限体系，基于四要素解耦设计：主体、资源、操作、角色。

1. RBAC 基础概念

1.1. 全称

Role-Based Access Control，基于角色的访问控制，K8s 官方标准权限体系，用于管控谁（主体）能对哪些资源执行哪些操作。
从 K8s 1.6 版本正式稳定，替代老旧 ABAC 权限模型，现在集群默认开启。

1.2. 核心设计思想

四要素分离解耦：

  1. 主体（谁）：User 用户、ServiceAccount 服务账号、Group 用户组
  2. 资源（操作对象）：Pod/Deployment/Service/PV 等集群资源
  3. 动作（操作）：create/get/list/watch/update/patch/delete/deletecollection
  4. 作用域（范围）：命名空间内（Role）、全集群（ClusterRole）

不直接给用户赋权，而是权限绑定角色，主体绑定角色，分层复用、便于统一管理。

1.3. 开启方式

kube-apiserver 启动参数必须包含：

--authorization-mode=RBAC

所有鉴权逻辑由 apiserver 统一处理，etcd 中存储权限绑定资源。

2. RBAC 五大核心资源对象（两类维度：命名空间 / 集群级）

2.1. 维度区分

  • 命名空间级（Namespaced）：仅作用单个 ns，资源：Role、RoleBinding
  • 集群级（Cluster-scoped）：跨所有命名空间，全局权限，资源：ClusterRole、ClusterRoleBinding
    ServiceAccount 是命名空间资源；User/Group 集群全局。

2.2. Role 命名空间角色（局部权限）

作用：单个 namespace 内定义一组权限规则，不能跨命名空间生效。
结构核心规则 rules[]：

  • apiGroups：资源所属 API 组（空=核心资源，apps/networking.k8s.io 等）
  • resources：资源类型 pod/deployments/services
  • verbs：允许的操作动作

示例：default 命名空间下只读 Pod、Deployment

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

2.3. ClusterRole 集群角色（全局权限）

  1. 不绑定 namespace，权限作用整个集群所有命名空间；
  2. 可管控集群级资源：Node/PV/Namespace/ClusterRole 等无ns资源；
  3. 内置大量系统预制 ClusterRole：admin、edit、view、cluster-admin（超级管理员）。

示例：集群只读所有 Pod，同时管理节点

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-pod-node-read
rules:
# 所有ns的pod只读
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
# 集群节点查看权限（集群资源无namespace）
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

2.3.1. 内置核心预制 ClusterRole（开箱即用）

  1. cluster-admin：最高权限，所有资源增删改查，等同于集群root
  2. admin：单个命名空间完整读写权限，无法管理集群资源(Node/NS)
  3. edit：命名空间读写，不能修改角色、权限绑定（无rbac操作权限）
  4. view：命名空间只读，无修改/删除权限

2.4. RoleBinding：命名空间绑定

作用：把 User/ServiceAccount/Group 和同命名空间的 Role 绑定，权限仅当前ns生效。
绑定主体 subjects 三种类型：

  • User：外部用户账号（运维人员）
  • ServiceAccount：Pod内部程序使用的服务账号
  • Group：用户分组，批量赋权

示例：绑定default ns的sa到pod-read-role

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: sa-pod-read-binding
subjects:
# 绑定服务账号
- kind: ServiceAccount
  name: app-sa
  namespace: default
# 也可绑定外部用户
# - kind: User
#   name: ops-user
roleRef:
  kind: Role
  name: pod-read-role
  apiGroup: rbac.authorization.k8s.io

2.5. ClusterRoleBinding：集群全局绑定

将主体绑定 ClusterRole，权限全集群所有命名空间生效。
适合管理员、监控组件、跨命名空间中间件（Prometheus、Cilium）。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-cluster-read-binding
subjects:
- kind: ServiceAccount
  name: prometheus-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: cluster-pod-node-read
  apiGroup: rbac.authorization.k8s.io

2.6. ServiceAccount（SA 服务账号）

2.6.1. 定位

Pod 内部程序访问 apiserver 的身份凭证，命名空间级资源，每个ns默认存在 default SA。

  1. 创建SA自动生成关联 Secret，内含 token、ca.crt；
  2. Pod 不指定 serviceAccountName 自动挂载当前ns default SA；
  3. 容器内 /var/run/secrets/kubernetes.io/serviceaccount/ 存放鉴权凭证。

2.6.2. 区别 User vs ServiceAccount

  • User：人使用，外部运维账号，证书/令牌鉴权；
  • ServiceAccount：程序(Pod)使用，集群内部自动签发token。

创建SA示例：

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: default
  name: app-sa

Deployment 绑定SA：

spec:
  template:
    spec:
      serviceAccountName: app-sa # 关键，替换默认default

3. 两种绑定模式：ClusterRole 复用在命名空间（重要）

ClusterRole 是全局角色，除了 ClusterRoleBinding 全局绑定，还能通过 RoleBinding 限定到单个命名空间使用：

# RoleBinding 引用 ClusterRole，权限仅作用本ns
roleRef:
  kind: ClusterRole
  name: view # 全局只读角色，但仅default ns生效

场景：统一一套集群只读ClusterRole，通过RoleBinding分配给不同命名空间用户，复用规则、简化维护。

4. verbs 标准操作权限详解

4.1. 基础资源动作

  1. get：查询单个资源
  2. list：列出资源集合
  3. watch：实时监听资源变化（监控、控制器必备）
  4. create：新建资源
  5. update：完整更新资源
  6. patch：局部补丁更新
  7. delete：删除单个资源
  8. deletecollection：批量删除集合（kubectl delete pod —all）

4.2. 特殊虚拟资源 verbs（子资源）

  • pods/log：查看容器日志
  • pods/exec：kubectl exec 进入容器
  • pods/portforward：端口转发
  • deployments/scale：HPA扩缩副本

若需要 exec 进入Pod，规则必须单独加 pods/exec 资源。

5. 资源匹配进阶：apiGroups / resources / 通配符

  1. 核心原生资源（pod/svc/ns/node）apiGroups 为空字符串 ""
  2. 控制器资源 deploy/rs/statefulset：apps
  3. 网络资源 ingress/networkpolicy：networking.k8s.io
  4. 权限资源 role/clusterrole：rbac.authorization.k8s.io

通配符简化配置：

# 允许所有资源所有读操作
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

6. RBAC 完整工作流程（Pod 内部调用 apiserver 举例）

  1. Deployment 指定 serviceAccountName: app-sa；
  2. Pod 启动自动挂载 SA 的 token 到容器内；
  3. 程序请求 apiserver 携带 Bearer Token；
  4. apiserver 验证token合法性，识别主体为 default:app-sa；
  5. 查询所有 RoleBinding/ClusterRoleBinding，找到绑定的 Role/ClusterRole；
  6. 匹配规则：apiGroups+resources+verbs 是否允许当前操作；
  7. 匹配放行则执行，无匹配返回 forbidden 权限拒绝。

7. 权限排查核心命令（生产高频）

7.1. 校验权限（最实用）

# 模拟当前用户能否获取pod
kubectl auth can-i get pods

# 模拟指定SA权限（关键排错）
kubectl auth can-i create deployments \
--as=system:serviceaccount:default:app-sa

# 模拟外部用户
kubectl auth can-i delete pods --as=ops-user

7.2. 查看绑定关系

# 查看命名空间绑定
kubectl get rolebindings -n default
kubectl describe rolebinding xxx

# 全局集群绑定
kubectl get clusterrolebindings

7.3. 查看角色规则

kubectl describe role pod-read-role -n default
kubectl describe clusterRole view

7.4. 查看SA与自动挂载Secret

kubectl get sa -n default
kubectl describe sa app-sa -n default

8. 生产典型场景示例

8.1. 场景1：监控Prometheus读取全集群资源

  1. 创建 monitoring 命名空间 SA prometheus-sa；
  2. 编写 ClusterRole 赋予全集群 pod/node/deployment list/watch/get；
  3. ClusterRoleBinding 全局绑定 SA，所有ns均可采集指标。

8.2. 场景2：开发人员仅能操作自己业务命名空间

  1. 复用内置 ClusterRole edit；
  2. 在业务ns创建 RoleBinding，绑定开发User；
  3. 开发只能操作该ns资源，无法访问其他ns、集群节点。

8.3. 场景3：Pod内控制器需要管理同命名空间Deployment

  1. 新建SA绑定到Pod；
  2. 当前ns创建Role，赋予deployments增删改查；
  3. RoleBinding 绑定SA与Role。

9. RBAC 最佳实践与避坑

  1. 最小权限原则
    禁止直接绑定 cluster-admin；区分 view/edit/admin，按需只开放必要verbs与资源。
  2. 区分集群级/命名空间级权限
    业务普通权限使用 Role+RoleBinding；集群节点、跨ns监控才用 ClusterRoleBinding。
  3. 复用 ClusterRole
    统一编写全局角色，通过 RoleBinding 下发到各命名空间，减少重复YAML。
  4. 禁止Pod使用 default SA
    default SA无任何权限，业务Pod自定义专属SA，精准赋权。
  5. 区分子资源权限
    exec/log/portforward 属于独立子资源，单独配置规则，不能靠 pods 通用规则放行。
  6. 权限分层管理
  • 集群管理员：cluster-admin
  • 平台运维：admin（单ns完整权限）
  • 开发人员：edit（不可改权限）
  • 只读审计/监控：view
  1. 权限变更审计
    所有 RBAC YAML 纳入Git管理，变更留痕，便于排查权限泄露。

10. 面试核心速记总结

  1. RBAC 四大核心资源：Role(ns角色)、ClusterRole(全局角色)、RoleBinding(ns绑定)、ClusterRoleBinding(全局绑定)；
  2. 主体三种：User(人)、ServiceAccount(Pod程序)、Group(用户组)；
  3. ServiceAccount 是Pod访问apiserver身份凭证，自动挂载token；
  4. ClusterRole 两种使用方式：ClusterRoleBinding全局生效 / RoleBinding限定单ns；
  5. 鉴权流程：token识别主体 → 查询绑定 → 匹配apiGroup/resources/verbs放行；
  6. 内置角色：cluster-admin(超管)、admin、edit、view；
  7. 排错核心命令：kubectl auth can-i —as 模拟账号校验权限；
  8. 核心规范：最小权限，业务禁用default SA，区分集群/命名空间权限。

关联文档

返回首页订阅更新