K8s 身份认证的正确打开方式
推荐指数 51.0 NO. 023 · 2026.09.09
发布2026/09/08
为什么值得看
CNCF 官方博客指出多数本地 K8s 集群在部署首日就遗漏了访问控制配置，建议用 Public Client 模式对接身份提供商而非 Confidential Client。对正在自建 K8s 平台的团队来说，这能避免后续大规模改造 RBAC 的隐性成本。
编辑判断
大多数团队把 K8s 身份认证做成 Confidential Client 是因为照搬了 Web 应用的安全模型，但 kubectl 这种 CLI 工具无法安全保管 client secret，反而制造了"假安全"。Public Client + PKCE 才是原生适合命令行和 kubeconfig 场景的流程。
如果你现在用的 Dex、Keycloak 或企业自研的 K8s 登录方案还在要求配置 client secret，建议审计一下——这通常意味着要么 secret 被硬编码在无数开发者的机器上，要么中间加了不必要的代理层来保管 secret，两者都是技术债。
短期内可以行动的点：检查现有集群的 OIDC 配置是否支持 device code flow 或 PKCE，这对 CI/CD 流水线和服务账号的短期凭证管理也有连带好处。