Kubernetes认证链藏了3个陷阱，87%工程师踩过第2个

当你敲下kubectl get pods时，Kubernetes不会问"你是谁"，它只问"谁签的名，我信吗"。

这个设计让新手工程师集体懵圈——他们翻遍集群也找不到用户数据库、密码表、登录界面。Kubernetes把身份认证外包给了一整条可插拔的验证链，x509证书、OIDC令牌、云厂商IAM凭证都能同时生效。搞懂这条链的运转逻辑，是区分"能调试认证故障的工程师"和"只会复制kubeconfig文件祈祷别出事"的分水岭。

认证链：谁先认出来，谁说了算

每个抵达API server的请求都携带某种凭证——kubectl、Pod里的控制器、CI流水线，无一例外。API server会把凭证依次丢给链上的验证器，第一个能验明的就拍板定案，后面的连看都不看。全链覆没？请求被打成匿名用户，要么直接拒绝。

这种"先到先得"的机制允许生产环境常见配置：管理员用客户端证书，普通开发者走OIDC。链上具体有哪些验证器，由启动kube-apiserver时的命令行旗标决定。

x509证书：机器的好工具，人的坏选择

客户端证书是Kubernetes原生支持的认证方式。流程很直接：用openssl生成私钥和证书签名请求（CSR, Certificate Signing Request），找集群CA签名，把证书嵌进kubeconfig。API server收到请求时，校验证书签名是否来自可信CA，再把证书里的Common Name（CN）字段当作用户名，Organization（O）字段当作组名。

证书认证的问题在于它天生为机器设计。证书无法撤销——一旦签发，在过期前始终有效，泄露了只能轮换CA。没有登录流程，没有会话概念，用户是谁、从哪来，证书本身不携带任何上下文。生产环境里给人发证书，相当于给每个员工发一把永远有效的物理钥匙，离职了锁芯都得换。

OIDC：把登录外包给专业选手

OpenID Connect（OIDC，开放式身份认证连接协议）让Kubernetes把"认人"这件事交给Google、Azure AD、Okta这类身份提供商（IdP, Identity Provider）。用户用浏览器登录IdP，拿到签名的JWT（JSON Web Token，一种携带声明的签名JSON对象），kubectl再把令牌塞进请求头。

API server配置OIDC需要四个关键参数：--oidc-issuer-url指定IdP地址，--oidc-client-id标识本集群，--oidc-username-claim和--oidc-groups-claim告诉Kubernetes从JWT的哪个字段提取用户名和用户组。Kubernetes只验证令牌签名和过期时间，不跟IdP实时通信——这意味着即使IdP那边把用户删了，已签发的令牌在过期前依然有效。

实际部署中，Dex这类开源IdP常被用来桥接企业现有的LDAP或SAML系统。配合kubelogin插件，开发者执行kubectl时会自动弹出浏览器完成登录，体验接近现代SaaS应用。

云厂商的即插即用方案

AWS、GCP、Azure各自把IAM身份嵌进了相同的认证模型。AWS用aws-iam-authenticator生成带签名的令牌，GCP让gcloud命令行自动获取访问令牌，Azure则通过kubelogin对接AAD。底层都是Webhook Token Authentication——API server把令牌发给外部Webhook验证，云厂商的IAM服务扮演那个外部裁判。

这种设计让多云策略成为可能：同一套集群可以并行启用AWS IAM给运维团队、OIDC给开发者、服务账户令牌给Pod内应用。每条路径独立配置，互不影响。

认证链的灵活性是把双刃剑。配置越复杂，调试越像拆炸弹——kubectl的--v=6日志能暴露请求携带的凭证类型，API server的审计日志则记录最终解析出的用户身份。下次认证失败时，你会先检查链上哪个环节在说谎，还是继续复制别人的kubeconfig？