摘要:梳理 Kubernetes API 请求中的身份认证、权限授权和准入控制,区分普通用户与 ServiceAccount,并理解常见身份凭据和访问边界。
在 Kubernetes(K8s)中,身份认证与权限授权是集群安全体系的核心。
这一部分主要解决两个问题:
-
Authentication(身份认证):你是谁?
- 确认访问 Kubernetes API Server 的用户或程序身份。
-
Authorization(权限授权):你能做什么?
- 判断这个身份是否有权限执行相应操作。
例如:
假设开发人员 Alice 需要查看集群中的 Pod:
- Alice 使用客户端证书或其他凭据访问 API Server。
- API Server 验证 Alice 的身份。
- API Server 检查 Alice 是否具有读取 Pod 的权限。
- 如果有权限,则允许访问;否则返回
Forbidden。
1. Kubernetes 身份认证与授权整体架构
先理解一次完整的 API 请求是如何被处理的。
Kubernetes API Server 处理请求时,主要经过以下几个阶段:
| 阶段 | 作用 | 核心问题 |
|---|---|---|
| Authentication | 身份认证 | 你是谁? |
| Authorization | 权限授权 | 你能做什么? |
| Admission Control | 准入控制 | 这个操作是否符合集群策略? |
| Validation | 对象校验 | 请求对象是否合法? |
| Persistence | 持久化 | 将结果保存到 etcd |
flowchart TB
A["客户端 API 写请求"] --> B["Authentication<br/>身份认证"]
B --> C["Authorization<br/>权限授权"]
C --> D["Admission Control<br/>准入控制与对象校验"]
D --> E["通过检查后持久化到 etcd"]
注意:Authentication、Authorization 和 Admission Control 是三个不同的安全环节,不要混淆。此图为写请求的逻辑示意,具体处理阶段取决于请求类型。
2. 身份认证 Authentication
2.1 Kubernetes 中有哪些身份?
Kubernetes 并没有传统意义上内置的用户管理数据库。
它主要区分两类身份:
- 普通用户(User)
例如:
- admin
- developer
- alice
普通用户通常由外部身份系统管理,例如证书、OIDC 身份提供商等。
- ServiceAccount
ServiceAccount 是 Kubernetes 内置的面向应用程序的身份机制。
例如:
- Pod 中运行的应用程序。
- Deployment 控制器。
- 集群内部的自动化程序。
两者的区别:
| 对比 | User | ServiceAccount |
|---|---|---|
| 使用对象 | 人或外部客户端 | Pod、应用程序 |
| 管理方式 | 通常由外部系统管理 | Kubernetes API 管理 |
| 是否有 Kubernetes API 对象 | 没有内置 User 对象 | 有 |
| 身份凭据 | 证书、OIDC 等 | ServiceAccount Token 等 |
| 常见用途 | 管理员、开发人员 | Pod 访问 API |
2.2 常见身份认证方式
Kubernetes 支持多种身份认证机制:
| 认证方式 | 原理 |
|---|---|
| X.509 Client Certificate | 使用客户端证书认证 |
| Bearer Token | 使用 Token 认证 |
| OIDC | 使用外部身份提供商认证 |
| Webhook Token Authentication | 将 Token 交给外部服务验证 |
| Authentication Proxy | 通过可信代理传递用户身份 |
常用的认证方式包括:
- 客户端证书认证
- ServiceAccount Token 认证
2.3 X.509 客户端证书认证
这是 Kubernetes 集群中非常重要的一种认证方式。
它的核心思想是:
客户端持有证书和私钥,API Server 使用 CA 证书验证客户端证书是否合法。
整个过程涉及三个文件:
| 文件 | 作用 |
|---|---|
| ca.crt | CA 根证书,用于验证证书 |
| client.crt | 客户端证书,证明客户端身份 |
| client.key | 客户端私钥,用于证明客户端持有对应密钥 |
认证过程:
flowchart TB
A["客户端 Alice<br/>持有 client.crt 和 client.key"]
B["Kubernetes API Server"]
C["使用客户端 CA 验证客户端证书"]
D["证书合法,提取 CN 和 O 字段"]
E["认证成功<br/>User: alice<br/>Group: developers"]
A -->|"TLS 中出示证书并证明持有私钥"| B
B --> C --> D --> E
这里有两个重要字段:
CN(Common Name):通常映射为用户名。O(Organization):映射为用户所属的组。
例如:
Subject: CN=alice,O=developersAPI Server 会将其识别为:
username: alicegroups: - developers - system:authenticated注意:证书认证成功只代表 Alice 的身份得到确认,并不代表 Alice 自动拥有管理员权限。
证书认证的配置入口:
--client-ca-file=/etc/kubernetes/pki/ca.crt在 kubeadm 集群中,通常可以在 API Server 静态 Pod 配置中看到这个参数:
cat /etc/kubernetes/manifests/kube-apiserver.yaml2.4 Token 认证
Token 认证不需要客户端证书,而是通过 HTTP 请求头携带 Token。
例如:
GET /api/v1/namespaces/default/pods HTTP/1.1Host: kubernetes.default.svcAuthorization: Bearer <TOKEN>API Server 验证 Token 后,确定请求对应的身份。
Kubernetes 中最常见的是 ServiceAccount Token。
3. 权限授权 Authorization
身份认证解决了你是谁,接下来 API Server 还需要判断你是否有权执行操作。
例如:
Alice 已经通过证书认证,但她可能只有查看 Pod 的权限,没有删除 Pod 的权限。
这就需要 Authorization。
3.1 Kubernetes 支持哪些授权机制?
常见的授权机制包括:
| 授权机制 | 作用 |
|---|---|
| RBAC | 基于角色的访问控制 |
| ABAC | 基于属性的访问控制 |
| Node | 限制 kubelet 对 API 资源的访问 |
| Webhook | 委托外部服务判断权限 |
| AlwaysAllow | 允许所有请求 |
| AlwaysDeny | 拒绝所有请求 |
其中最重要的是 RBAC(Role-Based Access Control)。
4. Authentication 与 Authorization 的区别
| 比较维度 | Authentication | Authorization |
|---|---|---|
| 中文 | 身份认证 | 权限授权 |
| 核心问题 | 你是谁? | 你能做什么? |
| 处理对象 | 证书、Token、身份信息 | 用户、用户组、权限规则 |
| 主要机制 | X.509、JWT、OIDC | RBAC、ABAC、Webhook |
| 失败结果 | 401 Unauthorized | 403 Forbidden |
| 典型配置 | --client-ca-file | --authorization-mode |
记住:
- 401:身份认证失败。
- 403:身份已经识别,但没有足够权限。
参考 Kubernetes 官方文档: