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

grahamzhu

于 2025-02-23 21:15:31 发布

阅读量1.1k

点赞数 32

分类专栏：云原生学习专栏文章标签： kubernetes RBAC 鉴权机制 authorization 授权 apiserver 云计算

本文链接：https://blog.youkuaiyun.com/a1369760658/article/details/145814466

版权

云原生学习专栏专栏收录该内容

103 篇文章

订阅专栏

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

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 请求时：

身份认证：API Server 确认请求者身份（如 TLS 证书、Bearer Token）。
获取主体信息：提取用户/组/ServiceAccount 信息（如 system:serviceaccount:default:my-sa）。
查询绑定关系：
- 查找所有 RoleBinding 和 ClusterRoleBinding，匹配主体（用户/组/ServiceAccount）。
- 收集绑定的 Role 和 ClusterRole。
权限校验：
- 遍历所有关联的 Role/ClusterRole 的规则。
- 检查请求的 API Group、Resource、Verb、ResourceName 是否匹配任意规则。
决策：
- 有一条规则允许 → 放行。
- 无任何规则允许 → 拒绝（返回 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	集成外部系统	依赖外部服务可用性	企业统一权限管理