本文档提供有关在您使用第三方身份提供方对舰队成员集群进行身份验证时，排查用户访问权限问题的指导。
gcloud anthos create-login-config 未能获取 clientconfig
此问题会在以下情况下发生：
- 传递给
gcloud anthos create-login-config的 kubeconfig 文件不正确。 - ClientConfig 自定义资源在集群中不存在（集群中未配置第三方身份验证）。
错误消息
failed to get clientconfig default in namespace kube-public
解决方案
如需解决此问题，请执行以下操作：
- 确保您的集群具有正确的 kubeconfig 文件。
要验证 ClientConfig 自定义资源是否在集群中，请运行以下命令：
kubectl --kubeconfig KUBECONFIG get clientconfig default -n kube-public
如果集群中不存在 ClientConfig，请在集群上安装并配置 ClientConfig。如需详细了解集群设置选项，请参阅集群设置选项。
gcloud anthos create-login-config 由于集群名称重复而失败
如果您尝试在已经包含此集群登录配置的文件中创建此集群的登录配置，则会出现此问题。
错误消息
error merging with file FILENAME because FILENAME contains a
cluster with the same name as the one read from KUBECONFIG.
解决方案
如需解决此问题，请使用 --output 标志指定新的目标文件。
如果未提供 --output，此登录配置数据将写入当前目录中名为 kubectl-anthos-config.yaml 的文件。
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 服务器出于以下某种原因无法向用户授权时，就会出现此问题：
- 用于使用
gcloud anthos auth login命令登录的配置存在错误。 - 用户必需的 RBAC 政策不正确或缺失。
错误消息
Unauthorized
解决方案
如需解决此问题，请执行以下操作：
验证用于登录的配置。
OIDC 配置
用户集群配置文件中的
authentication.oidc部分具有group和username字段，这两个字段用于设置 Kubernetes API 服务器中的--oidc-group-claim和--oidc-username-claim标志。当 API 服务器收到用户的身份令牌后，它会将令牌转发到集群，后者会将提取的group-claim和username-claim返回到 API 服务器。API 服务器使用响应来验证对应的组或用户具有正确的权限。验证 ID 令牌中包含集群配置文件的
authentication.oidc部分中为group和user设置的声明。验证已应用的 RBAC 政策。
如需了解如何设置正确的 RBAC 政策，请参阅设置基于角色的访问控制 (RBAC)。
群组的 RBAC 无法用于 OIDC 提供方
验证 ID 令牌是否包含群组信息
在您运行
gcloud anthos auth login命令以启动 OIDC 身份验证流程后，ID 令牌会存储在kubeconfig文件的id-token字段中。使用 jwt.io 解码 ID 令牌并验证它是否按预期包含用户的群组信息。如果 ID 令牌没有用户的群组信息，请按照 OIDC 提供方的文档正确配置 OIDC 提供方以返回群组信息。例如，如果您使用的是 Okta 身份提供方的 OIDC 配置，请按照 Okta 身份提供方的文档配置 ID 令牌中的群组。
如果 ID 令牌有群组信息，请验证 ID 令牌中的群组信息键是否与
oidc部分下配置的groupsClaim字段匹配。例如，如果 ID 令牌在
groups键中包含群组信息："groups" : ["group1", "group2" ...]则
oidc部分中的groupsClaim字段的值应为groups。
排查身份提供方问题
如果您在集群中使用 OIDC 或 LDAP 时遇到问题，请按照本部分中的步骤排查这些问题，并确定身份提供方配置是否存在问题。
启用调试日志
为了帮助排查集群中与身份相关的问题，请为 ais Deployment 中的 Pod 启用调试日志。
使用
kubectl patch修补现有集群：kubectl patch deployment ais \ -n anthos-identity-service --type=json \ -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value":"--vmodule=cloud/identity/hybrid/charon/*=LOG_LEVEL"}]' \ --kubeconfig KUBECONFIG替换以下内容：
LOG_LEVEL：对于最详细的日志，请在排查问题时将此值设置为级别3。KUBECONFIG：用户集群 kubeconfig 文件的路径。
检查容器日志
查看容器日志的内容，了解是否有任何错误或警告。
如需查看日志，请使用
kubectl logs：kubectl logs -f -l k8s-app=ais \ -n anthos-identity-service \ --kubeconfig KUBECONFIG将
KUBECONFIG替换为用户集群 kubeconfig 文件的路径。
重启 Pod
如果容器日志显示问题，请重启 Pod。
如需重启 Pod，请删除现有 Pod。系统会自动创建新 Pod 作为替换项。
kubectl delete pod -l k8s-app=ais \ -n anthos-identity-service \ --kubeconfig KUBECONFIG将
KUBECONFIG替换为用户集群 kubeconfig 文件的路径。
排查与身份提供方的连接问题
如果 Pod 看起来运行正常，请测试与远程身份提供方的连接。
在同一命名空间中启动 busybox Pod：
kubectl run curl --image=radial/busyboxplus:curl \ -n anthos-identity-service -- sleep 3000 \ --kubeconfig KUBECONFIG将
KUBECONFIG替换为用户集群 kubeconfig 文件的路径。如需检查您是否可以提取发现网址，请进入 busybox Pod 并运行
curl命令：kubectl exec pod/curl -n anthos-identity-service -- \ curl ISSUER_URL \ --kubeconfig KUBECONFIG替换以下内容：
ISSUER_URL：您的身份提供方的颁发者网址。KUBECONFIG：用户集群 kubeconfig 文件的路径。
成功的响应是包含详细身份提供方端点的 JSON 结果。
如果上一个命令未返回预期的结果，请与您的身份提供方管理员联系，以获取额外的帮助。
LDAP 登录不适用于 Google Distributed Cloud 管理员集群
目前只有 Google Distributed Cloud 用户集群支持 LDAP。