把静态证书换成身份提供商：自建 Kubernetes 集群接入 OIDC 的动手清单
托管云 Kubernetes 自带 IAM 或 SSO，自建集群往往仍靠一张长期有效的静态客户端证书：人走了、设备丢了，访问权限还在。这篇指南介绍用身份提供商（如 Keycloak）接管认证的完整做法：改配置而不用迁移平台，权限变更从此变成改用户组。
作者：核流编辑 · 栏目：资源
访问控制本该和网络、存储一起出现在集群上线第一天的清单里，但在多数自建（on-prem）集群上，它从未进过这张清单。托管云 Kubernetes 自带 IAM 或 SSO 集成，自建集群没有：默认给到的是一张静态客户端证书或长期 token，签发一次之后几乎不再回收，谁离职、谁换岗，凭证本身不会给出任何提示。本文面向自建集群的平台与运维团队，介绍把默认静态凭证换成身份提供商接管认证的完整做法。它的用途很直接：权限变更从此变成一次用户组操作。 问题出在静态凭证上 静态证书在持有人离职、换岗或设备丢失之后依然有效，集群的认证链路不会检查它是否还应该被信任；要吊销它，就得找齐文件在每台机器上的每一份拷贝，现实中很难做全。当需要不同权限的人超过一两个，按人、按文件各自维护，本身就成了一份持续的工作。 替代方案是把身份提供商放到集群前面（Keycloak 或任何兼容 OIDC 的服务都可以），让访问权限跟随账号与用户组，而不是某个文件。整套集成由三个部分配合：kubectl 搭配 kubelogin 插件负责发起登录，并把拿到的 token 附在每个 API 请求上；身份提供商负责认证用户，签发带用户名与组信息的 ID token；kube-apiserver 通过 --oidc-issuer-url、--oidc-client-id、--oidc-groups-claim 校验 token、提取身份，再交给 RBAC 决定权限边界。 客户端配置里最关键的一条：把它注册为 public client，而不是 confidential client。机密客户端会签发一个 client secret，然后被写进每台机器的插件配置。需要分发到所有客户端才生效的 secret，已经不再是一个秘密，而是一份共享的静态凭证；轮换它意味着给每台机器做一次协同的配置推送。OAuth 2.1 对原生与命令行应用已经给出结论：用 public client，不签发 secret，改用 PKCE（S256）。客户端先在本地生成随机值，登录时只发送它的哈希，换取 token 时再证明自己持有原值，中途截获授权码的人无法完成这一步证明。 如何开始使用 部署或选用一个 OIDC 身份提供商，例如 Keycloak。 在管理后台注册 public client：Client authentication 关闭，重定向 URI 与 Web origins 限制在回环地址（127.0.0.1、localhost），开启 PKCE。 为 client 添加 Group Membership 类型的映射器，把组信息写入 ID token 的 groups 声明，Kubernetes 里的 RBAC 只认 token 中声明的用户名与组。 给 kube-apiserver 加上 OIDC 参数；身份提供商若使用自签名证书，还要追加 --oidc-ca-file 指向 CA 证书，否则会先撞上一条与登录流程无关的 TLS 校验错误，第一次排查时相当费解。 把 kubeconfig 里的静态证书或 token 换成 kubelogin 的 exec 凭证条目，不需要任何 secret 字段；首次登录会拉起浏览器，之后的请求复用缓存 token，过期时由刷新令牌静默续期。 登录后确认落到 token 里的身份与组是否符合预期，再按组完成 RBAC 绑定。 改完之后，权限变更全部发生在身份提供商里：把某人加入 platform-viewer 组，他下一次换到的 token 就会带上这个组，集群侧无需改动，也没有新的 kubeconfig 需要分发。审计上的收益同样直接：共享 kubeconfig 的时代，所有人在 API server 日志里都是同一个泛化身份（cluster-admin 是最常见的一个），日志等于白记；身份联邦之后，每条请求记录都能对上具体的人。按原文作者的说法，这套改造大约花费一个下午。完整的参数与流程可参考 Kubernetes 官方鉴权文档（见参考资料）。 参考资料 CNCF Blog：Kubernetes access via an identity provider: Public client, not confidential Kubernetes Documentation：Authenticating