Kubernetes控制平面组件：API Server RBAC授权机制 详解

云原生学习路线导航页（持续更新中）

• kubernetes学习系列快捷链接
  • Kubernetes架构原则和对象设计（一）
  • Kubernetes架构原则和对象设计（二）
  • Kubernetes架构原则和对象设计（三）
  • Kubernetes控制平面组件：etcd（一）
  • Kubernetes控制平面组件：etcd（二）
  • Kubernetes控制平面组件：etcd常用配置参数
  • Kubernetes控制平面组件：etcd高可用集群搭建
  • Kubernetes控制平面组件：etcd高可用解决方案
  • Kubernetes控制平面组件：Kubernetes如何使用etcd
  • Kubernetes控制平面组件：API Server详解（一）
  • Kubernetes控制平面组件：APIServer 基于 X509 证书的认证机制
  • Kubernetes控制平面组件：APIServer 基于 静态Token 的认证机制
  • Kubernetes控制平面组件：APIServer 基于 引导Token 的认证机制
  • Kubernetes控制平面组件：APIServer 基于 ServiceAccount 的认证机制
  • Kubernetes控制平面组件：APIServer 基于 OpenID 的认证机制详解
  • Kubernetes控制平面组件：APIServer 基于 Webhook Toeken令牌 的认证机制详解
  • Kubernetes控制平面组件：APIServer 基于匿名请求的认证机制详解
  • kubectl 和 kubeconfig 基本原理
  • kubeadm 升级 k8s集群 1.17到1.20
  • Kubernetes常见问题解答
  • 查看云机器的一些常用配置

本文主要对kubernetes的控制面组件API Server 授权机制中的RBAC机制进行详细介绍，包括RBAC的设计理念、在kubernetes中的优化改造、完整运作流程、使用案例、最佳实践、生产中常遇到的陷阱等

• 希望大家多多 点赞 关注 评论 收藏，作者会更有动力编写技术文章

1.RBAC 基础概念（脱离 Kubernetes 的设计视角）

1.1.RBAC 的核心思想

• RBAC（Role-Based Access Control）是一种以 角色 为中心的权限控制模型，核心逻辑是：
  • 权限不直接赋予用户，而是通过 角色 作为中间层。
  • 用户与角色关联，角色与权限关联，形成两级映射关系。
• 核心组件：
  • 用户（User）：操作主体（人或程序）。
  • 角色（Role）：权限的集合，角色是权限的承载（如“管理员”、“开发者”）。
  • 权限（Permission）：对资源的操作许可，包括 objs 和 具体操作（如“读取日志”、“创建 Pod”）。
  • 会话（Session）：用户激活角色的上下文（如登录会话）。

1.2.经典 RBAC 模型（ANSI INCITS 359-2004）

• 角色层次（Role Hierarchy）：角色可继承其他角色的权限。
• 静态职责分离（SSD）：互斥角色不能分配给同一用户。
• 动态职责分离（DSD）：同一会话中不能激活互斥角色。

1.3.RBAC 的优势

• 最小权限原则：用户仅拥有完成任务所需的最小权限。
• 灵活管理：权限变更只需调整角色，无需逐个修改用户。
• 审计友好：通过角色追踪权限分配。

---

2.Kubernetes 对 RBAC 的优化改造

2.1.核心改进点

• 资源化设计：将角色、绑定等抽象为 Kubernetes 资源（API 对象），支持 kubectl 管理。
• 细粒度控制：支持到 API 资源级别 的权限控制（如 pods、secrets）。
• 命名空间隔离：角色（Role）分为 命名空间级（Role）和 集群级（ClusterRole）。
• 聚合角色：通过 aggregationRule 组合多个角色的权限。
• 内置角色：提供预定义角色（如 view、edit、admin），简化权限分配。

2.2.Kubernetes RBAC 核心组件

组件	作用域	描述
Role	命名空间	定义单个命名空间内的资源权限（如 default 命名空间的 Pod 读取权限）。
ClusterRole	集群级	定义集群范围或非命名空间资源的权限（如 Nodes、PersistentVolumes）。
RoleBinding	命名空间	将 Role 绑定到用户/组/ServiceAccount（仅限当前命名空间）。
ClusterRoleBinding	集群级	将 ClusterRole 绑定到用户/组/ServiceAccount（全局生效）。

2.3.权限规则（Rule）结构

每个 Role/ClusterRole 包含一组 规则（Rules），每条规则定义：

• API Groups：资源所属的 API 组（如 apps、batch）。
• Resources：资源类型（如 pods、deployments）。
• Verbs：允许的操作（如 get、list、create、delete）。
• ResourceNames：指定具体资源实例（可选，如只允许删除名为 test-pod 的 Pod）。

# Role 示例：允许读取 default 命名空间的 Pod
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

• 注意：
  • RBAC 的默认行为：Kubernetes RBAC 是 白名单模型：仅允许显式定义的权限，其他操作自动拒绝。
  • ns下的default sa，默认是无权限的
  • kubectl apply操作 Verb是patch，而kubectl replace Verb是update。
    • update是把变化后的整个对象，完整的发给apiserver，包比较大
    • patch是只把增量发给apiserver，包更小，效率更高，但你要保证你有patch的权限

2.5.怎么理解 Rolebinding 是ns级别的？

• Rolebinding 赋给用户的只有自己所在ns下的权限，即使引用了clusterRole，也没办法把其他ns下的权限赋予用户
• 比如下面rolebinding引用了clusterRole secret-reader，将权限赋给了user dave。但是由于rolebinding本身只存在于ns：development下，所以user dave也只会有 ns：development 下的secret读取权限
  
  

2.6.权限的三种绑定主体

• binding的时候，subjects有三个枚举：“User”, “Group”, and “ServiceAccount”
  • User：外部用户
  • ServiceAccount：内部用户
  • Group：一组用户，对内指某个ns下所有SA，对外指同属某group的多个用户
• 注意：如果role和rolebinding所在的ns不一致，是绑定不成功的，会报错的，因为rolebinding找不到对应的role
  
  
• 针对群组的授权中
  • 左图：表示将secret-reader权限 授给 manager group下的所有user
  • 右图：表示将secret-reader权限 授给 ns==qa 下的所有ServiceAccount

---

3.Kubernetes RBAC 运行流程

3.1.鉴权流程

当用户或 ServiceAccount 发起 API 请求时：

1. 身份认证：API Server 确认请求者身份（如 TLS 证书、Bearer Token）。
2. 获取主体信息：提取用户/组/ServiceAccount 信息（如 system:serviceaccount:default:my-sa）。
3. 查询绑定关系：
   • 查找所有 RoleBinding 和 ClusterRoleBinding，匹配主体（用户/组/ServiceAccount）。
   • 收集绑定的 Role 和 ClusterRole。
4. 权限校验：
   • 遍历所有关联的 Role/ClusterRole 的规则。
   • 检查请求的 API Group、Resource、Verb、ResourceName 是否匹配任意规则。
5. 决策：
   • 有一条规则允许 → 放行。
   • 无任何规则允许 → 拒绝（返回 403 Forbidden）。

3.2.权限匹配逻辑

• API Group 匹配：规则中的 apiGroups 必须包含请求资源的 API 组（空字符串表示核心 API 组）。
• Resource 匹配：规则中的 resources 必须包含请求的资源类型（支持通配符 *）。
• Verb 匹配：规则中的 verbs 必须包含请求的操作（如 create）。
• ResourceName 匹配：如果规则指定了 resourceNames，请求的资源名必须在该列表中。

---

4.Kubernetes RBAC 设计原理

4.1.最小权限原则的实现

• 精细化控制：允许为不同命名空间、不同资源类型设置独立权限。
• 避免特权扩散：ServiceAccount 默认无权限，需显式绑定角色。

4.2.命名空间隔离

• Role 与 RoleBinding 属于命名空间资源，天然支持多租户场景。
• ClusterRole 用于定义跨命名空间或集群级资源的权限（如节点、存储卷）。

4.3.高效鉴权

• 索引优化：API Server 缓存角色和绑定关系，加速权限查询。
• 预编译策略：将 RBAC 规则转换为快速匹配的数据结构。

4.4.扩展性

• 聚合 ClusterRole：通过标签选择器聚合多个 ClusterRole 的权限。

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: monitoring-admin
  aggregationRule:
    clusterRoleSelectors:
    - matchLabels:
        rbac.monitoring.io/aggregate-to-monitoring-admin: "true"
  

---

5.Kubernetes RBAC 使用案例

5.1.案例：为 ServiceAccount 授予 Pod 管理权限

场景：允许名为 cicd-sa 的 ServiceAccount 在 default 命名空间管理 Pod。

# 创建 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-manager
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "create", "delete"]

# 创建 RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: cicd-pod-access
subjects:
- kind: ServiceAccount
  name: cicd-sa
  namespace: default
roleRef:
  kind: Role
  name: pod-manager
  apiGroup: rbac.authorization.k8s.io

5.2.案例：授予跨命名空间的只读权限

场景：允许用户 dev-user 只读所有命名空间的 Deployments。

# 创建 ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: global-deployment-viewer
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch"]

# 创建 ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dev-user-global-view
subjects:
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: global-deployment-viewer
  apiGroup: rbac.authorization.k8s.io

5.3.案例：限制删除特定 ConfigMap

场景：禁止 test-sa 删除名为 critical-config 的 ConfigMap。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-guardian
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["*"]
  resourceNames: ["critical-config"]
  # 显式排除 delete 操作
  verbs: ["get", "list", "create", "update", "patch"]

---

6.高级技巧与最佳实践

6.1.权限审计

• 检查用户权限：

  kubectl auth can-i delete pods --as=system:serviceaccount:default:cicd-sa
  

• 生成权限报告：

  kubectl auth reconcile -f role.yaml --dry-run=server
  

6.2.最小权限分配

• 避免使用 verbs: ["*"]：明确列出所需操作。
• 利用内置角色：如 view、edit，减少自定义角色。

6.3.安全加固

• 定期清理无用 Binding：防止权限残留。
• 限制 ClusterRoleBinding：仅在必要时使用集群级绑定。

6.4.结合其他机制

• Pod Security Policies（已弃用，替换为 PSA）：控制 Pod 的安全上下文。
• Network Policies：网络层权限控制。

6.5.如何规划系统角色？

6.6.如何设计一个多租户系统？

我们已经学习了 Kubernetes apiserver 的认证和鉴权，我们应该已经具备设计一个多租户系统的基本思路

• 实现资源隔离：
  • 可以用ns为隔离机制，为每个部门分配一个ns，并且具备自己ns下的所有资源的读写权限。这样部门之间就实现了资源隔离。
• 全自动化的实现思路如下：
  
• 首先，可以为某个部门创建一个专用的role，拥有该ns下所有权限
• 创建一个 namespace 的 mutating webhook，监听namespace对象的create事件
  • 当发生namespace的创建时，mutating webhook拦截到请求，对namespace对象做变形
  • 将发起ns create的用户信息，写入 ns 的annotation中，再进行放行
• 创建一个 用于监听ns的Controller，watch namespace 的create事件
  • 如果发现ns annotation中有user信息，就为其创建一个rolebinding，将user绑定到role
• 这样，一个在创建ns时，自动化为该user授权的多租户管理系统就基本成型了

6.7.其他场景的最佳实践

---

7.运营过程中遇到的陷阱

• 案例1：
  • 我们在代码里更新一个资源，一般有两种方式：update、patch，对于role来说是两种verb，如果你的role没有patch操作权限，可能就会出现权限不足的错误
  • 所以在代码改动时，需要注意是否有权限的变化，有的话需要同步更新

8.与其他鉴权模式的对比

机制	优点	缺点	适用场景
RBAC	细粒度、易管理、Kubernetes 原生	配置稍复杂	绝大多数 Kubernetes 场景
ABAC	基于属性动态决策	难以维护、需重启 API Server	简单策略或遗留系统
Node	专为 Kubelet 设计	仅适用于节点组件	Kubelet 授权
Webhook	集成外部系统	依赖外部服务可用性	企业统一权限管理

---

9.总结

Kubernetes RBAC 通过 资源化设计 和 命名空间隔离，将经典 RBAC 模型优化为适应云原生环境的动态权限管理系统。其核心价值在于：

• 精细化控制：精确到 API 资源级别的权限管理。
• 多租户支持：通过命名空间实现逻辑隔离。
• 可扩展性：聚合角色、动态绑定等机制满足复杂场景需求。

深入理解 RBAC 后，应结合 最小权限原则 和 定期审计，构建安全可靠的 Kubernetes 权限体系。