## 一、先划边界：认证只回答"你是谁"

API Server 对每个请求做三件互不越界的事：

![auth-1-pipeline.png](https://developer.qcloudimg.com/http-save/yehe-11479707/adc2b8513cf8c3a21f795b7a7b56450e.png)

*图 1：认证不通过，后面的授权和准入根本不会发生。*

```
认证 Authentication  →  授权 Authorization  →  准入 Admission
"你是谁"                "你能做什么"            "这次改动合不合规"
```

认证的产物只有一个：`user.Info`。

```go
// staging/src/k8s.io/apiserver/pkg/authentication/user/user.go (v1.34.0)
type Info interface {
    GetName() string
    GetUID() string
    GetGroups() []string
    GetExtra() map[string][]string
}
```

就这四个字段。后面所有 RBAC 判断、审计日志、准入策略，都只认这四样东西。**认证器不碰对象、不查 etcd、不判断权限**——这条边界如果破了，整个权限模型就没法推理了。

一个具体的例子：认证器不会因为"这个用户没有 list pods 的权限"而拒绝请求，它只会在授权阶段被拒。所以 401 和 403 是两种完全不同的故障，第八节会展开。

## 二、为什么认证必须发生在 API Server 里

最常见的误解是："前面挂个网关做认证，API Server 放开不就行了？"

不行。因为在网关那一层，你拿不到 Kubernetes 需要的身份语义：

- 网关知道"这个 token 属于 alice"，但它不知道 alice 属于哪个 group，而 RBAC 通常授权给 group 而不是人；
- 网关不知道 `system:masters`、`system:nodes`、`system:serviceaccounts` 这些内置组的含义；
- 审计要求"谁在什么时候做了什么"，身份必须由 API Server 自己认定，不能信前端传的 header；
- 除了 kubectl，还有 kubelet、controller-manager、scheduler、webhook、Operator 在访问，它们不走你的网关。

所以网关可以做**前置过滤**（限流、WAF、TLS 卸载），但**身份认定必须发生在 API Server**。

这一点在代码里体现得很直接：认证发生在请求解码之前。API Server 还不知道你要操作什么对象，就已经把你认成了 `alice`。

## 三、Kubernetes 里没有"用户"这个对象

`kubectl get users` 会报错。集群里没有 User 资源，也没有 User CRD。用户是**认证器的输出**，不是集群的存储。

**为什么不把它做成对象？** 三个原因，每个都是硬约束：

1. **引导问题（bootstrap problem）**：如果 User 是 API 对象，那么"创建第一个 admin 用户"这个操作本身就需要一个 admin 用户。先有鸡还是先有蛋。
2. **身份是外部事实**：alice 是否存在，应该由 LDAP / OIDC / 证书体系回答，而不是由 etcd 回答。集群存一份用户表，从第一天起就会过期。
3. **多身份源**：同一个集群可能同时接企业 SSO、云 IAM、kubelet 证书、ServiceAccount。做成对象就得先合并这些模型，成本极高。

**代价也很实在**：没有"用户列表"API；RBAC 里只能写字符串；员工离职后，集群不会自动回收他的绑定，只能靠 IdP 停用 + 定期清理。

这也解释了 `ServiceAccount` 为什么是对象：它不是"人"，是**工作负载的身份**，生命周期跟 Namespace 绑定，可以创建、可以删、可以带 Secret。人和机器，在模型上被刻意分开了。

## 四、认证器是一条链，不是"配置一个"

API Server 启动时会组装一个 **union authenticator**：按顺序尝试每个认证器，谁先成功就用谁。

![auth-2-chain.png](https://developer.qcloudimg.com/http-save/yehe-11479707/8f62d21adc83de570fad58fd5e13c81f.png)

*图 2：请求带着凭证进来，第一个认出它的认证器胜出，输出 user.Info。*

```go
// staging/src/k8s.io/apiserver/pkg/authentication/request/union/union.go (v1.34.0)
func New(authRequestHandlers ...authenticator.Request) authenticator.Request {
    if len(authRequestHandlers) == 1 {
        return authRequestHandlers[0]
    }
    return &unionAuthRequestHandler{Handlers: authRequestHandlers, FailOnError: false}
}

for _, currAuthRequestHandler := range authHandler.Handlers {
    resp, ok, err := currAuthRequestHandler.AuthenticateRequest(req)
    if err != nil {
        if authHandler.FailOnError {
            return resp, ok, err
        }
        errlist = append(errlist, err)
        continue
    }
    if ok {
        return resp, ok, err
    }
}
```

注意 `FailOnError: false` 这个默认值：**一个认证器报错，不会中断整条链**，而是记下错误、继续试下一个。只有全部失败，才返回聚合错误。

顺序在 `config.go` 里写死：

```go
// pkg/kubeapiserver/authenticator/config.go (v1.34.0，节选)
// front-proxy, BasicAuth methods, local first, then remote
if config.RequestHeaderConfig != nil { ... }

// X509 methods
if config.ClientCAContentProvider != nil { ... }

// Bearer token methods, local first, then remote
if len(config.TokenAuthFile) > 0 { ... }
// ServiceAccount / Bootstrap / OIDC / Webhook ...

authenticator := union.New(authenticators...)
authenticator = group.NewAuthenticatedGroupAdder(authenticator)
```

最后那行 `NewAuthenticatedGroupAdder` 做了一件很容易被忽略的事：**任何认证成功的用户，都会被自动加入 `system:authenticated` 组**（匿名用户除外）。所以你在 RBAC 里写 `subjects: [{kind: Group, name: system:authenticated}]`，就等于"所有登录用户"。

**为什么要做成链，而不是"选一种"？**

- 异构身份源必然并存：人用 OIDC，kubelet 用证书，Pod 用 SA token，云厂商用 webhook。你不可能让所有人统一成一种。
- 迁移需要并行期：从静态 token 迁到 OIDC，两种认证器要同时开着。
- 每种认证器只做一件事：把凭证翻译成 `user.Info`，不负责别的。

代价是：**顺序即语义**。如果把 Anonymous 放在前面，所有请求都会变成 `system:anonymous`；如果 RequestHeader 配错，任何人都能伪造 `X-Remote-User`。

## 五、六种认证方式，各自解决什么问题

| 方式 | 谁在用 | 解决什么 | 代价 | 版本 |
| --- | --- | --- | --- | --- |
| **x509 客户端证书** | kubelet、controller-manager、管理员 | 最基础设施、不依赖外部系统 | 没有撤销机制 | 1.0 |
| **静态 Token 文件** | 早期集群 | 最简单 | 改 token 要重启、明文存盘 | 1.0（已不推荐） |
| **Bootstrap Token** | kubeadm 节点加入 | 让新节点能安全地"自举" | 仅用于引导，令牌短期 | 1.6 |
| **ServiceAccount Token** | Pod 内工作负载 | 工作负载身份 | 长期 token 泄露即永久 | 1.0，1.22/1.24 大改 |
| **OIDC** | 企业 SSO | 复用 IdP，无状态校验 | 依赖 IdP、audience 配错很常见 | 1.3 |
| **Webhook Token** | 云 IAM、自建 token 体系 | 把认证外包出去 | 多一次网络调用（有缓存） | 1.9 |

### x509：最"可信"，也最没有退路

证书里 `CN` 是用户名，`O` 是 group：

```
CN=alice, O=system:masters
```

它的设计取舍很典型：**没有撤销**。CRL / OCSP 在大规模集群里不可靠，Kubernetes 干脆不做，改走另一条路——**短生命周期证书 + 自动轮换**。kubelet 的证书轮换 1.8 进入 alpha，1.19 GA；配合 `CertificateSigningRequest` API，节点证书可以自动续期。

代价是：管理员手工签发的证书（比如 `kubeadm` 生成的 `admin.conf`）默认有效期一年，到期就是集群级故障。这是很多"一年后突然连不上"事故的根因。

### ServiceAccount Token：1.22 / 1.24 那次大改

![auth-3-sa-token.png](https://developer.qcloudimg.com/http-save/yehe-11479707/5c514766aa42b1d969045de95d9f176b.png)

*图 3：同一件事——让 Pod 证明自己是谁——两种实现的攻击面完全不同。*

老模型：每个 ServiceAccount 自动创建一个 Secret，里面是**永不过期**的 JWT，挂进 Pod。问题是——**它是一张永久通行证**。任何能读 Secret 的人、任何一次日志泄露，都等于永久拿到这个身份。

新模型（`BoundServiceAccountTokenVolume`，1.13 alpha → 1.21 beta → **1.22 GA**）：

- 用 projected volume 注入，token 有**过期时间**（默认 1 小时，自动轮换）；
- 带 **audience**，只能用于指定的 API Server；
- **绑定 Pod**：Pod 删除，token 失效。

1.24 起，默认不再为每个 ServiceAccount 自动创建长期 token Secret（`LegacyServiceAccountTokenNoAutoGeneration`）。这就是为什么升级后很多"读 Secret 拿 token"的脚本突然失效——不是 bug，是设计上要消灭永久凭证。

### OIDC：企业 SSO 的桥

```bash
--oidc-issuer-url=https://idp.example.com
--oidc-client-id=kubernetes
--oidc-username-claim=email
--oidc-groups-claim=groups
```

**为什么是 OIDC，不是 LDAP / SAML？**

- JWT 自带签名，API Server 用 JWKS **本地验签**，不需要每次请求都问 IdP；
- 无状态：IdP 挂了，已签发的 token 在有效期内还能用；
- 几乎所有企业 IdP（Okta、Azure AD、Keycloak）都支持。

代价：audience 配错、issuer 地址不一致、时钟偏移，都会表现为"token 明明有效但 401"，而且错误信息不会告诉你具体原因。

### Webhook：把认证彻底外包

云厂商的 IAM token 不可能让 Kubernetes 认识，于是有了 `TokenReview`：

```
API Server --TokenReview--> 你的认证服务 --> {authenticated, user}
```

默认缓存 2 分钟（`--authentication-token-webhook-cache-ttl`）。这里有个设计细节：**超时和失败是 fail-closed 的**——认证服务挂了，所有用这种 token 的请求都会被拒。这是安全上的正确选择，但会放大故障面。

### RequestHeader 与匿名

`RequestHeader` 认证不校验签名，它直接读 `X-Remote-User`、`X-Remote-Group` 这些 header，只信任来自 front-proxy 的流量（`--requestheader-client-ca-file` 校验客户端证书）。它存在是为了**聚合 API Server**（kube-aggregator）——扩展 API Server 需要把原始用户身份透传过去。

**这是整条链上最危险的一环**：配错了，任何人都能伪造身份。所以它要求 front-proxy 必须剥离外部传入的同名 header。

最后是兜底：所有认证器都失败时，请求会落到匿名认证器，身份是：

```
username: system:anonymous
groups:   [system:unauthenticated]
```

`--anonymous-auth=false` 可以关掉它，但健康检查 `/healthz`、`/livez` 这些端点通常需要匿名访问。

## 六、401 与 403 的边界

| 状态码 | 含义 | 典型原因 |
| --- | --- | --- |
| **401 Unauthorized** | 没认出你是谁 | 凭证缺失、过期、签名不对、audience 不匹配 |
| **403 Forbidden** | 认出你了，但你没权限 | 认证成功，RBAC / 授权 webhook 拒绝 |

一个常见的误判：看到 403 就去查证书。其实 403 说明**认证已经成功**，问题在 RBAC。

另外一个刻意设计：**401 不会告诉你具体哪一步失败**。"certificate expired" 和 "unknown authority" 对攻击者是信息泄露。要看细节，只能看 API Server 的审计日志和 `--v=6`。

如果你在审计日志里看到 `system:anonymous`，意思是：**你带的凭证一个都没被接受**，而不是"系统不认识这个用户"。

## 七、版本时间线

| 时间 | 版本 | 变化 |
| --- | --- | --- |
| 2015 | 1.0 | x509、静态 token、ServiceAccount token、匿名认证 |
| 2016 | 1.3 | OIDC 认证 |
| 2017 | 1.6 | Bootstrap Token 随 kubeadm 引入 |
| 2017 | 1.8 | kubelet 证书轮换 alpha |
| 2018 | 1.9 | Webhook Token 认证 |
| 2019 | 1.13 | BoundServiceAccountTokenVolume alpha |
| 2020 | 1.19 | kubelet 证书轮换 GA |
| 2021 | 1.21 | 投影 token beta |
| 2021 | 1.22 | 投影 token GA |
| 2022 | 1.24 | 不再自动创建长期 SA token Secret |
| 2023 | 1.29 | 结构化 `AuthenticationConfiguration` alpha |
| 2024 | 1.30 | 结构化认证配置 beta |

## 八、排障清单

| 现象 | 先查什么 |
| --- | --- |
| 401，日志里是 `system:anonymous` | 凭证根本没被任何认证器接受：证书是否被 apiserver 信任、token 是否过期、audience 是否匹配 |
| 401，`x509: certificate signed by unknown authority` | `--client-ca-file` 与签发 CA 不一致 |
| 401，OIDC token 看起来有效 | `--oidc-issuer-url` 必须与 token 的 `iss` 完全一致；`--oidc-client-id` 必须出现在 `aud` 里 |
| 401，SA token 在 1.24 后突然失效 | 旧脚本读 Secret 取 token；改用 projected volume 或 `TokenRequest` API |
| 403 | 认证已成功，查 RBAC：`kubectl auth can-i <verb> <resource> --as=<user>` |
| 证书一年后整体失联 | `admin.conf` / kubelet 证书过期；检查 `kubeadm certs check-expiration` |

## 九、设计师会追问的四个问题

**1. 为什么用户不是对象？**
因为身份是外部事实。把外部事实复制进集群，就要面对同步、过期、引导三个难题。代价是没有用户 API、RBAC 只能写字符串、离职不会自动清权。

**2. 为什么 x509 不做撤销？**
因为 CRL / OCSP 在大规模下不可靠。Kubernetes 选择用"短证书 + 轮换"替代"撤销"，把问题从"吊销"转成"过期"。

**3. 为什么 SA token 要改成投影卷？**
因为长期 bearer token 的泄露是不可检测、不可撤销的。投影卷把"永久凭证"换成了"有 audience、有过期、绑定 Pod 的短期票据"，把一次泄露的爆炸半径从"永久"压到"一小时"。

**4. 为什么认证器不能顺便做授权？**
因为授权需要看对象、看 namespace、看 verb，而认证发生在解析请求体之前。一旦认证器开始判断权限，它就得理解每一种资源——这会把 RBAC 的可解释性彻底毁掉。

## 小结

认证只做一件事——把各种形态的凭证，翻译成四个字段的 `user.Info`。它之所以是一条链、之所以没有 User 对象、之所以对失败原因含糊其辞，都是为了让"身份"这件事留在集群之外，让集群只负责解释，不负责存储。

理解这一点，再看 401 和 403，就不会再混：**401 是"我不认识你"，403 是"我认识你，但你不能"。**

---

## 参考资料

1. Kubernetes 官方文档：[Authenticating](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)、[Authorization Overview](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)
2. Kubernetes 源码（v1.34.0）：`staging/src/k8s.io/apiserver/pkg/authentication/`、`pkg/kubeapiserver/authenticator/config.go`
3. KEP：BoundServiceAccountTokenVolume、LegacyServiceAccountTokenNoAutoGeneration
4. Kubernetes 文档：[Managing Service Accounts](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/)

> 本文为原创内容，基于 Kubernetes v1.34.0 源码整理；版本号以对应 release note 为准。

就这四个字段。后面所有 RBAC 判断、审计日志、准入策略，都只认这四样东西。认证器不碰对象、不查 etcd、不判断权限——这条边界如果破了，整个权限模型就没法推理了。

kubernetes 进阶知识-API Server 认证：把凭证翻译成四个字段

这一篇只讲认证：它到底在回答什么问题、为什么必须是这个形状、六种认证方式各自解决什么、以及 401 和 403 为什么不能混为一谈。源码引用基于 Kubernetes v1.34.0。

运维开发工程师

云计算

安全

运维

Kubernetes认证机制深度解析：认证器如何将凭证转化为user.Info四字段，x509、OIDC、ServiceAccount等六种方式对比，401与403的区别及排障指南。基于v1.34.0源码，揭示为什么User不是API对象、SAtoken为何改成投影卷，帮助你彻底理解集群身份边界。

代码解释

Kubernetes

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

kubernetes 进阶知识-API Server 认证：把凭证翻译成四个字段-腾讯云开发者社区-腾讯云

kubernetes 进阶知识-API Server 认证：把凭证翻译成四个字段

kubernetes 进阶知识-API Server 认证：把凭证翻译成四个字段

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐