이 문서는 GKE Identity Service용 클러스터를 이미 구성한 클러스터 관리자를 대상으로 합니다. 여기에서는 조직의 개발자와 기타 사용자를 위해 구성된 클러스터에 대한 사용자 액세스를 설정하고 관리하는 방법을 안내합니다.
클러스터에 대한 사용자 액세스를 설정하는 데 사용할 수 있는 인증 방법에는 두 가지 유형이 있습니다.
FQDN 액세스로 설정(권장): 이 방법을 사용하면 사용자는 클러스터의 Kubernetes API 서버의 정규화된 도메인 이름(FQDN)을 사용하여 GKE Identity Service 서버에 직접 인증할 수 있습니다. 자세한 내용은 FQDN 액세스 설정을 참조하세요.
파일 기반 액세스로 설정: 이 방법을 사용하면 로그인 구성 파일을 생성하여 클러스터 사용자에게 배포할 수 있습니다. 그러면 사용자는 이 파일을 사용하여 gcloud 인증 명령어로 구성된 클러스터에 로그인할 수 있습니다. 자세한 내용은 파일 기반 액세스 설정을 참조하세요.
FQDN 액세스 설정(권장)
이 섹션에서는 사용자에게 인증에 사용할 서버의 URL(FQDN)을 제공하여 사용자 로그인 액세스를 설정하는 방법을 설명합니다. 인증 흐름을 통해 사용자는 IdP로 로그인할 수 있으며 클러스터에 액세스할 수 있도록 kubeconfig 파일에 추가된 토큰이 사용자에게 제공됩니다.
이 인증 방법은 버전 1.29부터 VMware 및 베어메탈용 온프레미스 클러스터(Google Distributed Cloud)에서만 지원됩니다.
다른 클러스터 유형은 지원되지 않습니다. 지원되는 이전 소프트웨어 버전을 사용하여 온프레미스 클러스터나 다른 클러스터 유형에 대한 인증을 설정해야 하는 경우 안내를 따라 파일 기반 액세스를 설정합니다.
사용자에게 FQDN을 공유하기 전에 개발자나 개발자 플랫폼 관리자가 FQDN의 DNS 설정, ID 공급업체 등록의 일부로 FQDN 제공(필요한 경우)을 포함한 적절한 설정을 따랐는지 확인합니다.
사용자와 FQDN 공유
클러스터 관리자는 구성 파일 대신 클러스터의 Kubernetes API 서버의 FQDN을 사용자와 공유할 수 있습니다. 사용자는 이 FQDN을 사용하여 클러스터에 로그인할 수 있습니다. 로그인의 URL 형식은 APISERVER-URL이며 여기서 URL에는 API 서버의 FQDN이 포함됩니다.
APISERVER-URL 형식 예시는 https://apiserver.company.com입니다.
ID 서비스 옵션 구성
이 설정 옵션을 사용하면 토큰 전체 기간을 구성할 수 있습니다. ClientConfig CR의 IdentityServiceOptions에는 토큰 수명(분)을 구성할 수 있는 sessionDuration 파라미터가 있습니다.
sessionDuration 파라미터 하한은 15분이고 최대 한도는 1,440분(24시간)입니다.
ClientConfig CR에서 표시되는 항목에 대한 예시는 다음과 같습니다.
spec:
IdentityServiceOptions:
sessionDuration: INT
여기서 INT는 세션 시간(분)입니다.
파일 기반 액세스 설정
클러스터 관리자는 FQDN 액세스의 대안으로 로그인 구성 파일을 생성하여 클러스터 사용자에게 배포할 수 있습니다. FQDN 액세스를 지원하지 않는 버전이나 유형으로 클러스터에 대한 인증을 설정하는 경우에 이 옵션을 사용할 수 있습니다. 이 파일을 사용하면 사용자가 선택한 제공업체를 통해 명령줄에서 클러스터에 액세스할 수 있습니다. 이 인증 방법은 OIDC 및 LDAP 제공업체에만 지원됩니다.
액세스 가능한 URL에서 파일을 호스팅합니다. Google Cloud CLI로 파일을 가져올 수 있도록 gcloud anthos auth login을 실행할 때 --login-config 플래그로 이 위치를 지정할 수 있습니다.
보안 호스트에 파일을 호스팅하는 것이 좋습니다. 보안 HTTPS 액세스에 PEM 인증서를 사용하는 방법에 대한 자세한 내용은 gcloud CLI의 --login-config-cert 플래그를 참조하세요.
로컬 머신에 저장할 위치 정보와 함께 각 사용자에게 파일을 수동으로 제공합니다. 이러한 위치 정보는 Google Cloud CLI가 OS별 기본 위치에서 파일을 찾기 위해 필요합니다. 파일에 기본값이 아닌 이름 또는 위치가 있는 경우 클러스터에 대해 명령어를 실행할 때 사용자가 --login-config 플래그를 사용하여 구성 파일 위치를 지정해야 합니다. 파일 저장 안내는 GKE Identity Service로 클러스터에 액세스를 참조하세요.
내부 도구를 사용하여 인증 구성 파일을 각 사용자 머신으로 푸시합니다. Google Cloud CLI는 사용자 OS에 따라 다음 위치에서 파일을 찾습니다.
[[["이해하기 쉬움","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-01-14(UTC)"],[],[],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 ```"]]
