【kube-apiserver】Authentication：SA、Bearer、OIDC 边界
内容提要
本文介绍Kubernetes v1.30.3中kube-apiserver的认证链结构，涵盖X509证书、SA token、静态Bearer、Bootstrap、OIDC及Webhook等认证器边界。文章区分401（认证失败）、403（授权失败）、503（存储或Webhook故障）等错误码，并讨论SA token过期、OIDC JWKS缓存等排障要点，强调认证与授权职责分离。
延伸解读
认证链顺序与短路机制
kube-apiserver 的认证器按固定顺序组成链，依次尝试直到成功或全部失败。理解这一顺序对排障至关重要：例如，若 X509 证书有效，则后续的 SA token、OIDC 等认证器不会执行。因此，当客户端同时提供多种凭证时，实际生效的总是链中靠前的认证器。这解释了为何某些看似配置了 OIDC 的请求却以 X509 身份通过认证。
401 与 503 的排障分列
文章强调 401 与 503 分别对应认证轴和存储/Webhook 轴，但实际排障中常因混淆而误判。例如，etcd 不可达时 apiserver 返回 503，但若同时存在 token 过期，则可能先返回 401。建议先根据返回码定位轴，再检查对应组件：401 检查 token 有效期、签名密钥、OIDC issuer；503 检查 etcd 健康、webhook 服务可用性。
OIDC 与 Webhook 认证的差异
OIDC 认证在 apiserver 本地验证 JWT 签名，依赖缓存的 JWKS，不实时联系 IdP，因此 IdP 吊销 token 后仍可能被接受。而 Webhook 认证则每次请求都调用外部服务，外部不可用即认证失败。选择时需权衡：OIDC 减少外部依赖但吊销延迟，Webhook 实时但引入额外故障点。
Q&A
kube-apiserver 返回 401 和 503 分别代表什么？
401 表示认证失败，属于 Authentication 轴的问题，例如 token 过期、签名密钥不匹配或 OIDC issuer 不符；503 通常表示存储或 Webhook 故障，属于 Storage 或 Admission 轴，例如 etcd 不可达或 webhook 故障。
kube-apiserver 的认证链包含哪些认证器？顺序是怎样的？
认证链依次为：X509 客户端证书、SA token (JWT)、静态 Bearer token、Bootstrap token、OIDC JWT、Webhook token，最后是匿名认证。按顺序调用，直到某个认证器成功或全部失败。
SA token 有哪两种？它们有什么区别？
SA token 分为 Legacy SA token 和 Bound SA token。Legacy token 是长期有效的 JWT，无过期时间，由 apiserver 私钥签名；Bound token 通过 TokenRequest API 颁发，带过期时间（默认 3600 秒）、受众和绑定对象，kubelet 会自动轮换。
OIDC 认证中，apiserver 如何验证 JWT？它和 Webhook 认证有什么不同？
apiserver 通过 OIDC discovery endpoint 获取 JWKS 并缓存，然后本地验证 JWT 签名，不向 IdP 发起实时认证请求。Webhook 认证则是将 TokenReview 发送给外部服务，由外部服务验证并返回结果。
如何排查 SA token 过期问题？
可以查看 kubelet 日志中的 'token expired, refreshing' 信息，或使用 `kubectl create token <sa-name>` 颁发临时 token 来验证签名密钥是否一致。
X509 客户端证书认证有什么特点？
X509 证书在 TLS 握手阶段验证，CN 作为用户名，O 作为组。控制面组件默认使用此方式。但证书无法在线吊销，v1.30 中仍无内置 CRL/OCSP 机制。
匿名认证默认是开启的吗？关闭后会发生什么？
默认开启（--anonymous-auth=true）。未认证请求会被赋予 system:anonymous 用户和 system:unauthenticated 组，并进入授权链。关闭后，未认证请求直接返回 401。
静态 Bearer token 认证有什么缺点？
token 明文存储在文件中，修改需要重启 apiserver，且无过期机制，因此生产中不推荐使用。
