Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Login menggunakan nama domain yang sepenuhnya memenuhi syarat (FQDN)
GKE Identity Service memungkinkan Anda login ke cluster yang dikonfigurasi dari command line menggunakan nama pengguna dan sandi dari penyedia identitas pihak ketiga. Ikuti petunjuk di halaman ini jika administrator cluster Anda telah memilih untuk mengizinkan Anda mengautentikasi langsung di server Identity Service GKE dengan nama domain yang sepenuhnya memenuhi syarat (FQDN).
Untuk penyedia SAML, akses login hanya didukung melalui pendekatan autentikasi
ini.
Pendekatan autentikasi ini hanya didukung untuk cluster on-prem (Google Distributed Cloud) di VMware dan bare metal, mulai versi 1.29. Jenis cluster lainnya tidak didukung.
Versi CLI gcloud yang diperlukan untuk login dengan FQDN yang Anda berikan setidaknya versi 477.0.0.
Alur kerja login
Berikut adalah langkah-langkah alur kerja saat pengguna login menggunakan pendekatan akses FQDN:
Memulai login: Pengguna menjalankan perintah gcloud anthos auth login --server APISERVER-URL untuk
memulai proses login.
Pemilihan penyedia identitas: Pengguna diberi daftar penyedia identitas yang dikonfigurasi. Pengguna memilih penyedia tempat kredensialnya disimpan.
Autentikasi dengan penyedia identitas: Proses autentikasi berbeda-beda berdasarkan protokol penyedia identitas yang Anda pilih:
OIDC: Pengguna dialihkan ke halaman login penyedia OIDC. Setelah
berhasil login, penyedia akan mengirimkan kode kembali ke Layanan Identitas GKE,
yang menukarnya dengan token akses melalui komunikasi back-channel.
SAML: Pengguna dialihkan ke halaman login penyedia SAML. Setelah
berhasil login, penyedia akan langsung mengirimkan token (pernyataan) kembali ke Identity Service GKE,
sehingga menghindari callback tambahan.
LDAP: GKE Identity Service tidak mengalihkan ke penyedia eksternal, tetapi menampilkan halaman login tempat pengguna memasukkan kredensial LDAP mereka, yang diverifikasi langsung dengan server LDAP.
Verifikasi token dan pembuatan file kubeconfig: Layanan Identitas GKE
memverifikasi token yang diterima (atau pernyataan), membuat token baru untuk pengguna, dan
mengirimkan kembali file kubeconfig yang berisi token ini.
Akses cluster: Pengguna dapat mengakses cluster menggunakan perintah kubectl.
Klien kubectl secara otomatis mengirimkan token dari file kubeconfig dengan
setiap permintaan.
Validasi token dan otorisasi RBAC: Server Kubernetes API menerima
token, Layanan Identitas GKE memverifikasi token ini, dan mengambil klaim pengguna (nama pengguna dan grup).
Setelah validasi berhasil, server API akan menjalankan pemeriksaan Kontrol Akses Berbasis Peran (RBAC)
untuk menentukan resource yang diizinkan untuk diakses pengguna.
Login menggunakan sertifikat SNI tepercaya
Sertifikat SNI menyederhanakan akses cluster dengan memanfaatkan sertifikat tepercaya
yang sudah ada di perangkat perusahaan. Administrator dapat menentukan sertifikat ini pada saat pembuatan cluster. Jika cluster Anda menggunakan sertifikat SNI tepercaya di tingkat cluster, gunakan perintah di bagian ini dengan FQDN yang diberikan oleh administrator untuk login ke cluster dan menerima token akses. Anda juga dapat
menggunakan file kubeconfig aman tempat token disimpan setelah autentikasi berhasil.
Jalankan perintah berikut untuk melakukan autentikasi ke server:
APISERVER-URL: FQDN server Kubernetes API cluster.
OUTPUT_FILE: Gunakan tanda ini jika file kubeconfig Anda berada di
lokasi selain default. Jika tanda ini dihilangkan, token autentikasi akan ditambahkan ke file kubeconfig di lokasi default. Contoh:
--kubeconfig /path/to/custom.kubeconfig.
Login menggunakan sertifikat yang diterbitkan CA cluster
Jika Anda tidak menggunakan sertifikat SNI tepercaya di tingkat cluster, sertifikat yang digunakan oleh layanan identitas akan diterbitkan oleh certificate authority (CA) cluster. Administrator mendistribusikan sertifikat CA ini kepada pengguna.
Jalankan perintah berikut menggunakan sertifikat CA cluster untuk login ke cluster Anda:
Autentikasi lintas perangkat memungkinkan Anda login ke cluster Google Distributed Cloud (GDC) dari perangkat yang tidak menginstal browser. Anda dapat memulai proses autentikasi di perangkat utama (yang tidak menginstal browser) dan menyelesaikannya di perangkat sekunder yang menginstal browser.
Gunakan langkah-langkah berikut untuk penyiapan autentikasi lintas perangkat.
Login ke perangkat utama Anda
Jalankan perintah berikut untuk melakukan autentikasi ke server di perangkat utama Anda.
Tentukan argumen --no-browser untuk menunjukkan bahwa perangkat yang Anda perlukan untuk
mengakses cluster tidak menginstal browser.
Layanan Identitas GKE menampilkan perintah yang perlu Anda gunakan saat login
dari perangkat kedua. Berikut adalah contoh tampilan perintah:
You are authorizing gcloud CLI without access to a web browser. Please run the following command on a machine with a web browser and copy its output back here.
gcloud auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --remote-bootstrap="URL_TO_COPY_ON_THE_SECOND_DEVICE"
Enter the output of the above command:
Salin perintah gcloud.
Login ke cluster di perangkat kedua
Sebelum login dari perangkat kedua, pastikan Anda telah menginstal browser
dan memiliki konektivitas jaringan ke server Kubernetes API. Jalankan perintah yang Anda salin dari
langkah sebelumnya di perangkat kedua.
Saat mencoba login dari perangkat ini, pesan peringatan akan ditampilkan. Ikuti proses autentikasi standar seperti yang ditampilkan di browser. Setelah autentikasi berhasil, Anda akan diberi kode sekali pakai. Salin kode ini.
WARNING: The following line enables access to your Cluster resources. ONLY COPY IT TO A MACHINE YOU TRUST AND RUN 'gcloud auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --no-browser' EARLY ON.
Or_mHYQFm90efgJdwhajx0KeC_WXkuvBPuWv_83nFX9J_Eawm3tQcBpxBBWszj6Ix8dAWCgc1QjJBrlt67bzIYIBTexU7dc_ggtkMTNkG7wCIGYZ75zfg9P1gBshP33STe0ks-AoVonzk01YekMbyNugeYSO18CBwFhaDDSMABq4PI-clgbaSh8CPqrvDKRLenbvfD9BSK6SW945I0bOgPURxNzUX4sICWcvFozhQdLYICuwRM0AgarNFwoeh-0wbJGyRqUjq2NJbaYdf-VCaByiZaGPR2B1QVGXO7deKGtUnk1_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYg
Menyelesaikan login di perangkat utama
Tempel kode yang disalin dari langkah sebelumnya ke perintah perangkat
utama Anda.
Enter the code you received on the other device: Or_mHYQFm90efgJdwhajx0KeC_WXkuvBPuWv_83nFX9J_Eawm3tQcBpxBBWszj6Ix8dAWCgc1QjJBrlt67bzIYIBTexU7dc_ggtkMTNkG7wCIGYZ75zfg9P1gBshP33STe0ks-AoVonzk01YekMbyNugeYSO18CBwFhaDDSMABq4PI-clgbaSh8CPqrvDKRLenbvfD9BSK6SW945I0bOgPURxNzUX4sICWcvFozhQdLYICuwRM0AgarNFwoeh-0wbJGyRqUjq2NJbaYdf-VCaByiZaGPR2B1QVGXO7deKGtUnk1_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYg
Perangkat Anda menggunakan kode ini untuk membuat kredensial yang disimpan dalam
file kubeconfig. File ini memungkinkan akses ke cluster di perangkat utama Anda. Setelah Anda login, pesan berikut akan ditampilkan:
You are logged in!
Context is stored under the name '{cluster-name}'
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[],[],null,["# Log in using a fully qualified domain name (FQDN)\n=================================================\n\nGKE Identity Service lets you log in to configured clusters from the command line using a username and password from a third party identity provider. Follow the instructions in this page if your cluster administrator has chosen to let you authenticate directly on the GKE Identity Service server with a fully qualified domain name (FQDN).\nFor SAML providers, login access is supported only through this authentication\napproach.\n\nThis authentication approach is supported only for on-prem clusters (Google Distributed Cloud) on VMware\nand bare metal, from version 1.29. Other cluster types are not supported.\n\nThe `gcloud` CLI version required to log in with your provided FQDN is\natleast version 477.0.0.\n\nLogin workflow\n--------------\n\nHere are the workflow steps when a user logs in using the FQDN access approach:\n\n1. **Initiate login** : The user runs the command `gcloud anthos auth login --server `\u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e to initiate the login process.\n2. **Identity provider selection**: The user is given a list of configured identity providers. The user selects the provider where their credentials are stored.\n3. **Authentication with identity provider:** The authentication process differs based on the identity provider protocol you choose:\n\n - **OIDC**: The user is redirected to the OIDC-provider login page. After a successful login, the provider sends a code back to the GKE Identity Service, which exchanges it for an access token through a back-channel communication.\n - **SAML**: The user is redirected to the SAML-provider login page. After a successful login, the provider directly sends a token (assertion) back to the GKE Identity Service thereby avoiding an additional callback.\n - **LDAP**: Instead of redirecting to an external provider, the GKE Identity Service displays a login page where the user enters their LDAP credentials, which is verified directly with the LDAP server.\n4. **Token verification and kubeconfig file generation**: The GKE Identity Service\n verifies the token received (or assertion), creates a new token for the user, and\n sends back a kubeconfig file containing this token.\n\n5. **Cluster access** : The user can access the cluster using `kubectl` commands.\n The `kubectl` client automatically sends the token from the kubeconfig file with\n each request.\n\n6. **Token validation and RBAC authorization**: The Kubernetes API server receives\n the token, GKE Identity Service verifies this token, and retrieves the user's claims (username and groups).\n After successful validation, the API server runs Role-Based Access Control (RBAC)\n checks to determine the resources that the user is authorized to access.\n\nLog in using trusted SNI certificates\n-------------------------------------\n\nSNI certificates simplify cluster access by leveraging trusted certificates\nalready present on corporate devices. Administrators can specify this certificate at the\ntime of cluster creation. If your cluster uses a trusted SNI certificate at the cluster\nlevel, use the command in this section with the FQDN provided by your\nadministrator to log in to the cluster and receive an access token. You can also\nuse a secure `kubeconfig` file where the token is stored after successful authentication.\n\nRun the following command to authenticate to the server:\n\n`gcloud anthos auth login --server `\u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e` --kubeconfig `\u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e: FQDN of the cluster's Kubernetes API server.\n- \u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e: Use this flag if your `kubeconfig` file resides in a location other than the default. If this flag is omitted, authentication tokens are added to the `kubeconfig` file in the default location. For example: `--kubeconfig /path/to/custom.kubeconfig`.\n\nLog in using cluster CA-issued certificates\n-------------------------------------------\n\nIf you don't use a trusted SNI certificate at the cluster level, then\nthe certificate used by the identity service is issued by the cluster's\ncertificate authority (CA). Administrators distribute this CA certificate to users.\nRun the following command using the cluster's CA certificate to log in to your cluster:\n\n`gcloud anthos auth login --server `\u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e` --kubeconfig `\u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e` --login-config-cert `\u003cvar translate=\"no\"\u003eCLUSTER_CA_CERTIFICATE\u003c/var\u003e\n| **Note:** As a recommendation, users can trust the CA certificate on their devices and browsers by following the device-specific instructions. This is a one-time activity. Once the CA certificate is trusted, you can log in to the cluster without specifying the `--login-config-cert` argument in the command.\n\nCross-device authentication\n---------------------------\n\nCross-device authentication lets you sign in to Google Distributed Cloud (GDC) clusters from devices that don't have a browser installed. You can initiate the authentication process on your primary device (which doesn't have a browser installed) and complete it on a secondary device installed with a browser.\n\nUse the following steps for a cross-device authentication setup.\n\n1. **Log in to your primary device**\n\n Run the following command to authenticate to the server on your primary device.\n Specify the argument `--no-browser` to indicate that the device you need to\n access your cluster from does not have a browser installed.\n\n `gcloud anthos auth login --server `\u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e` --kubeconfig `\u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e` --no-browser`\n\n GKE Identity Service returns a command that you need to use when you log\n in from the second device. Here's an example of what the command looks like: \n\n You are authorizing gcloud CLI without access to a web browser. Please run the following command on a machine with a web browser and copy its output back here.\n\n gcloud auth login --server \u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e --kubeconfig \u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e --remote-bootstrap=\"\u003cvar translate=\"no\"\u003eURL_TO_COPY_ON_THE_SECOND_DEVICE\u003c/var\u003e\"\n\n Enter the output of the above command:\n\n Copy the `gcloud` command.\n2. **Log in to clusters on the second device**\n\n Before logging in from the second device, verify that you have the browser installed\n and have network connectivity to the Kubernetes API server. Run the command you copied from\n the previous step on the second device. \n\n gcloud auth login --server \u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e --kubeconfig \u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e --remote-bootstrap=\"\u003cvar translate=\"no\"\u003eURL_TO_COPY_ON_THE_SECOND_DEVICE\u003c/var\u003e\"\n\n When attempting to log in from this device, a warning message is displayed. Follow the standard authentication process as displayed on the browser. After a successful authentication, you will be provided with a one-time code. Copy this code. \n\n WARNING: The following line enables access to your Cluster resources. ONLY COPY IT TO A MACHINE YOU TRUST AND RUN 'gcloud auth login --server \u003cvar translate=\"no\"\u003eAPISERVER-URL\u003c/var\u003e --kubeconfig \u003cvar translate=\"no\"\u003eOUTPUT_FILE\u003c/var\u003e --no-browser' EARLY ON.\n\n Or_mHYQFm90efgJdwhajx0KeC_WXkuvBPuWv_83nFX9J_Eawm3tQcBpxBBWszj6Ix8dAWCgc1QjJBrlt67bzIYIBTexU7dc_ggtkMTNkG7wCIGYZ75zfg9P1gBshP33STe0ks-AoVonzk01YekMbyNugeYSO18CBwFhaDDSMABq4PI-clgbaSh8CPqrvDKRLenbvfD9BSK6SW945I0bOgPURxNzUX4sICWcvFozhQdLYICuwRM0AgarNFwoeh-0wbJGyRqUjq2NJbaYdf-VCaByiZaGPR2B1QVGXO7deKGtUnk1_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYg\n\n3. **Complete log in on your primary device**\n\n Paste the copied code from the previous step into the prompt of your primary\n device. \n\n Enter the code you received on the other device: Or_mHYQFm90efgJdwhajx0KeC_WXkuvBPuWv_83nFX9J_Eawm3tQcBpxBBWszj6Ix8dAWCgc1QjJBrlt67bzIYIBTexU7dc_ggtkMTNkG7wCIGYZ75zfg9P1gBshP33STe0ks-AoVonzk01YekMbyNugeYSO18CBwFhaDDSMABq4PI-clgbaSh8CPqrvDKRLenbvfD9BSK6SW945I0bOgPURxNzUX4sICWcvFozhQdLYICuwRM0AgarNFwoeh-0wbJGyRqUjq2NJbaYdf-VCaByiZaGPR2B1QVGXO7deKGtUnk1_tTFOnB6sJQvT6UJ8Ge5nkR38rqBeeGkYdlVIBTXShENG80An1Ve524xZupSzCHNSVTJqYg\n\n Your device uses this code to generate a credential that is saved in a\n `kubeconfig` file. This file enables access to the cluster on your primary\n device. When you have logged in, the following message is displayed: \n\n You are logged in!\n Context is stored under the name '{cluster-name}'"]]
