基于OIDC认证的KubeConfig相关技术问题咨询

提供的Kubernetes ClientConfig配置 #

kind: ClientConfig
apiVersion: authentication.gke.io/v2alpha1
spec:
  name: dev-corp
  server: https://10.x.x.x:443
  certificateAuthorityData: ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
  authentication:
  - name: oidc
    oidc:
      clientID: aaaaad3-9aa1-33c8-dd0-ddddd6b5bf5
      clientSecret: ccccccccccccccccc-
      issuerURI: https://login.microsoftonline.com/aaaa92-aab7-bbfa-cccf-ddaaaaaaaa/v2.0
      kubectlRedirectURI: http://localhost:12345/callback
      cloudConsoleRedirectURI: http://console.cloud.google.com/kubernetes/oidc
      scopes: offline_access,profile
      userClaim: upn
      userPrefix: '-'
      groupsClaim: groups
  preferredAuthentication: oidc

我理解上述配置采用的是client credential授权类型，该类型需要client_id、client_secret、token URL（即issuerURI）以及scope。

1. 各字段作用说明 #

• kubectlRedirectURI：kubectl执行OIDC认证流程时的回调地址，授权服务器（这里是Azure AD）会将授权码发送到该地址，kubectl再用授权码换取访问令牌和ID Token。
• cloudConsoleRedirectURI：Google Cloud Console访问该Kubernetes集群时使用的OIDC回调地址，用于控制台完成身份认证并获取集群访问权限。
• userClaim：指定从OIDC ID Token中提取哪个字段作为Kubernetes的用户名，这里配置为upn，即使用用户的User Principal Name作为K8s用户名。
• userPrefix：为生成的Kubernetes用户名添加前缀，避免不同身份源的用户名冲突，比如配置为'-'后，最终用户名会是-<upn值>。

2. OIDC与OAuth2的区别 #

• OAuth2是一套授权框架，核心是解决"第三方应用如何获取用户资源访问权限"的问题，它只负责授权，不提供用户身份的标准化信息。
• OIDC（OpenID Connect）是基于OAuth2扩展的身份认证协议，在OAuth2基础上新增了ID Token（一种JWT格式的身份令牌），标准化了用户身份信息的传递方式，既解决授权问题，也解决了跨系统的身份认证问题。简单说，OAuth2管"能不能访问"，OIDC管"你是谁"。

3. 存储带OIDC认证的ClientConfig到缓存的方案 #

client-go的api.Config结构体中的AuthProvider字段支持存储自定义的认证配置信息，你可以按以下步骤处理：

1. 将ClientConfig中OIDC相关的userClaim、userPrefix、groupsClaim等字段，存入api.Config.AuthProvider.Config这个map中。
2. 把转换后的api.Config对象存入缓存——不管是内存缓存还是文件缓存都可以，因为api.Config实现了序列化接口，能被正常持久化或缓存。
3. 后续从缓存读取api.Config时，可直接从AuthProvider.Config中取出OIDC的自定义字段，用于构建OIDC认证逻辑。

内容的提问来源于stack exchange，提问作者overexchange