通过身份提供商访问Kubernetes：公开客户端，而非机密客户端
内容提要
自建Kubernetes集群常忽略访问控制，默认使用静态证书或长期令牌，难以撤销。建议集成OIDC身份提供商（如Keycloak），通过公开客户端和PKCE认证，使访问权限跟随用户组变化。配置包括kubelogin插件、Keycloak映射组声明、API服务器OIDC参数及RBAC绑定，实现权限动态管理，提升审计可追溯性，设置成本低。
延伸解读
为何选择公开客户端而非机密客户端
文章强调，若使用机密客户端，客户端密钥需分发到每台需要访问集群的机器，这实际上变成了共享的静态凭据，轮换时需协调推送配置，而非禁用单个受损身份。而公开客户端配合PKCE，无需分发密钥，拦截授权码的攻击者也无法兑换令牌，安全性更高且管理更简单。
权限变更的简化操作
通过OIDC集成，访问权限与身份提供者中的用户组绑定。添加或移除用户组成员即可即时生效，无需在集群侧修改RBAC或重新分发kubeconfig。这避免了传统静态证书或长期令牌在人员离职或角色变更后仍持续有效的问题，降低了权限管理成本。
审计追踪的改进
使用共享kubeconfig时，所有请求可能以同一身份（如cluster-admin）记录，审计日志无法区分具体操作者。集成OIDC后，每个API请求都携带真实用户名和组信息，使审计日志能准确记录谁执行了什么操作，提升了可追溯性，且设置成本不高。
Q&A
自建Kubernetes集群默认的访问控制方式存在哪些问题？
自建集群通常使用静态客户端证书或长期令牌，这些凭证难以撤销，且不会随人员离职或角色变化而失效。管理多个用户的权限需要逐人逐文件操作，审计日志也无法准确记录操作者身份。
如何通过OIDC身份提供商改进Kubernetes的访问控制？
集成OIDC身份提供商（如Keycloak），使用公开客户端和PKCE认证，让kubectl通过kubelogin插件获取令牌，API服务器验证令牌并提取用户和组信息，再由RBAC授权。这样权限变更只需在身份提供商中调整用户组即可。
为什么在Kubernetes OIDC集成中要使用公开客户端而不是机密客户端？
机密客户端需要分发客户端密钥到每个使用kubectl的机器，这实际上变成了共享静态凭证，难以安全管理和轮换。公开客户端不发放密钥，而是使用PKCE，即使授权码被拦截也无法兑换令牌，更安全且易于管理。
在Keycloak中配置Kubernetes客户端时，需要开启哪些选项？
需要将客户端认证设为Off（公开客户端），开启标准流程（Standard flow），关闭直接访问授权（Direct access grants），开启PKCE并要求S256方法，重定向URI和Web origins仅限回环地址（http://127.0.0.1:* 和 http://localhost:*），客户端作用域包含openid、profile、email和groups。
如何让Keycloak在ID令牌中包含用户组信息？
在Keycloak中，为realm级别的'groups'客户端作用域添加一个类型为'Group Membership'的协议映射器，将令牌声明名称设为'groups'，并确保'Add to ID token'选项开启。这样ID令牌中就会包含用户的组信息。
kube-apiserver需要配置哪些OIDC参数？
需要配置--oidc-issuer-url指向Keycloak的realm地址，--oidc-client-id设为'kubernetes'，--oidc-username-claim设为'preferred_username'，--oidc-groups-claim设为'groups'。如果Keycloak使用自签名证书，还需添加--oidc-ca-file参数指定CA证书路径。
kubectl的kubeconfig文件如何配置以使用OIDC认证？
在kubeconfig中为user配置exec凭证插件，使用kubectl oidc-login命令，并指定--oidc-issuer-url和--oidc-client-id参数。例如：exec: apiVersion: client.authentication.k8s.io/v1, command: kubectl, args: [oidc-login, get-token, --oidc-issuer-url=..., --oidc-client-id=kubernetes]。无需包含任何密钥字段。
如何将Keycloak中的用户组映射到Kubernetes的RBAC角色？
创建ClusterRoleBinding，将Keycloak中的组（如platform-viewer）绑定到Kubernetes的ClusterRole（如view）。例如，在subjects中指定kind: Group，name: platform-viewer，roleRef指向view角色。这样组内用户自动获得相应权限。
使用OIDC认证后，权限变更和审计有什么改进？
权限变更只需在身份提供商中调整用户组成员，无需重新分发kubeconfig。审计日志中每个请求都会记录实际用户名和组，而不是共享的cluster-admin，从而提供可追溯的审计记录。
