[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-07-31。"],[],[],null,["# Set up an authentication method for user access\n===============================================\n\nThis document is for **cluster administrators** who have already configured their\nclusters for GKE Identity Service. It provides instructions on how to set\nup and manage user access to these configured clusters for your organization's\ndevelopers and other users.\n\nThere are two types of authentication methods you can use to set up user access\nto your clusters:\n\n- Set up with FQDN access (Recommended): With this approach, users can directly authenticate to the GKE Identity Service server using the fully qualified domain name (FQDN) of the cluster's Kubernetes API server. For more information, see [Set up FQDN access](#fqdn-access).\n- Set up with file-based access: With this approach, you generate a login configuration file and distribute it to cluster users. Users can then sign in to configured clusters with `gcloud` authentication commands using this file. For more information, see [Set up file-based access](#file-access).\n\nSet up FQDN access (Recommended)\n--------------------------------\n\n| **Note:** If you experience any issues with this setup and your cluster is running GKE Enterprise 1.31 or higher, consider using the [diagnostic utility](/kubernetes-engine/enterprise/identity/setup/anthos-v2-diagnostic-utility) to assist with troubleshooting.\n\nThis section tells you how to set up user login access by providing the user with\nthe URL (FQDN) for a server to use for authentication. The authentication flow\nlets the user sign in with their IdP and provides the user with a token that is\nadded to their kubeconfig file for accessing the cluster.\nThis authentication approach is supported only for on-premises clusters\n(Google Distributed Cloud) on VMware and bare metal, from version 1.29 onwards.\nOther cluster types are not supported. If you need to set up authentication for\non-premises clusters using an older supported software version, or for other\ncluster types, follow the instructions to [set up file-based access](#file-access).\n\nBefore sharing the FQDN to users, ensure that you or your platform administrator\nhave followed the appropriate [setup](/kubernetes-engine/enterprise/identity/setup/idp-overview#beforeyoubegin), including DNS setup for the FQDN and providing the FQDN as part of registering to your identity provider if required.\n\n### Share FQDN with users\n\nInstead of a configuration file, *cluster administrators* can share the FQDN of\nthe cluster's Kubernetes API server, such as `https://apiserver.example.com`,\nwith users. Users can use this FQDN to sign in to the cluster.\n\n### Configure Identity Service options\n\nWith this set up option, you can configure the token\nlifetime duration. The `identityServiceOptions` in the ClientConfig CR has a\n`sessionDuration` parameter that lets you configure the token lifetime (in minutes).\nThe `sessionDuration` parameter has a lower limit of 15 minutes and a maximum\nlimit of 1440 minutes (24 hours).\n\nHere's an example of what it looks like in the ClientConfig CR: \n\n spec:\n identityServiceOptions:\n sessionDuration: \u003cvar translate=\"no\"\u003eINT\u003c/var\u003e\n\nwhere \u003cvar translate=\"no\"\u003eINT\u003c/var\u003e is the session duration in minutes.\n\nSet up file-based access\n------------------------\n\nAs an alternative to FQDN access, cluster administrators can generate a login\nconfiguration file and distribute it to cluster users. You may want to use this\noption if you are setting up authentication to a cluster with a version or type\nthat does not support [FQDN access](#fqdn-access). This file lets users access\nclusters from the command line with the chosen provider. This authentication\napproach is supported for OIDC and LDAP providers only.\n\n### Generate the login config\n\n### Console\n\n([Fleet-level setup](/kubernetes-engine/enterprise/identity/setup/fleet) only)\n\nCopy the displayed `gcloud` command and run it to generate the file.\n\n### gcloud\n\nIf you configured the cluster using `gcloud` CLI or if you need to generate the\nfile again, run the following command to generate the file: \n\n```bash\ngcloud anthos create-login-config --kubeconfig=KUBECONFIG\n```\n\nwhere \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e is the path to the kubeconfig file for the cluster. If there are multiple contexts in the kubeconfig, the current context is used. You may need to reset the current context to the correct cluster before running the command.\n\nYou can see complete reference details for this command, including additional optional parameters, in the [Google Cloud CLI reference guide](/sdk/gcloud/reference/anthos/create-login-config).\n\nThe default name for the login config file is `kubectl-anthos-config.yaml`, which is the name the Google Cloud CLI expects when using the file to sign in. If you want to change this to a non-default name, see the relevant section in [Distribute the login config](/kubernetes-engine/enterprise/identity/setup/fleet-cluster#distribute_the_login_config).\n\nFor troubleshooting information related to user access, see [Troubleshoot user access issues](/kubernetes-engine/enterprise/identity/setup/user-access-troubleshooting).\n\nDistribute the login config\n---------------------------\n\nThe following are some ways to distribute the config file:\n\n- Host the file at an accessible URL. Users can specify this location with the `--login-config`\n flag when running `gcloud anthos auth login`, allowing the Google Cloud CLI to get the file.\n\n Consider hosting the file on a secure host. See the\n [`--login-config-cert`](/kubernetes-engine/enterprise/identity/accessing#plugin_to_authenticate) flag of the gcloud CLI for\n more information about using PEM certificates for secure HTTPS access.\n- Manually provide the file to each user, with information on where to save it\n on their local machine---the Google Cloud CLI expects to find the file in an\n OS-specific default location. If the file has a non-default name or location, your users must use the `--login-config`\n flag to specify the config file location when running commands against the\n cluster. Instructions for users to save the file are in [Access clusters with GKE Identity Service](/kubernetes-engine/enterprise/identity/accessing).\n\n- Use your internal tools to push the authentication configuration file onto\n each user's machine. The Google Cloud CLI expects to find the file in the\n following locations, depending on the user OS:\n\n ### Linux\n\n ```\n $HOME/.config/google/anthos/kubectl-anthos-config.yaml\n ```\n\n ### macOS\n\n ```\n $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml\n ```\n\n ### Windows\n\n ```\n %APPDATA%\\google\\anthos\\kubectl-anthos-config.yaml\n ```"]]
