이 문서에서는 GKE Identity Service의 OIDC 및 AzureAD ID 공급업체 문제를 해결하는 방법을 안내합니다.
잘못된 인증서 형식
이 문제는 인증서 값에 형식 오류가 있는 경우 발생합니다. 형식 문제는 인증서 값이 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 ID 서비스를 구성해야 합니다. 자세한 내용은 중간 인증서를 참조하세요.
잘못된 인증서 값
이 문제는 인증서에 일치하지 않는 값이 있는 경우 발생합니다. 이 경우 인증서의 형식은 올바르지만 서버와 일치하지 않습니다. 구성에 인증서가 없는 경우일 수도 있습니다.
다음 시나리오에 하나라도 해당하면 인증서 값이 잘못된 것으로 간주될 수 있습니다.
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에 제공하는 인증서 값은 ID 공급업체와 일치하는 올바른 형식의 인증서 체인을 포함해야 합니다.
인증서 형식을 지정하고 인코딩하는 방법에 관한 자세한 내용은 CA 인증서 인코딩을 참조하세요.
gcloud anthos auth login 명령어로 생성된 kubeconfig 파일을 사용하면 kubectl 명령어가 실패함
Windows 머신에서 OIDC와 함께 gcloud anthos auth login 명령어를 사용하여 클러스터 액세스를 위한 kubeconfig 파일을 생성하면 kubectl 명령어가 다음 오류 메시지와 함께 실패할 수 있습니다. The command line is too long. 이 문제는 특히 Windows 시스템에서 발생하며 동일한 kubeconfig 파일을 사용하는 Linux 머신에는 영향을 미치지 않습니다. 근본 원인은 사용자가 다수의 그룹(그룹 이름 길이에 따라 약 70~200개 그룹)에 속해 있을 때 Azure Active Directory(Azure AD)에서 생성하는 인증 토큰의 크기와 관련이 있습니다.
이 큰 토큰은 Windows에서 허용하는 명령줄의 최대 길이인 8,191자를 초과하므로 kubectl 명령어 실행에 실패합니다.
오류 메시지
$ 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 이상으로 업그레이드
1.28 이전 버전의 GKE 클러스터를 실행하는 경우 지원되는 버전으로 업그레이드하는 것이 좋습니다.
영향을 받는 사용자의 그룹 멤버십 줄이기
인증하는 사용자가 속한 그룹 수를 문제가 되는 기준점(약 70개 그룹) 미만으로 줄이면 이 문제가 해결될 수 있습니다.
영향을 받는 사용자의 그룹 멤버십 늘리기
Microsoft Entra ID 기능에는 토큰에 포함할 수 있는 그룹 수에 제한이 있습니다. 그룹 멤버십이 70~200개 있으면 인증 문제가 발생할 수 있습니다. 하지만 이 한도를 초과하여 그룹 멤버십 수를 늘리면 ID 공급업체 문제를 해결할 수 있습니다. 이 제한의 동작으로 인해 Azure AD는 멤버십 수가 지나치게 많아지면 id_token에서 그룹을 생략하여 명령줄이 너무 길어지는 것을 방지하고 ID 공급업체 문제를 해결합니다. 한도 및 자세한 내용은 Microsoft Entra ID 문서를 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-31(UTC)"],[],[],null,["# Troubleshoot OIDC provider issues\n=================================\n\nThis document provides troubleshooting guidance for OIDC and AzureAD identity provider issues\nin GKE Identity Service.\n\nIncorrect formatting of certificate\n-----------------------------------\n\nThis issue occurs when the certificate value has formatting errors. Formatting\nissues can correspond to certificate values that aren't base64 encoded and values\nthat are base64 encoded but incorrect. The issue can also arise if the certificate\nisn't signed by a root certificate authority or a correctly formatted trust chain isn't provided.\n\n### Error messages\n\nThe following examples are of error messages for scenarios where the certificate format is incorrect:\n\n- Certificate that is not base64 encoded:\n `Failed creating HTTP client to fetch the Discovery URI \"\u003cDiscovery-document URI\u003e\" with error: Unable to decode data field, the value should be Base64 encoded`\n\n- Certificate that is not formatted correctly or is base64 encoded but incorrect:\n `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.)`\n\n- Certificate that is not formatted correctly or is base64 encoded but incorrect:\n `Failed fetching the Discovery URI \"\u003cDiscovery-document URI\u003e\" with error: Unable to load TLS certificates.`\n\n### Solution\n\nYou can resolve the issues in one of the following ways:\n\n- The certificate value you provide in the ClientConfig should be a base64 encoded string and PEM formatted string. For more information, see [Encode CA certificates](/kubernetes-engine/enterprise/identity/setup/format-certificates#encodecertificate).\n- If your provider doesn't use certificates signed by a root certificate authority, then you need to configure GKE Identity Service with a certificate trust chain. For more information, see [Intermediate certificates](/kubernetes-engine/enterprise/identity/setup/format-certificates#intermediatecertificates).\n\nWrong certificate value\n-----------------------\n\nThis issue occurs when the certificate has a mismatched value. In this case, the formatting of the certificates is correct, however they don't match the server. It can also indicate that there were no certificates in the configuration.\n\nA certificate value can be considered incorrect in any of the following scenarios:\n\n- An incorrect certificate value is shared in the ClientConfig. A certificate value is incorrect when the `issuer` of the server certificate does not match the `subject` of the configured certificate.\n- The certificate in the ClientConfig isn't a base64 encoded string.\n- The certificate chain is not provided when intermediate certificates are used to issue the server certificate.\n\n### Error message\n\nThe following examples are of error messages for scenarios where there's a mismatch in the certificate value:\n\n- Certificate chain is not complete or does not match the server:\n `SSL peer certificate was not OK. Details: SSL certificate problem: unable to get local issuer certificate`\n\n- Certificate chain is not complete (corresponds to an invalid partial chain which doesn't start at the root or isn't contiguous):\n `Failed fetching the Discovery URI \"\u003cDiscovery-document URI\u003e\" with error: The server's TLS certificate did not match expectations.`\n\n- Certificate chain is valid but doesn't match the OIDC server:\n `AIS was expecting the server to have a different certificate`\n\n- Certificate chain is valid but doesn't match the OIDC server:\n `Failed fetching the Discovery URI \"\u003cDiscovery-document URI\u003e\" with error: The server's TLS certificate did not match expectations.`\n\n### Solution\n\nThe certificate value you provide in the ClientConfig needs to include a correctly formatted certificate chain that matches the identity provider.\nFor more information on how to format and encode certificates, see [Encode CA certificates](/kubernetes-engine/enterprise/identity/setup/format-certificates#encodecertificate).\n\n`kubectl` commands fail when using a kubeconfig file generated by the `gcloud anthos auth login` command\n--------------------------------------------------------------------------------------------------------\n\nWhen you use the `gcloud anthos auth login` command with OIDC on Windows machines to generate a kubeconfig file for cluster access, `kubectl` commands might fail with the following error message: **`The command line is too long.`**\nThis issue occurs specifically on Windows systems and does not affect Linux machines that use the same kubeconfig file. The underlying cause is related to the size of the authentication token that's generated by Azure Active Directory (Azure AD) when a user belongs to a large number of groups (approximately 70 to 200 groups, depending on the lengths of group names).\n\nThis large token causes the execution of `kubectl` commands to fail because it exceeds the maximum length of the command line that's allowed by Windows, which is *8,191* characters.\n\n### Error message\n\n```\n$ kubectl --kubeconfig test-kubeconfig.yml get nodes\n\nThe command line is too long.\nThe command line is too long.\nE0102 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\nThe command line is too long.\nE0102 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\nThe command line is too long.\nE0102 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\nUnable to connect to the server: getting credentials: exec: executable gcloud failed with exit code 1\n```\n\n### Solution\n\nTo resolve this issue, do the following:\n\n- **Upgrade to GKE cluster version 1.28 or later**\n\n If you're running a version of GKE cluster that is earlier than 1.28, we recommend that you upgrade to the supported version.\n- **Reduce the affected user's group memberships**\n\n Reducing the number of groups the authenticating user belongs to below the problematic threshold (approximately 70 groups) can resolve the issue.\n- **Increase the affected user's group memberships**\n\n The [Microsoft Entra ID feature has a limit](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims) for the number of groups emitted in a token. Having between 70 to 200 group memberships might cause authentication problems. However, you can resolve the identity provider issues by increasing the number of group memberships beyond this limit. Due to the behavior of this limit, Azure AD omits groups from the `id_token` when the number of memberships becomes excessively large, preventing the command line from becoming too long and so resolving the identity provider issues. Review the [Microsoft Entra ID documentation](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-group-claims) to confirm the limit and for more details."]]
