If the ClientConfig is not present in the cluster, then install and configure
GKE Identity Service on the cluster. For more information on cluster
setup options, seeSetup options for clusters.
gcloud anthos create-login-configfails because of duplicate cluster name
This issue occurs if you attempt to create login configuration for a cluster
into a file that already contains a login configuration for this cluster.
Error message
error merging with fileFILENAMEbecauseFILENAMEcontains a
cluster with the same name as the one read fromKUBECONFIG.
Solution
To resolve this issue, use the--outputflag to specify a new destination file.
If you do not provide--output, this login configuration data is written to a
file namedkubectl-anthos-config.yamlin the current directory.
This issue occurs when there is an error in thehttps_proxyorHTTPS_PROXYenvironment variable configurations. If there's anhttps://specified in the
environment variables, then the GoLang HTTP client libraries might fail if the
proxy is configured to handle HTTPS connections using other protocols such as
SOCK5.
Error message
proxyconnect tcp: tls: first record does not look like a TLS handshake
Solution
To resolve this issue, modify thehttps_proxyandHTTPS_PROXYenvironment
variables to omit thehttps:// prefix. On Windows, modify the system
environment variables.
For example, change the value of thehttps_proxyenvironment variable fromhttps://webproxy.example.com:8000towebproxy.example.com:8000.
Cluster access fails when using kubeconfig generated bygcloud anthos auth login
This issue occurs when the Kubernetes API server is unable to authorize the
user for one of the following reasons:
There is an error in the configuration used to login with thegcloud anthos auth logincommand.
The necessary RBAC policies are incorrect or missing for the user.
Error message
Unauthorized
Solution
To resolve this issue, do the following:
Verify configuration used to login.
OIDC configuration
Theauthentication.oidcsection in the user cluster configuration file hasgroupandusernamefields that are used to set the--oidc-group-claimand--oidc-username-claimflags in the Kubernetes API server. When the API
server is presented with a user's identity token, it forwards the token to
GKE Identity Service, which returns the extractedgroup-claimandusername-claimback to the API server. The API server uses the response to
verify that the corresponding group or user has the correct permissions.
Verify that the claims set forgroupanduserin theauthentication.oidcsection of the cluster configuration file are present in the ID token.
After you rungcloud anthos auth logincommand to initiate theOIDC authentication flow, the ID Token is stored in thekubeconfigfile in theid-tokenfield. Usejwt.ioto decode the ID token and verify if it contains the group information of the user as expected.
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.
If the ID token has group information, then verify if the group information key in the ID token matches thegroupsClaimfield configured under theoidcsection.
For example, if the ID token contains group information in thegroupskey:
"groups" : ["group1", "group2" ...]
then the value of thegroupsClaimfield should begroupsin theoidcsection.
If you have problems using OIDC or LDAP with your GKE cluster, follow the
steps in this section to troubleshoot GKE Identity Service and help
determine if there's an issue with your identity provider configuration.
Enable the GKE Identity Service debug log
To help troubleshoot identity-related issues in your cluster, enable the
GKE Identity Service debug log.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 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."]]
