Produk yang dijelaskan dalam dokumentasi ini, Cluster Anthos di AWS (generasi sebelumnya), kini berada dalam mode pemeliharaan. Semua penginstalan baru harus menggunakan produk generasi saat ini, cluster Anthos di AWS.

Halaman ini diterjemahkan oleh Cloud Translation API.

Mengautentikasi dengan OpenID Connect (OIDC)

Pelajari cara mengonfigurasi GKE di AWS agar dapat menggunakan OpenID Connect (OIDC) untuk autentikasi ke cluster pengguna. Topik ini membahas proses untuk mengonfigurasi GKE di AWS dengan penyedia OpenID apa pun.

Untuk mengupgrade cluster yang menggunakan autentikasi OIDC ke Kubernetes 1.21, lihat Mengupgrade ke 1.21.

Untuk ringkasan GKE pada alur autentikasi AWS, lihat Autentikasi.

Ringkasan

GKE di AWS mendukung OIDC sebagai salah satu mekanisme autentikasi untuk berinteraksi dengan server Kubernetes API cluster pengguna. Dengan OIDC, Anda dapat mengelola akses ke cluster Kubernetes menggunakan prosedur standar di organisasi Anda untuk membuat, mengaktifkan, dan menonaktifkan akun pengguna.

Sebelum memulai

Topik ini mengasumsikan bahwa Anda telah memahami konsep autentikasi dan OpenID berikut:
Google Cloud CLI harus diinstal di setiap komputer lokal developer.
Sistem headless tidak didukung. Untuk melakukan autentikasi, Anda harus membuka browser di mesin lokal yang menjalankan gcloud CLI. Browser kemudian meminta Anda untuk memberikan otorisasi ke akun pengguna.
Untuk melakukan autentikasi melalui Konsol Google Cloud, setiap cluster yang ingin dikonfigurasi untuk autentikasi OIDC harus didaftarkan ke Google Cloud.

Persona

Topik ini mengacu pada tiga persona:

Administrator organisasi: Orang ini memilih penyedia OpenID dan mendaftarkan aplikasi klien ke penyedia tersebut.
Administrator cluster: Orang ini membuat satu atau beberapa cluster pengguna dan membuat file konfigurasi autentikasi untuk developer yang menggunakan cluster tersebut.
Developer: Orang ini menjalankan beban kerja pada satu atau beberapa cluster dan menggunakan OIDC untuk melakukan autentikasi.

Pilih penyedia OpenID

Bagian ini ditujukan untuk administrator organisasi.

Anda dapat menggunakan penyedia OpenID pilihan Anda. Untuk mengetahui daftar penyedia tersertifikasi, lihat Sertifikasi OpenID.

Membuat URL alihan

Bagian ini ditujukan untuk administrator organisasi.

Penyedia OpenID menggunakan URL pengalihan untuk mengembalikan token ID. Anda harus membuat URL pengalihan untuk gcloud CLI dan Google Cloud Console.

Menetapkan URL alihan gcloud CLI

Saat mengonfigurasi penyedia OpenID, tentukan URL alihan CLI sebagai http://localhost:PORT/callback

Ganti PORT dengan nomor port Anda yang lebih besar dari 1024.

Setel URL alihan Konsol Google Cloud

URL alihan untuk konsol Google Cloud adalah:

https://console.cloud.google.com/kubernetes/oidc

Saat mengonfigurasi penyedia OIDC, tetapkan https://console.cloud.google.com/kubernetes/oidc sebagai salah satu URL alihan.

Mendaftarkan aplikasi klien dengan penyedia OpenID

Bagian ini ditujukan untuk administrator organisasi.

Sebelum developer dapat menggunakan Google Cloud CLI atau Google Cloud Console dengan penyedia OpenID, Anda harus mendaftarkan kedua klien tersebut dengan penyedia OpenID. Pendaftaran mencakup langkah-langkah berikut:

Pelajari URI penerbit penyedia Anda. Gcloud CLI atau Google Cloud Console mengirimkan permintaan autentikasi ke URI ini.
Konfigurasikan penyedia Anda dengan URL alihan, termasuk nomor port, untuk gcloud CLI.
Konfigurasikan penyedia Anda dengan URL alihan untuk konsol Google Cloud, https://console.cloud.google.com/kubernetes/oidc.
Buat satu client ID yang digunakan penyedia Anda untuk mengidentifikasi Google Cloud CLI dan Konsol Google Cloud.
Buat satu rahasia klien yang digunakan gcloud CLI dan Google Cloud Console untuk melakukan autentikasi ke penyedia OpenID.
Buat cakupan kustom yang dapat digunakan gcloud CLI atau Konsol Google Cloud untuk meminta grup keamanan pengguna.
Buat nama klaim kustom yang digunakan penyedia untuk menampilkan grup keamanan pengguna.

Konfigurasi cluster Anda

Bagian ini ditujukan bagi administrator cluster.

Untuk mengonfigurasi autentikasi OIDC, Anda harus mengonfigurasi resource AWSCluster cluster pengguna Anda dengan detail autentikasi untuk sebuah cluster. Detail dari AWSCluster digunakan untuk mengonfigurasi OIDC untuk Konsol Google Cloud dan Plugin Authentication untuk GKE Enterprise. Konfigurasi ini mencakup informasi OIDC berikut:

authentication:
  awsIAM:
    adminIdentityARNs:
      - AWS_IAM_ARN
  oidc:
  -   certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET 
      extraParams:  EXTRA_PARAMS
      groupsClaim:  GROUPS_CLAIM
      groupPrefix:  GROUP_PREFIX
      issuerURI:  ISSUER_URI
      kubectlRedirectURI:  KUBECTL_REDIRECT_URI
      scopes:  SCOPES
      userClaim:  USER_CLAIM
      userPrefix:  USER_PREFIX

Kolom autentikasi

Tabel berikut menjelaskan kolom objek authentication.awsIAM.adminIdentityARNs.

Tabel berikut menjelaskan kolom objek `oidc`.

Kolom	Diperlukan	Deskripsi	Format
adminIdentityARNs	Ya, jika mengonfigurasi OIDC.	Amazon Resource Name (ARN) dari identitas IAM AWS (pengguna atau peran) yang diberi akses administrator cluster oleh GKE di AWS. Contoh: `arn:aws:iam::123456789012:group/Developers`	String

Kolom	Diperlukan	Deskripsi	Format
certificateAuthorityData	Tidak	Sertifikat berenkode PEM yang dienkode base64 untuk penyedia OIDC. Untuk membuat string ini, enkode sertifikat, termasuk header, ke dalam base64. Sertakan string yang dihasilkan di `certificateAuthorityData` sebagai satu baris. Contoh: `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	String
clientID	Ya	ID untuk aplikasi klien yang membuat permintaan autentikasi ke penyedia OpenID.	String
clientSecret	Tidak	Rahasia bersama antara aplikasi klien OIDC dan penyedia OIDC.	String
extraParams	Tidak	Parameter nilai kunci tambahan yang akan dikirim ke penyedia OpenID. Jika Anda memberikan otorisasi untuk grup, teruskan `resource=token-groups-claim`. Jika server otorisasi Anda meminta izin, untuk autentikasi dengan Microsoft Azure dan Okta, tetapkan `extraParams` ke `prompt=consent`. Untuk Cloud Identity, tetapkan `extraParams` ke `prompt=consent,access_type=offline`.	Daftar yang dipisahkan koma
groupsClaim	Tidak	JWT mengklaim yang digunakan penyedia tersebut untuk menampilkan grup keamanan Anda.	String
groupPrefix	Tidak	Awalan ditambahkan ke klaim grup untuk mencegah bentrokan dengan nama yang ada. Misalnya, jika Anda memiliki dua grup bernama `foobar` yang menambahkan awalan `gid-`, grup hasilnya adalah `gid-foobar`.	String
issuerURI	Ya	URL tempat permintaan otorisasi dikirim ke OpenID Anda, seperti `https://example.com/adfs`. Server Kubernetes API menggunakan URL ini untuk menemukan kunci publik guna memverifikasi token. URI harus menggunakan HTTPS.	URL String
kubectlRedirectURI	Ya	URL alihan yang digunakan `kubectl` untuk otorisasi.	URL String
cakupan	Ya	Cakupan tambahan untuk dikirim ke penyedia OpenID. Microsoft Azure dan Okta memerlukan cakupan `offline_access`.	Daftar yang dipisahkan koma
userClaim	Tidak	JWT mengklaim untuk digunakan sebagai nama pengguna. Anda dapat memilih klaim lain, seperti email atau nama, tergantung penyedia OpenID. Namun, klaim selain email diawali dengan URL penerbit untuk mencegah konflik penamaan.	String
userPrefix	Tidak	Awalan yang ditambahkan pada klaim nama pengguna untuk mencegah bentrokan dengan nama yang sudah ada.	String

Contoh: Memberikan otorisasi kepada pengguna dan grup

Banyak penyedia mengenkode properti identitas pengguna, seperti email dan ID pengguna, dalam sebuah token. Namun, properti ini memiliki risiko implisit untuk kebijakan autentikasi:

ID pengguna dapat membuat kebijakan sulit dibaca dan diaudit.
Penggunaan alamat email dapat menimbulkan risiko ketersediaan (jika pengguna mengubah email utamanya) dan risiko keamanan (jika email dapat ditetapkan ulang).

Daripada menetapkan ID pengguna, sebaiknya gunakan kebijakan grup, yang dapat bersifat persisten dan lebih mudah diaudit.

Misalkan penyedia Anda membuat token identitas yang menyertakan kolom berikut:

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

Dengan format token ini, Anda akan mengisi spesifikasi oidc file konfigurasi seperti berikut:

issuerURL: 'https://server.example.com'
username: 'sub'
usernamePrefix: 'uid-'
group: 'groupList'
groupPrefix: 'gid-'
extraParams: 'resource=token-groups-claim'
...

Setelah membuat cluster pengguna, Anda dapat menggunakan role-based access control (RBAC) Kubernetes untuk memberikan akses hak istimewa kepada pengguna yang diautentikasi.

Pada contoh berikut, Anda akan membuat ClusterRole yang memberi penggunanya akses hanya baca ke Secret cluster, dan membuat resource ClusterRoleBinding untuk mengikat peran ke grup terautentikasi.

Tentukan ClusterRole. Salin YAML berikut ke dalam file bernama secret-reader-role.yaml.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

Tentukan ClusterRoleBinding. Salin YAML berikut ke dalam file bernama secret-reader-admins.yaml.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-admins
subjects:
  # Allows anyone in the "us-east1-cluster-admins" group to
  # read Secrets in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
  # Allows this specific user to read Secrets in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Terapkan secret-reader-role.yaml dan secret-reader-admins.yaml ke cluster Anda dengan kubectl.
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f secret-reader-role.yaml && \
  kubectl apply -f secret-reader-admins.yaml
```
Pengguna yang diberi akses di read-secrets-admins kini memiliki akses untuk membaca Rahasia di cluster Anda.

Membuat konfigurasi login

Bagian ini ditujukan bagi administrator cluster.

Setelah membuat cluster pengguna, Anda perlu membuat file konfigurasi untuk cluster tersebut menggunakan gcloud anthos create-login-config.

Dari direktori anthos-aws, gunakan anthos-gke untuk mengalihkan konteks ke cluster pengguna.
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
Ganti CLUSTER_NAME dengan nama cluster pengguna Anda.
Buat konfigurasi dengan gcloud anthos.
```
gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
```
Ganti usercluster-kubeconfig dengan jalur ke file kubeconfig cluster pengguna Anda. Di Linux dan macOS, secara default file ini berada di ~/.kube/config.

Perintah ini menghasilkan file (kubectl-anthos-config.yaml) yang berisi informasi konfigurasi yang digunakan developer Anda untuk melakukan autentikasi ke cluster dengan gcloud CLI. Anda tidak boleh mengubah file ini.

Untuk memahami konten kubectl-anthos-config.yaml lebih lanjut, lihat lampiran.

Distribusikan file konfigurasi kepada pengguna yang perlu melakukan autentikasi ke cluster pengguna Anda. Anda dapat mendistribusikan konfigurasi dengan:

Menempatkan file di direktori default.
Mendistribusikan file dengan aman.
Menghosting file di server HTTPS.

Direktori default konfigurasi login

Lokasi default untuk menyimpan file konfigurasi untuk setiap OS adalah sebagai berikut:

Linux: $HOME/.config/google/anthos/kubectl-anthos-config.yaml, dengan $HOME adalah direktori utama pengguna.
macOS: $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml, dengan $HOME adalah direktori utama pengguna.
Windows: %APPDATA%/google/anthos/kubectl-anthos-config.yaml, dengan %APPDATA% adalah direktori data aplikasi pengguna.

Setelah konfigurasi login didistribusikan, developer Anda siap untuk mengonfigurasi gcloud CLI untuk mengakses cluster.

Mengubah cluster Anda setelah mengupgrade ke Kubernetes 1.21

Setelah mengupgrade cluster ke Kubernetes 1.21, Anda perlu mengonfigurasi GKE Identity Service dan menghapus informasi OIDC dari konfigurasi cluster Anda. Untuk mengupdate konfigurasi, lakukan langkah-langkah berikut:

Ikuti langkah-langkah di bagian Mengupgrade cluster.
Dari direktori anthos-aws, gunakan anthos-gke untuk mengalihkan konteks ke cluster pengguna.
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
Ganti CLUSTER_NAME dengan nama cluster pengguna Anda.
Buka manifes yang berisi AWSCluster di editor teks. Biarkan file tetap terbuka dan gunakan nilai objek oidc untuk mengikuti langkah-langkah dalam Mengonfigurasi cluster untuk GKE Identity Service.
Dari direktori anthos-aws, gunakan anthos-gke untuk mengalihkan konteks ke layanan pengelolaan Anda.
```
cd anthos-aws
anthos-gke aws management get-credentials
```
Catatan: anthos-gke menggunakan kredensial yang Anda tentukan saat menjalankan aws configure.
Buka file YAML yang membuat AWSCluster di editor teks. Jika tidak memiliki file YAML awal, Anda dapat menggunakan kubectl edit.
Edit YAML
Jika Anda mengikuti petunjuk dalam Membuat cluster pengguna, file YAML Anda akan diberi nama cluster-0.yaml. Buka file ini di editor teks.
edit kubectl
Untuk menggunakan kubectl edit guna mengedit AWSCluster, jalankan perintah berikut:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-name
```
Ganti cluster-name dengan AWSCluster Anda. Misalnya, untuk mengedit cluster default, cluster-0, jalankan perintah berikut:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-0
```
Hapus objek oidc dari manifes cluster Anda.
Simpan file. Jika Anda menggunakan kubectl edit, kubectl akan menerapkan perubahan secara otomatis. Jika Anda mengedit file YAML, terapkan ke layanan pengelolaan Anda menggunakan perintah berikut:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f cluster-0.yaml
```
Kemudian, layanan pengelolaan akan mengupdate AWSCluster Anda.

Mengonfigurasi gcloud untuk mengakses cluster Anda

Bagian ini ditujukan untuk developer atau administrator cluster.

Prasyarat

Untuk menyelesaikan bagian ini, Anda harus menyelesaikan hal-hal berikut:

Konfigurasi login.

Versi terbaru gcloud CLI dengan komponen anthos-auth.

gcloud components update
gcloud components install anthos-auth

Verifikasi bahwa gcloud CLI berhasil diinstal dengan menjalankan perintah berikut, yang akan merespons dengan memberikan detail tentang argumen yang diperlukan dan opsi yang tersedia.
```
gcloud anthos auth
```

Mengautentikasi cluster Anda

Anda dapat melakukan autentikasi ke cluster dengan cara berikut:

Dengan gcloud CLI di mesin lokal Anda.
Dengan gcloud CLI pada mesin jarak jauh menggunakan tunnel SSH.
Dengan Connect di konsol Google Cloud.

gcloud lokal

Gunakan gcloud anthos auth login untuk melakukan autentikasi ke cluster dengan konfigurasi login Anda.

Jika Anda menempatkan konfigurasi login di lokasi default dan telah mengonfigurasi nama cluster, Anda dapat menggunakan gcloud anthos auth login tanpa opsi. Anda juga dapat mengonfigurasi cluster, pengguna, dan detail autentikasi lainnya dengan parameter opsional.

Default

gcloud anthos auth login --cluster CLUSTER_NAME

Ganti CLUSTER_NAME dengan nama cluster yang sepenuhnya memenuhi syarat. Misalnya, projects/my-gcp-project/locations/global/memberships/cluster-0-0123456a.

Parameter opsional

gcloud anthos auth login mendukung parameter opsional berikut:

gcloud anthos auth login --cluster CLUSTER_NAME \
--user USERNAME --login-config ANTHOS_CONFIG_YAML \
--login-config-cert LOGIN_CONFIG_CERT_PEM \
--kubeconfig=KUBECONFIG --dry-run

Parameter tersebut dijelaskan dalam tabel berikut.

Parameter	Deskripsi
`cluster`	Nama cluster yang akan diotentikasi. Default-nya adalah cluster di `kubectl-anthos-config.yaml`.
`user`	Nama pengguna untuk kredensial di `kubeconfig`. Default-nya adalah `{cluster-name}-anthos-default-user`.
`login-config`	Baik jalur ke file konfigurasi yang dibuat oleh admin cluster untuk developer atau URL yang menghosting file. Default-nya adalah `kubectl-anthos-config.yaml`.
`login-config-cert`	Jika menggunakan URL untuk `login-config`, jalur ke file sertifikat CA untuk membuat koneksi HTTPS.
`kubeconfig`	Jalur ke file kubeconfig yang berisi token. Default-nya adalah $HOME/.kube/config`.
uji coba	Uji opsi command line Anda tanpa mengubah konfigurasi atau cluster.

Perintah gcloud anthos login meluncurkan browser yang meminta pengguna untuk login dengan kredensial perusahaan mereka, melakukan pertukaran kredensial OIDC, dan memperoleh token yang relevan. Kemudian, gcloud CLI akan menulis token ke file kubeconfig. kubectl menggunakan file ini untuk melakukan autentikasi ke cluster pengguna.

Untuk memverifikasi bahwa autentikasi berhasil, jalankan perintah kubectl apa pun dengan file kubeconfig Anda:

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get nodes --kubeconfig my.kubeconfig

tunnel gcloud

Jika ingin melakukan autentikasi ke cluster pengguna dari mesin jarak jauh, Anda dapat melakukan autentikasi menggunakan tunnel SSH. Untuk menggunakan tunnel, file konfigurasi autentikasi Anda harus berada di komputer jarak jauh, dan Anda harus dapat menjangkau penyedia Open ID dari komputer lokal Anda.

Di komputer lokal, jalankan perintah berikut:

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

Ganti kode berikut:

USERNAME dengan pengguna yang memiliki akses SSH ke mesin jarak jauh.
REMOTE_MACHINE dengan nama host atau alamat IP komputer jarak jauh.
LOCAL_PORT adalah port yang tersedia di mesin lokal Anda yang digunakan ssh untuk melakukan tunnel ke mesin jarak jauh.
REMOTE_PORT adalah port yang dikonfigurasi untuk URL pengalihan OIDC Anda. Nomor port adalah bagian dari kolom kubectlRedirectURI pada file konfigurasi autentikasi Anda.

Di shell SSH, jalankan perintah berikut untuk memulai autentikasi:

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

Ganti AUTH_CONFIG_FILE dengan jalur file konfigurasi autentikasi Anda di komputer jarak jauh. Gcloud CLI menjalankan server web di komputer jarak jauh.

Di komputer lokal Anda, di browser, buka http://localhost:LOCAL_PORT/login dan ikuti alur login OIDC.

File kubeconfig di komputer jarak jauh Anda sekarang memiliki token untuk mengakses cluster pengguna.

Di shell SSH, pastikan Anda memiliki akses ke cluster pengguna:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Konsol

Anda dapat melakukan autentikasi dengan Konsol Google Cloud, memulai alur autentikasi dari halaman cluster Kubernetes di Konsol Google Cloud:

Buka konsol Google Cloud:

Buka halaman cluster Kubernetes
Temukan GKE Anda di cluster AWS dalam daftar, lalu klik Login.
Pilih Autentikasi dengan Penyedia Identitas yang dikonfigurasi untuk cluster, lalu klik LOGIN.

Anda akan dialihkan ke Penyedia Identitas, tempat Anda mungkin perlu login atau mengizinkan Google Cloud Console mengakses akun Anda. Kemudian, Anda akan dialihkan kembali ke halaman Cluster Kubernetes di Konsol Google Cloud.

Memperbarui konfigurasi OIDC

Untuk memperbarui konfigurasi OIDC pada cluster Anda, gunakan perintah kubectl edit.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit clientconfigs -n kube-public default

Alat kubectl memuat resource ClientConfig di editor default Anda. Untuk memperbarui konfigurasi, simpan file. Alat kubectl mengupdate resource ClientConfig di cluster Anda.

Untuk informasi tentang konten resource ClientConfig, lihat bagian berikut.

Lampiran: Contoh konfigurasi login

Berikut adalah contoh kubectl-anthos-config.yaml. Contoh ini disertakan untuk memahami isinya. Anda harus selalu membuat file dengan gcloud anthos create-login-config.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
 name: default
 namespace: kube-public
spec:
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_CONFIG
      clientSecret: CLIENT_SECRET
      extraParams: resource=k8s-group-claim,domain_hint=consumers
      certificateAuthorityData:   CERTIFICATE_STRING
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
    proxy: PROXY_URL #Optional
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

Untuk mengetahui penjelasan tentang isi kolom, lihat Kolom autentikasi.

Langkah selanjutnya

Deploy workload pertama Anda ke GKE di AWS.

Mengautentikasi dengan OpenID Connect (OIDC)

Ringkasan

Sebelum memulai

Persona

Pilih penyedia OpenID

Membuat URL alihan

Menetapkan URL alihan gcloud CLI

Setel URL alihan Konsol Google Cloud

Mendaftarkan aplikasi klien dengan penyedia OpenID

Konfigurasi cluster Anda

Kolom autentikasi

Contoh: Memberikan otorisasi kepada pengguna dan grup

Membuat konfigurasi login

Mendistribusikan konfigurasi login

Direktori default konfigurasi login

Mengubah cluster Anda setelah mengupgrade ke Kubernetes 1.21

Edit YAML

edit kubectl

Mengonfigurasi gcloud untuk mengakses cluster Anda

Prasyarat

Mengautentikasi cluster Anda

gcloud lokal

Default

Parameter opsional

tunnel gcloud

Konsol

Memperbarui konfigurasi OIDC

Lampiran: Contoh konfigurasi login

Langkah selanjutnya