排查 Google Distributed Cloud 身份验证问题

本文档帮助排查 Google Distributed Cloud 中的身份验证问题。其中提供了常规问题排查信息和指南，以及 OpenID Connect (OIDC) 和轻量级目录访问协议 (LDAP) 的特定信息。

OIDC 和 LDAP 身份验证使用 GKE Identity Service。您必须先配置身份提供方，然后才能将 GKE Identity Service 与 Google Distributed Cloud 搭配使用。如果您尚未为 GKE Identity Service 配置身份提供方，请按照以下较常见的提供方之一的说明操作：

• Google OIDC
• Microsoft ADFS
• Azure AD
• Okta

请参阅 GKE Identity Service 身份提供方问题排查指南，了解如何启用和查看身份日志并测试连接。

如果您需要其他帮助，请与 Cloud Customer Care 联系。

常规问题排查

以下问题排查提示可帮助您解决 Google Distributed Cloud 的一般身份验证和授权问题。如果这些问题不适用或您存在 OIDC 或 LDAP 问题，请继续阅读关于 GKE Identity Service 问题排查的部分。

及时更新 gcloud anthos auth

您可以通过验证 gcloud anthos auth 安装的组件处于最新状态，以避免许多常见问题。

有两个部分必须验证。gcloud anthos auth 命令的逻辑存在于 Google Cloud CLI 核心组件以及独立封装的 anthos-auth 组件中。

1. 如需更新 Google Cloud CLI，请运行以下命令：

   gcloud components update
   

2. 如需更新 anthos-auth 组件，请运行以下命令：

   gcloud components install anthos-auth
   

提供商配置无效

如果您的身份提供方配置无效，点击LOGIN后，身份提供方将显示错误屏幕。按照特定于提供方的说明正确配置提供方或您的集群。

配置无效

如果 Google Cloud 控制台无法从集群中读取 OIDC 配置，则LOGIN按钮会被停用。如需排查集群 OIDC 配置问题，请参阅本文档中的以下排查 OIDC 问题部分。

权限无效

如果您完成了身份验证流程，但仍看不到集群的详细信息，请确保您已向与 OIDC 搭配使用的账号授予了正确的 RBAC 权限。此账号可能与您用于访问 Google Cloud 控制台的账号不同。

缺少刷新令牌

如果授权服务器提示是否同意，但未提供所需的身份验证参数，就会出现以下问题。

Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct

要解决此问题，请在 ClientConfig 资源中将 prompt=consent 添加到 authentication.oidc.extraParams 字段。然后重新生成客户端身份验证文件。

刷新令牌已过期

当 kubeconfig 文件中的刷新令牌过期时，会出现以下问题：

Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
    certificate signed by unknown authority

如需解决此问题，请再次运行 gcloud anthos auth login 命令。

gcloud anthos auth login 失败并显示 proxyconnect tcp

如果 https_proxy 或 HTTPS_PROXY 环境变量配置出错，就会出现此问题。如果环境变量中指定了 https://，则当代理配置为使用其他协议（如 SOCK5）来处理 HTTPS 连接时，GoLang HTTP 客户端库可能会失败。

可能会返回以下示例错误消息：

proxyconnect tcp: tls: first record does not look like a TLS handshake

如需解决此问题，请修改 https_proxy 和 HTTPS_PROXY 环境变量以省略 https:// prefix。在 Windows 上，修改系统环境变量。例如，将 https_proxy 环境变量的值从 https://webproxy.example.com:8000 更改为 webproxy.example.com:8000。

使用 gcloud anthos auth login 生成的 kubeconfig 时集群访问失败

当 Kubernetes API 服务器无法向用户授权时，就会出现此问题。如果相应的 RBAC 不存在或错误，或者集群的 OIDC 配置存在错误，就可能发生这种情况。系统可能会显示以下示例错误：

Unauthorized

如需解决此问题，请完成以下步骤：

1. 在 gcloud anthos auth login 生成的 kubeconfig 文件中，复制 id-token 的值。

   kind: Config
   ...
   users:
   - name: ...
     user:
       auth-provider:
         config:
           id-token: xxxxyyyy
   

2. 安装 jwt-cli 并运行以下命令：

   jwt ID_TOKEN
   

3. 验证 OIDC 配置。

   ClientConfig 资源具有 group 和 username 字段。这些字段用于在 Kubernetes API 服务器中设置 --oidc-group-claim 和 --oidc-username-claim 标志。当 API 服务器收到令牌时，会将令牌转发到 GKE Identity Service，后者随后会将提取的 group-claim 和 username-claim 返回给 API 服务器。API 服务器使用响应来验证对应的组或用户具有正确的权限。

   验证 ID 令牌中包含 ClientConfig 资源中为 group 和 user 设置的声明。

4. 检查已应用的 RBAC。

   针对上一步由 username-claim 指定的用户或者 group-claim 中列出的某个群组，验证是否存在具有正确权限的 RBAC。RBAC 中用户或群组的名称应该带有 ClientConfig 资源中指定的 usernameprefix 或 groupprefix 前缀。

   如果 usernameprefix 为空，并且 username 的值不是 email，则前缀默认为 issuerurl#。要停用用户名前缀，请将 usernameprefix 设置为 -。

   如需详细了解用户和群组前缀，请参阅使用 OIDC 进行身份验证。

   注意：Kubernetes API 服务器将反斜杠视为转义字符。如果用户或群组的名称包含 \\，则 API 服务器会在解析 ID 令牌时将其作为单个 \ 进行读取。因此，应用到此用户或群组的 RBAC 角色绑定只能包含一个反斜杠，否则您可能会看到 Unauthorized 错误。

   ClientConfig 资源：

   oidc:
     ...
     username: "unique_name"
     usernameprefix: "-"
     group: "group"
     groupprefix: "oidc:"
   

   ID 令牌：

   {
     ...
     "email": "[e-mail]",
     "unique_name": "EXAMPLE\cluster-developer",
     "group": [
       "Domain Users",
       "EXAMPLE\developers"
     ],
   ...
   }
   

   以下 RBAC 绑定会向此群组和用户授予 pod-reader 集群角色。请注意名称字段中应包含单斜杠，而不是双斜杠：

   群组 ClusterRoleBinding：

   apiVersion:
   kind: ClusterRoleBinding
   metadata:
     name: example-binding
   subjects:
   - kind: Group
     name: "oidc:EXAMPLE\developers"
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: pod-reader
     apiGroup: rbac.authorization.k8s.io
   

   用户 ClusterRoleBinding：

   apiVersion:
   kind: ClusterRoleBinding
   metadata:
     name: example-binding
   subjects:
   - kind: User
     name: "EXAMPLE\cluster-developer"
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: pod-reader
     apiGroup: rbac.authorization.k8s.io
   

5. 检查 Kubernetes API 服务器日志。

   如果 Kubernetes API 服务器中配置的 OIDC 插件未正确启动，则 API 服务器会在收到 ID 令牌时返回 Unauthorized 错误。如需检查 API 服务器中的 OIDC 插件是否存在任何问题，请运行以下命令：

   kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \
     --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

   请替换以下内容：

   • USER_CLUSTER_NAME：要查看其日志的用户集群的名称。
   • ADMIN_CLUSTER_KUBECONFIG：管理员集群 kubeconfig 文件。

gkectl create-login-config 无法获取 clientconfig

如果传递到 gkectl create-login-config 的 kubeconfig 文件不适用于用户集群，或者 ClientConfig 资源在集群创建过程中未出现，则会出现此问题。

Error getting clientconfig using KUBECONFIG

要解决此问题，请确保用户集群具有正确的 kubeconfig 文件。然后检查 ClientConfig 资源是否在集群中：

kubectl get clientconfig default -n kube-public \
  --kubeconfig USER_CLUSTER_KUBECONFIG

将 USER_CLUSTER_KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。

gkectl create-login-config 由于集群名称重复而失败

如果您尝试写入包含目标文件中已存在的集群名称的登录配置数据，则会出现此问题。每个登录配置文件都必须包含唯一的集群名称。

error merging with file MERGE_FILE because MERGE_FILE contains a cluster with
  the same name as the one read from KUBECONFIG. Please write to a new
  output file

如需解决此问题，请使用 --output 标志指定新的目标文件。

如果您未提供 --output，此登录配置数据会写入当前目录中名为 kubectl-anthos-config.yaml 的文件。

排查 OIDC 问题

如果 OIDC 身份验证对于 Google Distributed Cloud 不起作用，通常是由于 ClientConfig 资源中的 OIDC 规范未正确配置。ClientConfig 资源介绍如何查看日志和 OIDC 规范，以帮助确定 OIDC 问题的原因。

请参阅 GKE Identity Service 身份提供方问题排查指南，了解如何启用和查看身份日志并测试连接。在您确认 GKE Identity Service 按预期运行或识别问题后，请查看以下 OIDC 问题排查信息。

检查集群中的 OIDC 规范

集群的 OIDC 信息在 kube-public 命名空间中的 ClientConfig 资源中指定。

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

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

   将 KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。

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

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

4. 如果您无法自行诊断和解决问题，请与 Google Cloud 支持团队联系。

   Google Cloud 支持团队需要查看 GKE Identity Service 日志和 OIDC 规范，以诊断和解决 OIDC 问题。

验证是否已启用 OIDC 身份验证

在测试 OIDC 身份验证之前，请验证是否已在集群中启用 OIDC 身份验证。

1. 检查 GKE Identity Service 日志：

   kubectl logs -l k8s-app=ais -n anthos-identity-service
   

   以下示例输出显示 OIDC 身份验证已正确启用：

   ...
   I1011 22:14:21.684580      33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started.
   ...
   

   如果 OIDC 身份验证未正确启用，则会显示如下错误示例：

   Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
   

   查看报告的具体错误并尝试改正。

测试 OIDC 身份验证

如需使用 OIDC 功能，请使用启用了界面和浏览器的工作站。您无法从基于文本的 SSH 会话执行这些步骤。如需测试 OIDC 在您的集群中是否正常运行，请完成以下步骤：

1. 下载 Google Cloud CLI。

2. 如需生成登录配置文件，请运行以下 gcloud anthos create-login-config 命令：

   gcloud anthos create-login-config \
     --output user-login-config.yaml \
     --kubeconfig KUBECONFIG
   

   将 KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。

3. 如需对用户进行身份验证，请运行以下命令：

   gcloud anthos auth login --cluster CLUSTER_NAME \
     --login-config user-login-config.yaml \
     --kubeconfig AUTH_KUBECONFIG
   

   请替换以下内容：

   • 将 CLUSTER_NAME 替换为要连接到的用户集群的名称。
   • 将 AUTH_KUBECONFIG 替换为要创建的新 kubeconfig 文件，其中包含用于访问集群的凭据。如需了解详情，请参阅向集群进行身份验证。

4. 您应该会收到在本地工作站的默认网络浏览器中打开的登录同意页面。在登录提示中提供用户的有效身份验证信息。

   成功完成上一个登录步骤后，当前目录中会生成一个 kubeconfig 文件。

5. 如需测试包含凭据的新 kubeconfig 文件，请列出用户集群中的 Pod：

   kubectl get pods --kubeconfig AUTH_KUBECONFIG
   

   将 AUTH_KUBECONFIG 替换为上一步中生成的新 kubeconfig 文件的路径。

   以下示例消息可能会返回，显示您可以成功进行身份验证，但未为该账号分配基于角色的访问权限控制 (RBAC)：

   Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
   

查看 OIDC 身份验证日志

如果您无法通过 OIDC 进行身份验证，则 GKE Identity Service 日志可以提供最相关、最有用的问题调试信息。

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

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

   将 KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。

2. 查看日志中是否有错误可帮助您诊断 OIDC 问题。

   例如，ClientConfig 资源在 issuerURL 字段中可能有拼写错误，例如 htps://accounts.google.com（https 中缺少 t）。GKE Identity Service 日志会包含类似于以下示例的条目：

   OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
   

3. 如果您在日志中发现配置问题，请重新配置 OIDC 并更正配置问题。

4. 如果您无法自行诊断和解决问题，请与 Google Cloud 支持团队联系。Google Cloud 支持团队需要查看 GKE Identity Service 日志和 OIDC 规范，以诊断和解决 OIDC 问题。

常见的 OIDC 问题

如果您在进行 OIDC 身份验证时遇到问题，请查看以下常见问题。请按照有关如何解决问题的任何指导进行操作。

没有可用于服务“ais”的端点

保存 ClientConfig 资源时，系统会返回以下错误消息：

  Error from server (InternalError): Internal error occurred: failed calling webhook "clientconfigs.validation.com":
  failed to call webhook: Post "https://ais.anthos-identity-service.svc:15000/admission?timeout=10s":
  no endpoints available for service "ais"

此错误是由健康状况不佳的 GKE Identity Service 端点引起的。GKE Identity Service Pod 无法响应验证 webhook。

1. 如需确认 GKE Identity Service Pod 健康状况不佳，请运行以下命令：

   kubectl get pods -n anthos-identity-service \
     --kubeconfig KUBECONFIG
   

   将 KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。

   以下示例输出意味着您的 GKE Identity Service Pod 崩溃：

   NAME                  READY  STATUS            RESTARTS  AGE
   ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s
   

2. 如需了解 Pod 出现问题的原因，请查看 Pod 事件：

   kubectl describe pod -l k8s-app=ais \
     -n anthos-identity-service \
     --kubeconfig KUBECONFIG
   

   将 KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。

   以下示例输出报告的是在拉取映像时的权限错误：

   Events:
     Type     Reason     Age                     From               Message
     ----     ------     ----                    ----               -------
     Normal   Scheduled  10m                     default-scheduler  Successfully assigned anthos-identity-service/ais-5949d879cd-flv9w to pool-1-76bbbb8798-dknz5
     Normal   Pulling    8m23s (x4 over 10m)     kubelet            Pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"
     Warning  Failed     8m21s (x4 over 10m)     kubelet            Failed to pull image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": failed to resolve reference "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": pulling from host gcr.io failed with status code [manifests hybrid_identity_charon_20220808_2319_RC00]: 401 Unauthorized
     Warning  Failed     8m21s (x4 over 10m)     kubelet            Error: ErrImagePull
     Warning  Failed     8m10s (x6 over 9m59s)   kubelet            Error: ImagePullBackOff
     Normal   BackOff    4m49s (x21 over 9m59s)  kubelet            Back-off pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"
   

3. 如果 Pod 事件报告问题，请在受影响的范围内继续排查问题。如需额外帮助，请与 Google Cloud 支持团队联系。

从服务器读取响应字节失败

您可能会在 GKE Identity Service 日志中看到以下错误：

  E0516 07:24:38.314681      65 oidc_client.cc:207] Failed fetching the Discovery URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/.well-known/openid-configuration" with error:
  Failed reading response bytes from server.

  E0516 08:24:38.446504      65 oidc_client.cc:223] Failed to fetch the JWKs URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/certs" with error:
  Failed reading response bytes from server.

这些网络连接错误在日志中的出现方式可能会是：

• 稀疏地出现在日志中：稀疏错误可能不是主要问题，并且可能是间歇性网络问题。

  GKE Identity Service OIDC 插件具有守护进程，每 5 秒定期同步 OIDC 发现网址。如果网络连接不稳定，则此出站流量请求可能会失败。偶发故障不会影响 OIDC 身份验证。现有的缓存数据可以重复使用。

  如果您在日志中遇到稀疏的错误，请继续按照其他问题排查步骤进行操作。

• 不断出现在日志中，或者 GKE Identity Service 未成功到达已知端点：这些常见问题表示 GKE Identity Service 与您的 OIDC 身份提供方之间的连接有问题。

  以下问题排查步骤可帮助诊断这些连接问题：

  1. 确保防火墙不会阻止来自 GKE Identity Service 的出站请求。
  2. 检查身份提供方服务器是否正常运行。
  3. 验证 ClientConfig 资源中的 OIDC 颁发者网址是否配置正确。
  4. 如果您在 ClientConfig 资源中启用了代理字段，请查看出站代理服务器的状态或日志。
  5. 测试 GKE Identity Service Pod 与 OIDC 身份提供方服务器之间的连接。

您必须登录服务器（未经授权）

尝试使用 OIDC 身份验证登录时，您可能会收到以下错误消息：

  You must be logged in to the server (Unauthorized)

这是一个常见的 Kubernetes 身份验证问题，不会提供任何其他信息。但是，此错误确实表示存在配置问题。

如需确定此问题，请查看前面的部分以检查集群中的 OIDC 规范并配置 ClientConfig 资源。

未能发出 webhook 身份验证器请求

在 GKE Identity Service 日志中，您可能会看到以下错误：

  E0810 09:58:02.820573       1 webhook.go:127] Failed to make webhook authenticator request:
  error trying to reach service: net/http: TLS handshake timeout

此错误表示 API 服务器无法与 GKE Identity Service Pod 建立连接。

1. 如需验证是否可以从外部访问 GKE Identity Service 端点，请运行以下 curl 命令：

   curl -k  -s -o /dev/null -w "%{http_code}" -X POST \
     https://APISERVER_HOST/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
   

   将 APISERVER_HOST 替换为您的 API 服务器的地址。

   预期响应为 HTTP 400 状态代码。如果请求超时，请重启 GKE Identity Service Pod。如果错误仍然存在，则表示 GKE Identity Service HTTP 服务器无法启动。如需更多帮助，请与 Google Cloud 支持团队联系。

找不到登录网址

当 Google Cloud 控制台无法访问身份提供方时，会出现以下问题。尝试登录时会被重定向到显示 URL not found 错误的页面。

如需解决此问题，请参阅以下问题排查步骤。完成每个步骤后，请再次尝试登录：

1. 如果无法通过公共互联网访问身份提供方，请启用 OIDC HTTP 代理以使用 Google Cloud 控制台登录。修改 ClientConfig 自定义资源并将 useHTTPProxy 设置为 true：

   kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
   

   将 USER_CLUSTER_KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。

2. 如果已启用 HTTP 代理，但您仍然遇到此错误，则可能是代理启动时出现问题。查看代理的日志：

   kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
   

   将 USER_CLUSTER_KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。

   即使您的身份提供方有知名 CA，您也必须在 ClientConfig 自定义资源中提供 oidc.caPath 的值，才能成功启动 HTTP 代理。

3. 如果授权服务器提示是否同意，而您未添加 extraparam prompt=consent 参数，请修改 ClientConfig 自定义资源，并将 prompt=consent 添加到 extraparams 参数：

   kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
   

   将 USER_CLUSTER_KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。

4. 如果存储服务的配置设置发生更改，您可能需要明确退出现有会话。在 Google Cloud 控制台中，前往集群详情页面，然后选择退出。

排查 LDAP 问题

如果您在进行 LDAP 身份验证时遇到问题，请确保已按照相应的配置文档之一设置环境：

• OpenLDAP
• Azure AD
• Microsoft Active Directory
• Google LDAP

您还需要确保填充 LDAP 服务账号密钥，并且配置了用于启用 LDAP 身份验证的 ClientConfig 资源。

请参阅 GKE Identity Service 身份提供方问题排查指南，了解如何启用和查看身份日志并测试连接。在您确认 GKE Identity Service 按预期工作或识别问题后，请查看以下 LDAP 问题排查信息。

验证 LDAP 身份验证已启用

在测试 LDAP 身份验证之前，请验证是否已在集群中启用 LDAP 身份验证。

1. 检查 GKE Identity Service 日志：

   kubectl logs -l k8s-app=ais -n anthos-identity-service
   

   以下示例输出显示 LDAP 身份验证已正确启用：

   ...
   I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
   ...
   

   如果未正确启用 LDAP 身份验证，则会显示类似如下的错误示例：

   Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
   

   查看报告的具体错误并尝试改正。

测试 LDAP 身份验证

如需使用 LDAP 功能，请使用启用了界面和浏览器的工作站。您无法从基于文本的 SSH 会话执行这些步骤。如需测试 LDAP 身份验证在您的集群中是否正常运行，请完成以下步骤：

1. 下载 Google Cloud CLI。

2. 如需生成登录配置文件，请运行以下 gcloud anthos create-login-config 命令：

   gcloud anthos create-login-config \
     --output user-login-config.yaml \
     --kubeconfig KUBECONFIG
   

   将 KUBECONFIG 替换为用户集群 kubeconfig 文件的路径。

3. 如需对用户进行身份验证，请运行以下命令：

   gcloud anthos auth login --cluster CLUSTER_NAME \
     --login-config user-login-config.yaml \
     --kubeconfig AUTH_KUBECONFIG
   

   请替换以下内容：

   • 将 CLUSTER_NAME 替换为要连接到的用户集群的名称。
   • 将 AUTH_KUBECONFIG 替换为要创建的新 kubeconfig 文件，其中包含用于访问集群的凭据。如需了解详情，请参阅向集群进行身份验证。

4. 您应该会收到在本地工作站的默认网络浏览器中打开的登录同意页面。在登录提示中提供用户的有效身份验证信息。

   成功完成上一个登录步骤后，当前目录中会生成一个 kubeconfig 文件。

5. 如需测试包含凭据的新 kubeconfig 文件，请列出用户集群中的 Pod：

   kubectl get pods --kubeconfig AUTH_KUBECONFIG
   

   将 AUTH_KUBECONFIG 替换为上一步中生成的用户集群 kubeconfig 的路径。

   Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
   

常见 LDAP 问题

如果您在进行 LDAP 身份验证时遇到问题，请查看以下常见问题。请按照有关如何解决问题的任何指导进行操作。

用户的 CN 包含英文逗号，无法进行身份验证

使用 LDAP 时，如果用户的 CN 包含英文逗号（例如 CN="a,b"），则可能无法进行身份验证。如果您为 GKE Identity Service 启用了调试日志，则系统会报告以下错误消息：

  I0207 20:41:32.670377 30 authentication_plugin.cc:977] Unable to query groups from the LDAP server directory.example.com:636, using the LDAP service account
  'CN=svc.anthos_dev,OU=ServiceAccount,DC=directory,DC=example,DC=com'.
  Encountered the following error: Empty entries.

出现此问题的原因是 GKE Identity Service LDAP 插件对英文逗号进行双重转义。此问题仅在 Google Distributed Cloud 1.13 及更早版本中出现。

如需解决此问题，请完成以下步骤之一：

1. 将集群升级到 Google Distributed Cloud 1.13 或更高版本。
2. 选择其他 identifierAttribute（例如 sAMAccountName），而不要使用 CN。
3. 从 LDAP 目录中的 CN 中移除英文逗号。

Google Cloud CLI 1.4.2 身份验证失败

如果使用 Google Cloud CLI anthos-auth 1.4.2，您在运行 gcloud anthos auth login 命令时可能会看到以下错误消息：

  Error: LDAP login failed: could not obtain an STS token: Post "https://127.0.0.1:15001/sts/v1beta/token":
  failed to obtain an endpoint for deployment anthos-identity-service/ais: Unauthorized
  ERROR: Configuring Anthos authentication failed

在 GKE Identity Service 日志中，您还会看到以下错误：

  I0728 12:43:01.980012      26 authentication_plugin.cc:79] Stopping STS   authentication, unable to decrypt the STS token:
  Decryption failed, no keys in the current key set could decrypt the payload.

要解决此错误，请完成以下步骤：

1. 检查您使用的是否为 Google Cloud CLI anthos-auth 1.4.2 版：

   gcloud anthos auth version
   

   以下示例输出显示版本为 1.4.2：

   Current Version: v1.4.2
   

2. 如果您运行的是 Google Cloud CLI anthos-auth 1.4.2 版，请升级到 1.4.3 版或更高版本。

常见问题

本部分详细介绍了常见的身份验证问题以及如何解决这些问题。

由于 SSH 密钥 permission denied 错误，无法访问管理员工作站

如果您尝试连接到管理员工作站并收到类似于以下示例的 "Permission denied" 消息，则会发生以下错误：

Authorized users only. All activity may be monitored and reported.
TARGET_MACHINE: Permission denied (publickey).

使用 SSH 连接到管理员工作站时，如果使用了错误的私钥或没有密钥，就会发生此错误。

如需解决此问题，请找到并使用正确的 SSH 密钥。如果您找不到正确的 SSH 密钥，请按照以下步骤为管理员工作站生成新的 SSH 密钥对：

1. 创建临时抢救虚拟机。此抢救虚拟机必须连接到与当前管理员工作站虚拟机相同的网络和数据中心。

2. 关闭管理员工作站虚拟机和救援虚拟机。

3. 将管理员工作站虚拟机的数据磁盘挂接到救援虚拟机。数据磁盘通常为 512 MB，除非您在管理员工作站配置文件中指定了不同的磁盘大小（该大小与启动磁盘不同）。

4. 启动抢救虚拟机。

5. 使用 SSH 连接到抢救虚拟机。

6. 在本地计算机上，生成新的 SSH 密钥对。

7. 在本地计算机上，使用 ssh-copy-id 命令将新的 SSH 公钥复制到抢救虚拟机：

   ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM
   

   请替换以下内容：

   • 将 NEW_SSH_KEY 替换为您在上一步中创建的新 SSH 密钥的名称。
   • 将 RESCUE_VM 替换为您的抢救虚拟机的 IP 地址或 FQDN。

8. 在救援虚拟机上，将数据磁盘装载到救援虚拟机上：

   sudo mkdir -p /mnt/ext-disk
   sudo mount DEVICE /mnt/ext-disk
   

   将 DEVICE 替换为您自己的磁盘的唯一标识符，例如 /dev/sdb1。

9. 在救援虚拟机上，将新的 SSH 公钥从管理员工作站虚拟机复制到已装载数据磁盘上的 authorized_keys 文件中。

   查看救援虚拟机上 authorized_keys 文件的内容，其中包括在上一步中使用 ssh-copy-id 命令复制的新 SSH 公钥：

   ls ~/.ssh/authorized_keys
   

   从 authorized_keys 文件中复制最后一个 SSH 公钥条目，然后关闭该文件。

10. 从管理员工作站虚拟机修改装载的数据磁盘上的 authorized_keys 文件：

    vi /mnt/ext-disk/.ssh/authorized_keys
    

    将救援虚拟机的 authorized_keys 文件中的 SSH 公钥内容粘贴到此处。

11. 保存并关闭管理员工作站虚拟机中已装载数据磁盘上的 authorized_keys 文件。

12. 验证 /mnt/ext-disk/.ssh/ 中的文件应用了正确的权限：

    chown -R ubuntu /mnt/ext-disk/.ssh/*
    chmod -R 600 /mnt/ext-disk/.ssh/*
    

13. 退出与救援虚拟机的 SSH 连接。

14. 关停抢救虚拟机。

15. 将数据磁盘与救援虚拟机分离，然后将磁盘重新挂接到管理员工作站虚拟机。

16. 启动管理员工作站。

17. 虚拟机成功运行后，使用 SSH 和新的 SSH 密钥对连接到管理工作站。

    ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM
    

    请替换以下内容：

    • 将 NEW_SSH_KEY 替换为您在上一步中创建并复制到管理员工作站虚拟机的新 SSH 密钥的名称。
    • 将 RESCUE_VM 替换为管理员工作站虚拟机的 IP 地址或 FQDN。

    验证您能否使用 SSH 成功连接。

18. 删除救援虚拟机。

后续步骤

如果您需要其他帮助，请与 Cloud Customer Care 联系。