3. 认证(Authentication)基础：ServiceAccount、UserAccount、X509证书、Bearer Token原理
在Kubernetes鉴权拦截链路中，认证（Authentication）是第一道关卡。只有通过认证的请求，才会进入后续的鉴权（Authorization）与准入控制（Admission Control）阶段。本章深入剖析四种核心认证机制：ServiceAccount、UserAccount、X509证书、Bearer Token，并揭示它们在错误处理链路中的关键作用。
3.1 认证体系全景：谁在请求API Server？
Kubernetes API Server 接收的所有请求，都必须携带身份凭证。认证模块负责从请求中提取并验证身份，最终将请求关联到一个确定的 UserInfo 对象（包含 Username、UID、Groups 和 Extra 字段）。
3.2 ServiceAccount：Pod 的身份凭证
ServiceAccount（服务账户）是 Kubernetes 为 Pod 内进程提供的身份标识。每个 Namespace 都有一个默认的 ServiceAccount（名为 default），Pod 未显式指定 ServiceAccount 时自动使用。
3.2.1 核心原理
- 自动挂载：Kubernetes 将 ServiceAccount 的 Token 自动挂载到 Pod 的
/var/run/secrets/kubernetes.io/serviceaccount/目录。 - Token 类型：传统 Token（静态 Secret）和 Projected Token（TokenRequest API），后者具有更短的过期时间和更安全的绑定机制。
- 身份映射：ServiceAccount 名称映射为
system:serviceaccount:<namespace>:<name>格式的 Username。
401 Unauthorized。这是生产环境中常见的“静默故障”来源。
3.2.2 ServiceAccount 与 UserAccount 对比
| 对比维度 | ServiceAccount | UserAccount |
|---|---|---|
| 管理方式 | Kubernetes API 原生管理（kubectl create sa） | 外部管理（证书、OIDC、Webhook） |
| 使用场景 | Pod 内进程、CronJob、Controller | 管理员、CI/CD 系统、开发人员 |
| 命名空间 | 属于特定 Namespace | 全局（集群级别） |
| 用户名格式 | system:serviceaccount:<ns>:<name> |
自定义（如 admin@example.com） |
| 自动挂载 | 自动挂载 Token 到 Pod | 不适用 |
| 典型错误 | Token 过期、SA 被删除、RBAC 未绑定 | 证书过期、Token 无效、OIDC 配置错误 |
3.3 X509 证书认证：双向 TLS 的基石
X509 客户端证书是 Kubernetes 最基础的认证方式之一。kubeconfig 文件中的 client-certificate 和 client-key 字段即用于此认证。
3.3.1 认证流程
- TLS 握手：客户端发起 HTTPS 请求，API Server 要求客户端提供证书。
- 证书验证：API Server 验证客户端证书的签名链（CA 信任）、有效期、是否被吊销。
- 身份提取：从证书的 CN（Common Name） 字段提取 Username，从 O（Organization） 字段提取 Groups。
- UserInfo 构建：将提取的信息封装为 UserInfo 对象，传递给后续鉴权模块。
openssl x509 -in client.crt -text -noout 定期检查证书有效期。
3.3.2 证书字段与身份映射
| 证书字段 | 映射到 UserInfo | 示例值 |
|---|---|---|
| CN (Common Name) | Username | admin、system:kube-controller-manager |
| O (Organization) | Groups（可多个） | system:masters、devops-team |
| OU (Organizational Unit) | 不直接映射（可自定义） | engineering |
3.4 Bearer Token 认证：从静态到动态
Bearer Token 是 HTTP 请求头 Authorization: Bearer <token> 中携带的凭证。Kubernetes 支持多种 Token 类型。
3.4.1 Token 类型对比
| Token 类型 | 来源 | 生命周期 | 安全性 | 典型错误 |
|---|---|---|---|---|
| 静态 Token | 静态文件（--token-auth-file） | 永久（需重启 API Server 更新） | 低（泄露风险高） | Token 被泄露、文件格式错误 |
| ServiceAccount Token | Secret 或 TokenRequest API | 永久（Secret）或 1h（Projected） | 中（需配合 RBAC） | Token 过期、Secret 被删除 |
| OIDC Token | 外部身份提供商（如 Keycloak） | 短时间（通常 1h） | 高（支持刷新） | OIDC 配置错误、Token 签名验证失败 |
| Bootstrap Token | 集群初始化时生成 | 临时（用于节点加入） | 中 | Token 过期、Secret 未创建 |
3.4.2 TokenRequest API：现代 ServiceAccount 认证
从 Kubernetes 1.21 开始，TokenRequest API 成为 ServiceAccount 获取 Token 的推荐方式。它生成的 Token 是 Projected Token，具有以下特性：
- 绑定 Pod 身份：Token 中嵌入 Pod 的 UID，即使 Token 泄露也无法在其他 Pod 中使用。
- 自动过期：默认 1 小时过期，减少泄露风险。
- 自动刷新：kubelet 在 Token 过期前自动刷新挂载的 Token。
kubectl create token <sa-name> 或 TokenRequest API 获取临时 Token，避免使用永久 Secret Token。
3.5 认证链与错误处理策略
API Server 的认证模块以 链式（Chain） 方式工作。每个认证器依次尝试，任一成功即停止；全部失败则返回 401 Unauthorized。
3.5.1 默认认证链顺序
- X509 证书认证器（验证客户端证书）
- Bearer Token 认证器（验证 Token）
- ServiceAccount 认证器（验证 ServiceAccount Token）
- Webhook Token 认证器（外部认证服务）
- Anonymous 认证器（允许匿名请求，默认禁用）
3.5.2 认证错误分类与排查
| 错误类型 | HTTP 状态码 | 常见原因 | 排查方法 |
|---|---|---|---|
| 证书错误 | 401 | 证书过期、CA 不信任、CN 为空 | openssl verify -CAfile ca.crt client.crt |
| Token 错误 | 401 | Token 过期、格式错误、签名无效 | 检查 Token 是否包含 . 分隔的三段 |
| ServiceAccount 错误 | 401 | SA 被删除、Token Secret 不存在 | kubectl get sa -n <ns> 检查 SA 状态 |
| OIDC 错误 | 401 | Issuer 不可达、ClientID 不匹配 | 检查 API Server 日志中的 OIDC 错误 |
| 匿名请求被拒 | 401 | --anonymous-auth=false | 检查 API Server 启动参数 |
3.6 本章小结
- ServiceAccount 是 Pod 的身份凭证，推荐使用 TokenRequest API 获取临时 Token。
- UserAccount 由外部管理，X509 证书和 Bearer Token 是两种主要认证方式。
- X509 证书 通过 CN/O 字段映射 Username 和 Groups，证书过期是常见故障。
- Bearer Token 支持静态、ServiceAccount、OIDC 等多种类型，Projected Token 提供更高的安全性。
- 认证链按顺序尝试，全部失败返回 401；详细的错误日志是高效排障的关键。