【k8s】rbac权限框架和鉴权、鉴权概念

文章目录

• [1、鉴权 (Authentication) 和 授权区别](#1、鉴权 (Authentication) 和 授权区别)
• • [1.1 鉴权 (Authentication) ------ "你是谁？"](#1.1 鉴权 (Authentication) —— “你是谁？”)
  • [1.2. 授权 (Authorization) ------ "你能做什么？"](#1.2. 授权 (Authorization) —— “你能做什么？”)
  • [1.3 . 准入控制 (Admission Control) ------ 针对"写"操作的额外校验](#1.3 . 准入控制 (Admission Control) —— 针对“写”操作的额外校验)
• [2.RBAC 属于授权 (Authorization) 范畴](#2.RBAC 属于授权 (Authorization) 范畴)
• [3. 总结](#3. 总结)

1、鉴权 (Authentication) 和 授权区别

鉴权和权限是两个概念吧，鉴权是登录相关的，例如kubectl get po ，首先api-server需要鉴权，判断~/.kube/config 是否正确，基于鉴权，得到用户或用户组，然后才是判断这个用户或用户组是否有权限查看po资源？

你的理解完全正确。

你举的 kubectl get po 这个例子非常精准，清晰地划分了两个不同阶段：鉴权 (Authentication) 和 授权 (Authorization)。

在 Kubernetes（以及绝大多数分布式系统）的 API 访问控制流程中，确实是先鉴权，后授权。我们可以把整个过程拆解为三个步骤：

1.1 鉴权 (Authentication) ------ "你是谁？"

这是第一步。kubectl 发起请求到 api-server，api-server 需要验证客户端的身份。

• 核心任务：验证身份。

• 你的例子：api-server 读取 ~/.kube/config 中的客户端证书（最常见的方式）、Token 或用户名/密码。它需要确认两件事：这个文件是否存在，以及证书签名是否由集群的 Certificate Authority (CA) 签发且未过期。

• 判断结果：如果鉴权失败，你会收到 401 Unauthorized（未授权）错误。此时请求会被直接拒绝，根本不会进入下一步。

1.2. 授权 (Authorization) ------ "你能做什么？"

鉴权通过后，系统知道了"你是谁"（例如，你的证书里 CN=admin，或者你是一个 system:serviceaccount:default:mysa）。接下来，api-server 会检查这个身份是否被允许执行当前的操作。

• 核心任务：检查权限。

• 你的例子：api-server 会根据你的身份，匹配 RBAC（基于角色的访问控制）规则。系统会检查：

  • 你有没有权限访问 pods 这个资源？

  • 你有没有权限在 default 命名空间下执行 get 操作？

• 判断结果：如果身份合法，但没有相应权限，你会收到 403 Forbidden（禁止访问）错误。

1.3 . 准入控制 (Admission Control) ------ 针对"写"操作的额外校验

在你关注的"读"操作（get po）中不涉及这一步，但对于 create、update、delete 等"写"操作，在鉴权和授权之后，还有一个准入控制阶段。它会拦截请求，进行修改或验证，例如检查是否设置了资源配额、是否有必要的标签等。

2.RBAC 属于授权 (Authorization) 范畴

在 Kubernetes 中，RBAC 是授权机制的一种具体实现，它负责解决"你能做什么"的问题，而不是"你是谁"的问题。

让我帮你理清它们之间的关系：

1）. 三层架构中的位置

请求流程：
kubectl get po
    ↓
[1. 鉴权 Authentication]  ← 你是谁？（证书/Token）
    ↓
[2. 授权 Authorization]  ← ✅ RBAC 在这里 ✅
    ↓
[3. 准入控制 Admission Control]

2）RBAC 在授权层做了什么

当你通过了鉴权（api-server 确认了你的身份）后，RBAC 负责回答：

• 你的身份是什么？（通过 RoleBinding 或 ClusterRoleBinding 将用户/ServiceAccount 绑定到角色）

• 这个角色允许对哪些资源执行哪些操作？（通过 Role 或 ClusterRole 定义规则）

具体到你的例子：

# 这是一个授权规则（RBAC），不是鉴权规则
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]   # 允许 get 和 list pods

当你的身份（比如 user@example.com）通过鉴权后，RBAC 会检查这个用户是否通过 RoleBinding 关联到了上面这个 Role。如果是，授权通过；如果不是，返回 403 Forbidden。

3）鉴权层也有自己的配置

鉴权层解决的是"身份验证"，它的配置是独立的，常见方式包括：

鉴权方式	配置位置	说明
客户端证书	~/.kube/config 中的 client-certificate-data	api-server 用 CA 验证证书签名
Bearer Token	~/.kube/config 中的 token	ServiceAccount 或静态 Token 文件
OIDC / OAuth	api-server 启动参数 --oidc-*	对接外部身份提供商（如 Google、Okta）
X.509 证书	api-server 的 --client-ca-file	自定义 CA 签发的证书

4）容易混淆的地方

RBAC 本身不关心你的证书是怎么签发的，也不关心 Token 是否有效，它只关心：经过鉴权后，系统识别出的"用户名"和"组"是什么。

alice@example.com来自鉴权后得到的用户名称，然后授权会检查RoleBinding：

# RoleBinding 示例：将角色授权给某个"用户"
kind: RoleBinding
subjects:
- kind: User
  name: alice@example.com   # 这个 name 来自鉴权层提供的身份
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader

• 如果 alice@example.com 用正确的证书请求 → 鉴权通过 → 身份被识别为 alice@example.com → RBAC 检查 → 有权限 → 成功

• 如果 alice@example.com 用错误的证书请求 → 鉴权失败 → 直接 401，RBAC 根本不会执行

• 如果 bob@example.com 用正确的证书请求 → 鉴权通过 → 身份被识别为 bob@example.com → RBAC 检查 → 没有绑定任何角色 → 403

3. 总结

概念	所属层级	核心问题	Kubernetes 实现
鉴权 (Authentication)	第 1 层	你是谁？	客户端证书、Bearer Token、OIDC、静态 Token 文件等
授权 (Authorization)	第 2 层	你能做什么？	RBAC、ABAC、Webhook、Node（节点授权器）