本页介绍如何识别和解决 Anthos clusters on Bare Metal 的 OpenID Connect (OIDC) 问题。
识别 OIDC 问题
如果 OIDC 对于 Anthos clusters on Bare Metal 不起作用,原因通常是集群配置文件中的 OIDC 规范存在配置问题。本部分介绍如何查看日志和 OIDC 规范,以帮助确定 OIDC 问题的原因。
查看 Anthos Identity Service 日志
Anthos Identity Service 支持 Anthos clusters on Bare Metal 中的 OIDC
使用
kubectl logs
输出 Anthos Identity Service 日志:kubectl --kubeconfig CLUSTER_KUBECONFIG -n anthos-identity-service logs \ deployment/ais --all-containers=true
查看日志中是否有错误可帮助您诊断 OIDC 问题。
如果您无法通过 OIDC 进行身份验证,则 Anthos Identity Service 日志可以提供最相关、最有用的问题调试信息。
例如,如果 OIDC 规范(在集群配置文件中)在
issuerURL
字段中有录入错误,例如htps://accounts.google.com
(https 中缺少一个“t”),则 Anthos Identity 服务日志将包含如下所示的条目:OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
如果您在日志中发现了配置问题,请继续重新配置 OIDC。
如果您无法自行诊断和解决问题,请与 Cloud 客户服务团队联系。
Cloud Customer Care 将需要 Anthos Identity Service 日志和 OIDC 规范,以诊断和解决 OIDC 问题。
检查集群中的 OIDC 规范
集群的 OIDC 信息在 kube-public
命名空间中的 clientconfig
对象中指定。
使用
kubectl get
输出集群的 OIDC 资源:kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public get \ clientconfig.authentication.gke.io default -o yaml
查看字段值,以确认已为您的 OIDC 提供商正确地配置了规范。
如果您在规范中发现配置问题,请继续重新配置 OIDC。
如果您无法自行诊断和解决问题,请与 Cloud 客户服务团队联系。
Cloud Customer Care 将需要 Anthos Identity Service 日志和 OIDC 规范,以诊断和解决 OIDC 问题。
重新配置 OIDC
如果您在 Anthos Identity Service 日志或 clientconfig
对象中发现问题,则可以重新配置集群中的 OIDC(无需重新创建集群)以解决这些问题。如需重新配置 OIDC,请修改 kube-public
命名空间中 clientconfig
类型的 KRM 默认对象:
kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public edit clientconfig default
ClientConfig CRD 中的详细信息用于为 Google Cloud 控制台和适用于 Anthos 的身份验证插件配置 OIDC。如需详细了解 ClientConfig CRD 中包含的 OIDC 信息,请参阅以下 YAML 和相关字段描述表。
authentication: - name: oidc oidc: certificateAuthorityData: CERTIFICATE_STRING clientID: CLIENT_ID clientSecret: CLIENT_SECRET cloudConsoleRedirectURI: "http://console.cloud.google.com/kubernetes/oidc" deployCloudConsoleProxy: PROXY_BOOLEAN extraParams: EXTRA_PARAMS groupsClaim: GROUPS_CLAIM groupPrefix: GROUP_PREFIX issuerURI: ISSUER_URI kubectlRedirectURI: KUBECTL_REDIRECT_URI scopes: SCOPES userClaim: USER_CLAIM userPrefix: USER_PREFIX proxy: PROXY_URL
下表介绍了 ClientConfig CRD oidc
对象的字段。
字段 | 必填 | 说明 | 格式 |
---|---|---|---|
名称 | 是 | 要创建的 OIDC 配置的名称。 | 字符串 |
certificateAuthorityData | 否 | OIDC 提供方的 示例: |
字符串 |
clientID | 是 | 向 OpenID 提供方发出身份验证请求的客户端应用的 ID。 | 字符串 |
clientSecret | 否 | OIDC 客户端应用和 OIDC 提供方之间的共享密钥令牌。 | 字符串 |
extraParams | 否 |
要发送到 OpenID 提供方的其他键值对参数。如果您要向群组授权,请传入 如果您的授权服务器提示是否同意使用 Microsoft Azure 和 Okta 进行身份验证,请将 |
英文逗号分隔列表 |
groupsClaim | 否 | 提供方用于返回安全组的 JWT 声明。 | 字符串 |
groupPrefix | 否 | 附加到群组声明前面的前缀,以防止与现有名称冲突。例如,如果您有两个名为 foobar 的群组,请添加前缀 gid- 。生成的群组为 gid-foobar 。 |
字符串 |
issuerURI | 是 | 用于向 OpenID 发送授权请求的网址,例如 https://example.com/adfs 。Kubernetes API 服务器使用此网址来发现用于验证令牌的公钥。URI 必须使用 HTTPS。 |
网址字符串 |
kubectlRedirectURI | 是 | kubectl 用于授权的重定向网址。 |
网址字符串 |
scopes | 是 | 要发送到 OpenID 提供方的其他范围。Microsoft Azure 和 Okta 需要 offline_access 范围。 |
英文逗号分隔列表 |
userClaim | 是 | 用作用户名的 JWT 声明。您可以选择其他声明,例如电子邮件或名称,具体取决于 OpenID 提供方。不过,电子邮件以外的声明会以颁发者网址作为前缀,以防止命名冲突。 | 字符串 |
userPrefix | 否 | 附加到用户名声明前面的前缀,以防止与现有名称冲突。 | 字符串 |
proxy | 否 | 用于 auth 方法的代理服务器(如果适用)。例如 http://user:password@10.10.10.10:8888 |
字符串 |