本文档提供有关排查 GKE Identity Service 中的 OIDC 和 AzureAD 身份提供方问题的指导。
证书格式不正确
当证书值有格式错误时，就会出现此问题。格式问题可能对应于非 base64 编码的证书值和以 base64 编码但不正确的值。如果证书并非由根证书授权机构签名，或者未提供格式正确的信任链，则可能会出现此问题。
错误消息
以下是证书格式不正确时的错误消息示例：
非 base64 编码的证书：
Failed creating HTTP client to fetch the Discovery URI "<Discovery-document URI>" with error: Unable to decode data field, the value should be Base64 encoded证书格式不正确或采用 base64 编码但值不正确：
Unable to connect to 'https://example.com', encountered the following error: Problem with the SSL CA cert (path? access rights?). Details: error setting certificate verify locations: CAfile: /tmp/example.pem CApath: none (The certificate could not be read, this is most likely because it's empty or contains a formatting error. Please check your configuration.)证书格式不正确或采用 base64 编码但值不正确：
Failed fetching the Discovery URI "<Discovery-document URI>" with error: Unable to load TLS certificates.
解决方案
您可以通过以下方式之一解决这些问题：
- 您在 ClientConfig 中提供的证书值应该是 base64 编码的字符串和 PEM 格式的字符串。如需了解详情，请参阅对 CA 证书进行编码。
- 如果您的提供方未使用由根证书授权机构签名的证书，则您需要使用证书信任链配置 GKE Identity Service。如需了解详情，请参阅中间证书。
证书值错误
当证书的值不匹配时，会出现此问题。在这种情况下，证书的格式正确，但它们与服务器不匹配。此问题也可能表示配置中没有证书。
在以下情况下，证书值可能会被视为不正确：
- ClientConfig 中共享了不正确的证书值。如果服务器证书的
issuer与已配置证书的subject不匹配，则证书值不正确。 - ClientConfig 中的证书不是 base64 编码的字符串。
- 使用中间证书颁发服务器证书时，未提供证书链。
错误消息
以下是证书值不匹配时的错误消息示例：
证书链不完整或与服务器不匹配：
SSL peer certificate was not OK. Details: SSL certificate problem: unable to get local issuer certificate证书链不完整（对应于不是从根开始或不连续的无效部分链）：
Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.证书链有效，但与 OIDC 服务器不匹配：
AIS was expecting the server to have a different certificate证书链有效，但与 OIDC 服务器不匹配：
Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.
解决方案
您在 ClientConfig 中提供的证书值需要包含与身份提供方匹配的格式正确的证书链。如需详细了解如何设置证书格式和编码，请参阅对 CA 证书进行编码。
使用由 gcloud anthos auth login 命令生成的 kubeconfig 文件时，kubectl 命令失败
在 Windows 机器上将 gcloud anthos auth login 命令与 OIDC 搭配使用来生成 kubeconfig 文件以用于集群访问时，kubectl 命令可能会失败，并显示以下错误消息：The command line is too long.
此问题专门在 Windows 系统上发生，不会影响使用同一 kubeconfig 文件的 Linux 机器。根本原因与用户属于大量群组（大约 70 到 200 个群组，具体取决于群组名称的长度）时，Azure Active Directory (Azure AD) 所生成的身份验证令牌的大小有关。
此大型令牌会导致 kubectl 命令的执行失败，因为它超出了 Windows 允许的命令行长度上限（8,191 个字符）。
错误消息
$ kubectl --kubeconfig test-kubeconfig.yml get nodes The command line is too long. The command line is too long. E0102 11:02:29.115256 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1 The command line is too long. E0102 11:02:29.350238 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1 The command line is too long. E0102 11:02:30.062811 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1 Unable to connect to the server: getting credentials: exec: executable gcloud failed with exit code 1
解决方案
如需解决此问题，请执行以下操作：
升级到 GKE 集群 1.28 版或更高版本
如果您运行的 GKE 集群版本低于 1.28，建议您升级到受支持的版本。
减少受影响用户的群组成员资格
将进行身份验证的用户所属的群组数量减少到有问题的阈值（大约 70 个群组）以下，即可解决此问题。
增加受影响用户的群组成员资格
Microsoft Entra ID 功能会限制令牌中发出的群组数量。介于 70 到 200 之间的群组成员资格数量可能会导致身份验证问题。不过，您可以通过将群组成员资格数量增加到超出此限制来解决身份提供方问题。由于此限制的行为，当成员资格数量过大时，Azure AD 会在
id_token中省略群组，以防止命令行过长，因而可解决身份提供方问题。请查看 Microsoft Entra ID 文档，以确认限制并了解更多详情。