failed to get clientconfig default in namespace kube-public
솔루션
이 문제를 해결하려면 다음 단계를 따르세요.
클러스터에 올바른 kubeconfig 파일이 있는지 확인합니다.
ClientConfig 커스텀 리소스가 클러스터에 있는지 확인하려면 다음 명령어를 실행합니다.
kubectl --kubeconfig KUBECONFIG get clientconfig default -n kube-public
ClientConfig가 클러스터에 없는 경우 클러스터에 GKE Identity Service를 설치하고 구성합니다. 클러스터 설정 옵션에 대한 자세한 내용은 클러스터 설정 옵션을 참조하세요.
중복 클러스터 이름으로 인해 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 정책이 잘못되었거나 사용자에 대한 RBAC 정책이 없습니다.
오류 메시지
Unauthorized
솔루션
이 문제를 해결하려면 다음 단계를 따르세요.
로그인에 사용된 구성을 확인합니다.
OIDC 구성
사용자 클러스터 구성 파일의 authentication.oidc 섹션에는 Kubernetes API 서버에서 --oidc-group-claim 플래그와 --oidc-username-claim 플래그를 설정하는 데 사용되는 group 필드와 username 필드가 있습니다. API 서버에 사용자 ID 토큰이 있으면 토큰을 GKE Identity Service로 전달합니다. 그러면 GKE Identity Service는 추출된 group-claim 및 username-claim을 다시 API 서버로 반환합니다. API 서버에서는 응답을 사용하여 해당 그룹이나 사용자에게 올바른 권한이 있는지 확인합니다.
클러스터 구성 파일의 authentication.oidc 섹션에서 group 및 user에 설정된 클레임이 ID 토큰에 있는지 확인합니다.
gcloud anthos auth login 명령어를 실행하여 OIDC 인증 흐름을 시작하면 ID 토큰이 id-token 필드의 kubeconfig 파일에 저장됩니다. jwt.io를 사용하여 ID 토큰을 디코딩하고 예상대로 사용자의 그룹 정보가 포함되어 있는지 확인합니다.
ID 토큰에 사용자의 그룹 정보가 없으면 OIDC 제공업체의 문서에 따라 그룹 정보를 반환하도록 OIDC 제공업체를 올바르게 구성합니다. 예를 들어 Okta ID 공급업체의 OIDC 구성을 사용하는 경우 Okta ID 공급업체의 문서에 따라 ID 토큰의 그룹을 구성합니다.
ID 토큰에 그룹 정보가 있으면 ID 토큰의 그룹 정보 키가 oidc 섹션에서 구성된 groupsClaim 필드와 일치하는지 확인합니다.
[[["이해하기 쉬움","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-09-01(UTC)"],[],[],null,["# Troubleshoot user access issues\n===============================\n\nThis document provides troubleshooting guidance for user access issues\nin GKE Identity Service.\n\n`gcloud anthos create-login-config` fails to get clientconfig\n-------------------------------------------------------------\n\nThis issue occurs in one of the following cases:\n\n- The kubeconfig file passed to `gcloud anthos create-login-config` is incorrect.\n- The ClientConfig custom resource is not present in the cluster (GKE Identity Service is not installed on the cluster).\n\n### Error message\n\n\u003cbr /\u003e\n\n```\n failed to get clientconfig default in namespace kube-public\n \n```\n\n\u003cbr /\u003e\n\n### Solution\n\nTo resolve this issue, do the following:\n\n1. Make sure you have the correct kubeconfig file for your cluster.\n2. To verify if the ClientConfig custom resource is in the cluster, run the following command:\n\n ```\n kubectl --kubeconfig KUBECONFIG get clientconfig default -n kube-public\n ```\n\n If the ClientConfig is not present in the cluster, then install and configure\n GKE Identity Service on the cluster. For more information on cluster\n setup options, see [Setup options for clusters](/kubernetes-engine/enterprise/identity#setup_options).\n\n`gcloud anthos create-login-config` fails because of duplicate cluster name\n---------------------------------------------------------------------------\n\nThis issue occurs if you attempt to create login configuration for a cluster\ninto a file that already contains a login configuration for this cluster.\n\n### Error message\n\n\u003cbr /\u003e\n\n```\n error merging with file FILENAME because FILENAME contains a\n cluster with the same name as the one read from KUBECONFIG.\n \n```\n\n\u003cbr /\u003e\n\n### Solution\n\nTo resolve this issue, use the `--output` flag to specify a new destination file.\n\nIf you do not provide `--output`, this login configuration data is written to a\nfile named `kubectl-anthos-config.yaml` in the current directory.\n\n`gcloud anthos auth login` fails with `proxyconnect tcp`\n--------------------------------------------------------\n\nThis issue occurs when there is an error in the `https_proxy` or `HTTPS_PROXY`\nenvironment variable configurations. If there's an `https://` specified in the\nenvironment variables, then the GoLang HTTP client libraries might fail if the\nproxy is configured to handle HTTPS connections using other protocols such as\nSOCK5.\n\n### Error message\n\n\u003cbr /\u003e\n\n```\n proxyconnect tcp: tls: first record does not look like a TLS handshake\n \n```\n\n\u003cbr /\u003e\n\n### Solution\n\nTo resolve this issue, modify the `https_proxy` and `HTTPS_PROXY` environment\nvariables to omit the `https:// prefix`. On Windows, modify the system\nenvironment variables.\nFor example, change the value of the `https_proxy`\nenvironment variable from `https://webproxy.example.com:8000` to\n`webproxy.example.com:8000`.\n\nCluster access fails when using kubeconfig generated by `gcloud anthos auth login`\n----------------------------------------------------------------------------------\n\nThis issue occurs when the Kubernetes API server is unable to authorize the\nuser for one of the following reasons:\n\n- There is an error in the configuration used to login with the `gcloud anthos auth login` command.\n- The necessary RBAC policies are incorrect or missing for the user.\n\n### Error message\n\n\u003cbr /\u003e\n\n```\n Unauthorized\n \n```\n\n\u003cbr /\u003e\n\n### Solution\n\nTo resolve this issue, do the following:\n\n1. Verify configuration used to login.\n\n **OIDC configuration**\n\n The `authentication.oidc` section in the user cluster configuration file has\n `group` and `username` fields that are used to set the `--oidc-group-claim`\n and `--oidc-username-claim` flags in the Kubernetes API server. When the API\n server is presented with a user's identity token, it forwards the token to\n GKE Identity Service, which returns the extracted `group-claim` and\n `username-claim` back to the API server. The API server uses the response to\n verify that the corresponding group or user has the correct permissions.\n\n Verify that the claims set for `group` and `user` in the `authentication.oidc`\n section of the cluster configuration file are present in the ID token.\n2. Verify applied RBAC policies.\n\n To learn how to set up the correct RBAC policies for\n GKE Identity Service, see [Set up role-based access control (RBAC)](/kubernetes-engine/enterprise/identity/setup/user-access#optional_set_up_role-based_access_control_rbac).\n\nRBACs for groups not working for OIDC providers\n-----------------------------------------------\n\n| **Note:** The following troubleshooting instructions are applicable only if your provider is configured under the `oidc` section in the ClientConfig custom resource and the `enableAccessToken` field is set to `false`.\n\n1. Verify if the ID token has the group information\n\n After you run `gcloud anthos auth login` command to initiate the [OIDC authentication flow](https://cloud.google.com/kubernetes-engine/enterprise/identity/accessing#plugin_to_authenticate), the ID Token is stored in the `kubeconfig` file in the `id-token` field. Use [jwt.io](https://jwt.io) to decode the ID token and verify if it contains the group information of the user as expected.\n2. If ID token does not have group information of the user, then correctly configure the OIDC provider to return the group information as per the documentation of your OIDC provider. For example, if you're using OIDC configuration of the Okta Identity provider, then follow the documentation of the Okta Identity provider to configure groups in the ID token.\n\n3. If the ID token has group information, then verify if the group information key in the ID token matches the `groupsClaim` field configured under the `oidc` section.\n\n For example, if the ID token contains group information in the `groups` key: \n\n \"groups\" : [\"group1\", \"group2\" ...]\n\n then the value of the `groupsClaim` field should be `groups` in the `oidc` section.\n\n After modifying the configuration in the `oidc` section, make sure you run the instructions listed in [Set up user access](https://cloud.google.com/kubernetes-engine/enterprise/identity/setup/user-access) and [Accessing clusters](https://cloud.google.com/kubernetes-engine/enterprise/identity/accessing) again.\n\nTroubleshoot identity providers\n-------------------------------\n\nIf you have problems using OIDC or LDAP with your GKE cluster, follow the\nsteps in this section to troubleshoot GKE Identity Service and help\ndetermine if there's an issue with your identity provider configuration.\n\n### Enable the GKE Identity Service debug log\n\nTo help troubleshoot identity-related issues in your cluster, enable the\nGKE Identity Service debug log.\n\n1. Patch your existing cluster with `kubectl patch`:\n\n kubectl patch deployment ais \\\n -n anthos-identity-service --type=json \\\n -p='[{\"op\": \"add\", \"path\": \"/spec/template/spec/containers/0/args/-\", \"value\":\"--vmodule=cloud/identity/hybrid/charon/*=\u003cvar translate=\"no\"\u003eLOG_LEVEL\u003c/var\u003e\"}]' \\\n --kubeconfig \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eLOG_LEVEL\u003c/var\u003e: For the most verbose logs, set this value\n to level `3` when troubleshooting.\n\n | **Note:** This value can be set higher to `9`, however at this level it might reveal some credential information in your console.\n - \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e: The path to your user cluster kubeconfig\n file.\n\n### Check the GKE Identity Service container log\n\nReview the content of the GKE Identity Service container logs for any\nerrors or warnings.\n\n1. To review the logs, use `kubectl logs`:\n\n kubectl logs -f -l k8s-app=ais \\\n -n anthos-identity-service \\\n --kubeconfig \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e with the path to your user cluster\n kubeconfig file.\n\n### Restart the GKE Identity Service pod\n\nIf the container logs show problems, restart the GKE Identity Service pod.\n\n1. To restart the GKE Identity Service pod, delete the existing pod. A new\n pod is automatically created as a replacement.\n\n kubectl delete pod -l k8s-app=ais \\\n -n anthos-identity-service \\\n --kubeconfig \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e with the path to your user cluster\n kubeconfig file.\n\n### Troubleshoot connectivity to identity provider\n\nIf the GKE Identity Service pod looks to be running correctly, test the\nconnectivity to the remote identity provider.\n\n1. Start a busybox pod in the same namespace as the GKE Identity Service\n pod:\n\n kubectl run curl --image=radial/busyboxplus:curl \\\n -n anthos-identity-service -- sleep 3000 \\\n --kubeconfig \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e with the path to your user cluster\n kubeconfig file.\n2. To check if you can fetch the discovery URL, execute into the busybox pod and\n run the `curl` command:\n\n kubectl exec pod/curl -n anthos-identity-service -- \\\n curl \u003cvar translate=\"no\"\u003eISSUER_URL\u003c/var\u003e \\\n --kubeconfig \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eISSUER_URL\u003c/var\u003e: The issuer URL of your identity provider.\n - \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e: The path to your user cluster kubeconfig file.\n\n A successful response is a JSON result with the detailed identity provider\n endpoints.\n3. If the previous command doesn't return the expected result, contact your\n identity provider administrator for additional assistance.\n\nLDAP login not working for Google Distributed Cloud admin cluster\n-----------------------------------------------------------------\n\nLDAP is currently only supported for Google Distributed Cloud user cluster."]]
