排查 Anthos clusters on Bare Metal 中的 OIDC 问题

本页介绍如何识别和解决 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

  1. 使用 kubectl logs 输出 Anthos Identity Service 日志：

    kubectl --kubeconfig CLUSTER_KUBECONFIG -n anthos-identity-service logs \
deployment/ais --all-containers=true

  2. 查看日志中是否有错误可帮助您诊断 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.

  3. 如果您在日志中发现了配置问题，请继续重新配置 OIDC。

  4. 如果您无法自行诊断和解决问题，请与 Cloud 客户服务团队联系。

    Cloud 客户服务将需要 Anthos Identity Service 日志和 OIDC 规范，以诊断和解决 OIDC 问题。

检查集群中的 OIDC 规范

集群的 OIDC 信息在 kube-public 命名空间中的 clientconfig 对象中指定。

  1. 使用 kubectl get 输出集群的 OIDC 资源：

    kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public get \
clientconfig.authentication.gke.io default -o yaml

  2. 查看字段值，以确认已为您的 OIDC 提供商正确地配置了规范。

  3. 如果您在规范中发现配置问题，请继续重新配置 OIDC。

  4. 如果您无法自行诊断和解决问题，请与 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 中的详细信息用于为 Cloud Console 和适用于 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 提供方的 base64 编码的 PEM 编码证书。如需创建字符串，请将证书（包括标头）进行 base64 编码。将生成的字符串作为单独的一行添加到 certificateAuthorityData 中。

示例：
certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==

 字符串
clientID 是 向 OpenID 提供商发出身份验证请求的客户端应用的 ID。 字符串
clientSecret 否 OIDC 客户端应用和 OIDC 提供方之间的共享密钥令牌。 字符串
extraParams 否

要发送到 OpenID 提供方的其他键值对参数。如果您要向群组授权，请传入 resource=token-groups-claim。

如果您的授权服务器提示是否同意使用 Microsoft Azure 和 Okta 进行身份验证，请将 extraParams 设置为 prompt=consent。对于 Cloud Identity，请将 extraParams 设置为 prompt=consent,access_type=offline。

 英文逗号分隔列表
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. 字符串