Memecahkan masalah GKE pada autentikasi VMware

Dokumen ini membantu memecahkan masalah autentikasi di Google Distributed Cloud Virtual for VMware. Panduan dan informasi pemecahan masalah umum disediakan, beserta informasi khusus untuk OpenID Connect (OIDC) dan Lightweight Directory Access Protocol (LDAP).

Autentikasi OIDC dan LDAP menggunakan GKE Identity Service. Sebelum dapat menggunakan GKE Identity Service dengan Google Distributed Cloud Virtual untuk VMware, Anda harus mengonfigurasi penyedia identitas. Jika Anda belum mengonfigurasi penyedia identitas untuk GKE Identity Service, ikuti petunjuk untuk salah satu penyedia yang lebih umum berikut:

Baca panduan pemecahan masalah penyedia identitas GKE Identity Service untuk mengetahui informasi tentang cara mengaktifkan dan meninjau log identitas dan menguji konektivitas.

Jika Anda memerlukan bantuan lainnya, hubungi Cloud Customer Care.

Pemecahan masalah umum

Tips pemecahan masalah berikut dapat membantu mengatasi masalah autentikasi dan otorisasi umum pada Google Distributed Cloud Virtual for VMware. Jika masalah ini tidak berlaku atau Anda mengalami masalah dengan OIDC atau LDAP, lanjutkan ke bagian tentang pemecahan masalah GKE Identity Service.

Selalu update `gcloud anthos auth`

Anda dapat menghindari banyak masalah umum dengan memverifikasi bahwa komponen penginstalan gcloud anthos auth Anda sudah yang terbaru.

Ada dua bagian yang harus diverifikasi. Perintah gcloud anthos auth memiliki logika dalam komponen inti Google Cloud CLI, dan komponen anthos-auth yang dikemas secara terpisah.

Untuk mengupdate Google Cloud CLI:
```
gcloud components update
```
Untuk mengupdate komponen anthos-auth:
```
gcloud components install anthos-auth
```

Konfigurasi penyedia tidak valid

Jika konfigurasi Penyedia Identitas tidak valid, Anda akan melihat layar error dari Penyedia Identitas Anda setelah mengklik LOGIN. Ikuti petunjuk khusus penyedia untuk mengonfigurasi penyedia atau cluster Anda dengan benar.

Konfigurasi tidak valid

Jika Konsol Google Cloud tidak dapat membaca konfigurasi OIDC dari cluster Anda, tombol LOGIN akan dinonaktifkan. Untuk memecahkan masalah konfigurasi OIDC cluster, lihat bagian memecahkan masalah OIDC berikut dalam dokumen ini.

Izin tidak valid

Jika Anda telah menyelesaikan alur autentikasi, tetapi masih tidak melihat detail cluster, pastikan Anda telah memberikan izin RBAC yang benar ke akun yang digunakan dengan OIDC. Akun ini mungkin berbeda dengan akun yang Anda gunakan untuk mengakses konsol Google Cloud.

Token refresh tidak ada

Masalah berikut terjadi saat server otorisasi meminta izin, tetapi parameter autentikasi yang diperlukan tidak diberikan.

Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct

Untuk mengatasi masalah ini, di resource ClientConfig Anda, tambahkan prompt=consent ke kolom authentication.oidc.extraParams. Kemudian, buat ulang file autentikasi klien.

Token refresh sudah tidak berlaku

Masalah berikut terjadi saat token refresh dalam file kubeconfig telah habis masa berlakunya:

Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
    certificate signed by unknown authority

Untuk mengatasi masalah ini, jalankan kembali perintah gcloud anthos auth login.

Login autentikasi gcloud anthos gagal dengan `proxyconnect tcp`

Masalah ini terjadi saat ada error dalam konfigurasi variabel lingkungan https_proxy atau HTTPS_PROXY. Jika ada https:// yang ditentukan dalam variabel lingkungan, library klien HTTP GoLang mungkin akan gagal jika proxy dikonfigurasi untuk menangani koneksi HTTPS menggunakan protokol lain seperti SOCK5.

Contoh pesan error berikut mungkin ditampilkan:

proxyconnect tcp: tls: first record does not look like a TLS handshake

Untuk mengatasi masalah ini, ubah variabel lingkungan https_proxy dan HTTPS_PROXY untuk menghilangkan https:// prefix. Di Windows, ubah variabel lingkungan sistem. Misalnya, ubah nilai variabel lingkungan https_proxy dari https://webproxy.example.com:8000 menjadi webproxy.example.com:8000.

Akses cluster gagal saat menggunakan kubeconfig yang dibuat oleh `gcloud anthos auth login`

Masalah ini terjadi jika server Kubernetes API tidak dapat memberikan otorisasi kepada pengguna. Hal ini dapat terjadi jika RBAC yang sesuai tidak ada atau salah, atau ada error dalam konfigurasi OIDC untuk cluster. Contoh error berikut mungkin ditampilkan:

Unauthorized

Untuk mengatasi masalah ini, selesaikan beberapa langkah berikut:

Dalam file kubeconfig yang dibuat oleh gcloud anthos auth login, salin nilai id-token.

kind: Config
...
users:
- name: ...
  user:
    auth-provider:
      config:
        id-token: xxxxyyyy

Instal jwt-cli, lalu jalankan:
```
jwt ID_TOKEN
```
Verifikasi konfigurasi OIDC.

Resource ClientConfig memiliki kolom group dan username. Kolom ini digunakan untuk menetapkan tanda --oidc-group-claim dan --oidc-username-claim di server Kubernetes API. Saat disajikan dengan token, server API akan meneruskan token ke GKE Identity Service, yang menampilkan group-claim dan username-claim yang telah diekstrak kembali ke server API. Server API menggunakan respons untuk memverifikasi bahwa grup atau pengguna yang sesuai memiliki izin yang benar.

Verifikasi bahwa klaim yang ditetapkan untuk group dan user dalam resource ClientConfig ada dalam token ID.
Periksa RBAC yang diterapkan.

Pastikan ada RBAC dengan izin yang benar untuk pengguna yang ditentukan oleh username-claim atau salah satu grup yang tercantum group-claim dari langkah sebelumnya. Nama pengguna atau grup di RBAC harus diawali dengan usernameprefix atau groupprefix yang ditentukan dalam resource ClientConfig.

Jika usernameprefix kosong, dan username adalah nilai selain email, awalan akan ditetapkan secara default ke issuerurl#. Untuk menonaktifkan awalan nama pengguna, tetapkan usernameprefix ke -.

Untuk mengetahui informasi selengkapnya tentang awalan pengguna dan grup, lihat Mengautentikasi dengan OIDC.

Catatan: Server Kubernetes API memperlakukan garis miring terbalik sebagai karakter escape. Jika nama pengguna atau grup berisi \\, server API akan membacanya sebagai \ tunggal saat mengurai token ID. Oleh karena itu, binding peran RBAC yang diterapkan untuk pengguna atau grup ini hanya boleh berisi satu garis miring terbalik, atau Anda mungkin melihat error Unauthorized.

Resource ClientConfig:
```
oidc:
  ...
  username: "unique_name"
  usernameprefix: "-"
  group: "group"
  groupprefix: "oidc:"
```
Token ID:
```
{
  ...
  "email": "cluster-developer@example.com",
  "unique_name": "EXAMPLE\cluster-developer",
  "group": [
    "Domain Users",
    "EXAMPLE\developers"
  ],
...
}
```
Binding RBAC berikut memberikan peran cluster pod-reader kepada grup dan pengguna ini. Perhatikan garis miring tunggal di kolom nama, bukan garis miring ganda:

ClusterRoleBinding Grup:
```
apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
- kind: Group
  name: "oidc:EXAMPLE\developers"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
ClusterRoleBinding Pengguna:
```
apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
- kind: User
  name: "EXAMPLE\cluster-developer"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
Periksa log server Kubernetes API.

Jika plugin OIDC yang dikonfigurasi di server Kubernetes API tidak dimulai dengan benar, server API akan menampilkan error Unauthorized saat diberi token ID. Untuk melihat apakah ada masalah dengan plugin OIDC di server API, jalankan:
```
kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Ganti kode berikut:
- USER_CLUSTER_NAME: Nama cluster pengguna Anda untuk melihat log.
- ADMIN_CLUSTER_KUBECONFIG: File kubeconfig cluster admin.

Masalah ini terjadi saat file kubeconfig yang diteruskan ke gkectl create-login-config bukan untuk cluster pengguna atau resource ClientConfig tidak muncul selama pembuatan cluster.

Error getting clientconfig using KUBECONFIG

Untuk mengatasi masalah ini, pastikan Anda memiliki file kubeconfig yang benar untuk cluster pengguna Anda. Selanjutnya, periksa apakah resource ClientConfig ada dalam cluster tersebut:

kubectl get clientconfig default -n kube-public \
  --kubeconfig USER_CLUSTER_KUBECONFIG

Ganti USER_CLUSTER_KUBECONFIG dengan jalur ke file cluster kubeconfig pengguna Anda.

Masalah ini terjadi jika Anda mencoba menulis data konfigurasi login yang berisi nama cluster yang sudah ada di file tujuan. Setiap file konfigurasi login harus berisi nama cluster yang unik.

error merging with file MERGE_FILE because MERGE_FILE contains a cluster with
  the same name as the one read from KUBECONFIG. Please write to a new
  output file

Untuk mengatasi masalah ini, gunakan flag --output untuk menentukan file tujuan baru.

Jika Anda tidak memberikan --output, data konfigurasi login ini akan ditulis ke file bernama kubectl-anthos-config.yaml di direktori saat ini.

Memecahkan masalah OIDC

Saat autentikasi OIDC tidak berfungsi untuk Google Distributed Cloud Virtual for VMware, biasanya spesifikasi OIDC dalam resource ClientConfig tidak dikonfigurasi dengan benar. Resource ClientConfig memberikan petunjuk untuk meninjau log dan spesifikasi OIDC guna membantu mengidentifikasi penyebab masalah OIDC.

Baca panduan pemecahan masalah penyedia identitas GKE Identity Service untuk mengetahui informasi tentang cara mengaktifkan dan meninjau log identitas dan menguji konektivitas. Setelah Anda mengonfirmasi bahwa GKE Identity Service berfungsi seperti yang diharapkan atau Anda mengidentifikasi masalah, tinjau informasi pemecahan masalah OIDC berikut.

Memeriksa spesifikasi OIDC di cluster Anda

Informasi OIDC untuk cluster Anda ditentukan dalam resource ClientConfig dalam namespace kube-public.

Gunakan kubectl get untuk mencetak resource OIDC bagi cluster pengguna Anda:
```
kubectl --kubeconfig KUBECONFIG -n kube-public get \
  clientconfig.authentication.gke.io default -o yaml
```
Ganti KUBECONFIG dengan jalur ke file cluster pengguna Anda.
Tinjau nilai kolom untuk mengonfirmasi bahwa spesifikasi telah dikonfigurasi dengan benar untuk penyedia OIDC Anda.
Jika Anda mengidentifikasi masalah konfigurasi dalam spesifikasi, konfigurasi ulang OIDC.
Jika Anda tidak dapat mendiagnosis dan menyelesaikan masalah ini sendiri, hubungi dukungan Google Cloud.

Dukungan Google Cloud memerlukan Log Layanan Identitas GKE dan spesifikasi OIDC untuk mendiagnosis dan menyelesaikan masalah OIDC.

Memverifikasi bahwa autentikasi OIDC diaktifkan

Sebelum menguji autentikasi OIDC, pastikan autentikasi OIDC diaktifkan di cluster Anda.

Periksa log GKE Identity Service:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
Contoh output berikut menunjukkan bahwa autentikasi OIDC diaktifkan dengan benar:
```
...
I1011 22:14:21.684580      33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started.
...
```
Jika autentikasi OIDC tidak diaktifkan dengan benar, error yang mirip dengan contoh berikut akan ditampilkan:
```
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
```
Tinjau error tertentu yang dilaporkan dan coba perbaiki.

Menguji autentikasi OIDC

Untuk menggunakan fitur OIDC, gunakan workstation dengan UI dan browser diaktifkan. Anda tidak dapat melakukan langkah-langkah ini dari sesi SSH berbasis teks. Untuk menguji apakah OIDC berfungsi dengan benar di cluster Anda, selesaikan langkah-langkah berikut:

Download Google Cloud CLI.
Untuk membuat file konfigurasi login, jalankan perintah gcloud anthos create-login-config berikut:
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Ganti KUBECONFIG dengan jalur ke file cluster pengguna Anda.
Untuk mengautentikasi pengguna, jalankan perintah berikut:
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
Ganti kode berikut:
- CLUSTER_NAME dengan nama cluster pengguna Anda yang akan dihubungkan.
- AUTH_KUBECONFIG dengan file kubeconfig baru untuk dibuat yang mencakup kredensial untuk mengakses cluster Anda. Untuk mengetahui informasi selengkapnya, lihat Mengautentikasi ke cluster.
Anda akan menerima halaman izin login yang terbuka di browser web default di komputer lokal Anda. Berikan informasi autentikasi yang valid untuk pengguna dalam perintah login ini.

Setelah Anda berhasil menyelesaikan langkah login sebelumnya, file kubeconfig akan dibuat di direktori Anda saat ini.
Untuk menguji file kubeconfig baru yang menyertakan kredensial Anda, cantumkan Pod di cluster pengguna Anda:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Ganti AUTH_KUBECONFIG dengan jalur ke file kubeconfig baru yang dibuat pada langkah sebelumnya.

Pesan contoh berikut mungkin ditampilkan yang menunjukkan bahwa Anda dapat berhasil mengautentikasi, tetapi tidak ada role-based access control (RBAC) yang ditetapkan ke akun:
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Meninjau log autentikasi OIDC

Jika Anda tidak dapat melakukan autentikasi dengan OIDC, log GKE Identity Service akan memberikan informasi yang paling relevan dan berguna untuk men-debug masalah.

Gunakan kubectl logs untuk mencetak log GKE Identity Service:
```
kubectl --kubeconfig KUBECONFIG \
  -n anthos-identity-service logs \
  deployment/ais --all-containers=true
```
Ganti KUBECONFIG dengan jalur ke file cluster pengguna Anda.
Tinjau log untuk menemukan error yang dapat membantu Anda mendiagnosis masalah OIDC.

Misalnya, resource ClientConfig mungkin salah ketik di kolom issuerURL, misalnya htps://accounts.google.com (tidak memiliki t dalam https). Log GKE Identity Service akan berisi entri seperti contoh berikut:
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
Jika Anda mengidentifikasi masalah konfigurasi dalam log, Konfigurasi ulang OIDC dan perbaiki masalah konfigurasi.
Jika Anda tidak dapat mendiagnosis dan menyelesaikan masalah sendiri, hubungi dukungan Google Cloud. Dukungan Google Cloud memerlukan log GKE Identity Service dan spesifikasi OIDC untuk mendiagnosis dan menyelesaikan masalah OIDC.

Masalah umum OIDC

Jika Anda mengalami masalah dengan autentikasi OIDC, tinjau masalah umum berikut. Ikuti panduan tentang cara menyelesaikan masalah tersebut.

Tidak ada endpoint yang tersedia untuk layanan "ais"

Saat Anda menyimpan resource ClientConfig, pesan error berikut akan muncul:

  Error from server (InternalError): Internal error occurred: failed calling webhook "clientconfigs.validation.com":
  failed to call webhook: Post "https://ais.anthos-identity-service.svc:15000/admission?timeout=10s":
  no endpoints available for service "ais"

Error ini disebabkan oleh endpoint GKE Identity Service yang tidak responsif. Pod Layanan Identitas GKE tidak dapat menyalurkan webhook validasi.

Untuk mengonfirmasi bahwa Pod GKE Identity Service tidak responsif, jalankan perintah berikut:
```
kubectl get pods -n anthos-identity-service \
  --kubeconfig KUBECONFIG
```
Ganti KUBECONFIG dengan jalur ke file cluster pengguna Anda.

Contoh output berikut menunjukkan bahwa Pod GKE Identity Service Anda mengalami error:
```
NAME                  READY  STATUS            RESTARTS  AGE
ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s
```

Untuk memahami alasan Pod mengalami masalah, lihat peristiwa Pod:

kubectl describe pod -l k8s-app=ais \
  -n anthos-identity-service \
  --kubeconfig KUBECONFIG

Ganti KUBECONFIG dengan jalur ke file cluster pengguna Anda.

Contoh output berikut melaporkan error izin saat menarik image:

Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned anthos-identity-service/ais-5949d879cd-flv9w to pool-1-76bbbb8798-dknz5
  Normal   Pulling    8m23s (x4 over 10m)     kubelet            Pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"
  Warning  Failed     8m21s (x4 over 10m)     kubelet            Failed to pull image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": failed to resolve reference "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": pulling from host gcr.io failed with status code [manifests hybrid_identity_charon_20220808_2319_RC00]: 401 Unauthorized
  Warning  Failed     8m21s (x4 over 10m)     kubelet            Error: ErrImagePull
  Warning  Failed     8m10s (x6 over 9m59s)   kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m49s (x21 over 9m59s)  kubelet            Back-off pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"

Jika peristiwa Pod melaporkan masalah, lanjutkan pemecahan masalah di area yang terpengaruh. Jika Anda memerlukan bantuan tambahan, hubungi Dukungan Google Cloud.

Gagal membaca byte respons dari server

Anda mungkin melihat error berikut di log GKE Identity Service:

  E0516 07:24:38.314681      65 oidc_client.cc:207] Failed fetching the Discovery URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/.well-known/openid-configuration" with error:
  Failed reading response bytes from server.

  E0516 08:24:38.446504      65 oidc_client.cc:223] Failed to fetch the JWKs URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/certs" with error:
  Failed reading response bytes from server.

Error jaringan ini mungkin muncul di log dengan salah satu cara berikut:

Muncul di log dengan jarang: Error cadangan mungkin bukan masalah utama, dan dapat menjadi masalah jaringan yang berselang-seling.

Plugin OIDC GKE Identity Service memiliki proses daemon untuk menyinkronkan URL penemuan OIDC secara berkala setiap 5 detik. Jika koneksi jaringan tidak stabil, permintaan traffic keluar ini mungkin akan gagal. Kegagalan sesekali tidak memengaruhi autentikasi OIDC. Data yang sudah di-cache dapat digunakan kembali.

Jika Anda menemukan error cadangan di log, lanjutkan dengan langkah-langkah pemecahan masalah tambahan.
Selalu muncul di log, atau Layanan Identitas GKE tidak pernah berhasil menjangkau endpoint yang terkenal: Masalah konstan ini menunjukkan masalah konektivitas antara Layanan Identitas GKE dan penyedia identitas OIDC Anda.

Langkah-langkah pemecahan masalah berikut dapat membantu mendiagnosis masalah konektivitas ini:
1. Pastikan firewall tidak memblokir permintaan keluar dari GKE Identity Service.
2. Pastikan server penyedia identitas berjalan dengan benar.
3. Pastikan URL penerbit OIDC di resource ClientConfig dikonfigurasi dengan benar.
4. Jika Anda mengaktifkan kolom proxy di resource ClientConfig, tinjau status atau log server proxy keluar Anda.
5. Uji konektivitas antara pod GKE Identity Service dan server penyedia identitas OIDC.

Anda harus masuk ke server (Tidak sah)

Saat mencoba login menggunakan autentikasi OIDC, Anda mungkin menerima pesan error berikut:

  You must be logged in to the server (Unauthorized)

Error ini adalah masalah autentikasi Kubernetes umum yang tidak memberikan informasi tambahan apa pun. Namun, error ini menunjukkan masalah konfigurasi.

Untuk menentukan masalah, tinjau bagian sebelumnya untuk Memeriksa spesifikasi OIDC di cluster dan Mengonfigurasi resource ClientConfig.

Gagal membuat permintaan pengautentikasi webhook

Di log GKE Identity Service, Anda mungkin melihat error berikut:

  E0810 09:58:02.820573       1 webhook.go:127] Failed to make webhook authenticator request:
  error trying to reach service: net/http: TLS handshake timeout

Error ini menunjukkan bahwa server API tidak dapat terhubung dengan Pod GKE Identity Service.

Untuk memverifikasi apakah endpoint GKE Identity Service dapat dijangkau dari luar, jalankan perintah curl berikut:
```
curl -k  -s -o /dev/null -w "%{http_code}" -X POST \
  https://APISERVER_HOST/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
```
Ganti APISERVER_HOST dengan alamat server API Anda.

Respons yang diharapkan adalah kode status HTTP 400. Jika waktu permintaan habis, mulai ulang Pod Layanan Identitas GKE. Jika error berlanjut, artinya server HTTP GKE Identity Service gagal dimulai. Untuk mendapatkan bantuan tambahan, hubungi Dukungan Google Cloud.

URL login tidak ditemukan

Masalah berikut terjadi saat Konsol Google Cloud tidak dapat menjangkau penyedia identitas. Percobaan login akan dialihkan ke halaman dengan error URL not found.

Untuk mengatasi masalah ini, tinjau langkah-langkah pemecahan masalah berikut. Setelah melakukan setiap langkah, coba login lagi:

Jika penyedia identitas tidak dapat dijangkau melalui internet publik, aktifkan proxy HTTP OIDC untuk login menggunakan Konsol Google Cloud. Edit resource kustom ClientConfig dan tetapkan useHTTPProxy ke true:
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
Ganti USER_CLUSTER_KUBECONFIG dengan jalur ke file kubeconfig cluster pengguna Anda.
Jika proxy HTTP diaktifkan dan Anda masih mengalami error ini, mungkin ada masalah saat memulai proxy. Lihat log proxy:
```
kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
```
Ganti USER_CLUSTER_KUBECONFIG dengan jalur ke file kubeconfig cluster pengguna Anda.

Meskipun penyedia identitas Anda memiliki CA yang dikenal, Anda harus memberikan nilai untuk oidc.caPath dalam resource kustom ClientConfig agar proxy HTTP berhasil dimulai.
Jika server otorisasi meminta izin, dan Anda belum menyertakan parameter prompt=consent extraparam, edit resource kustom ClientConfig, lalu tambahkan prompt=consent ke parameter extraparams:
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
Ganti USER_CLUSTER_KUBECONFIG dengan jalur ke file kubeconfig cluster pengguna Anda.
Jika setelan konfigurasi diubah di layanan penyimpanan, Anda mungkin perlu logout secara eksplisit dari sesi yang ada. Di konsol Google Cloud, buka halaman detail cluster, lalu pilih Log out.

Memecahkan masalah LDAP

Jika mengalami masalah dengan autentikasi LDAP, pastikan Anda telah menyiapkan lingkungan Anda dengan mengikuti salah satu dokumen konfigurasi yang sesuai:

Anda juga harus memastikan bahwa Anda mengisi rahasia akun layanan LDAP dan telah mengonfigurasi resource ClientConfig untuk mengaktifkan autentikasi LDAP.

Baca panduan pemecahan masalah penyedia identitas GKE Identity Service untuk mengetahui informasi tentang cara mengaktifkan dan meninjau log identitas dan menguji konektivitas. Setelah mengonfirmasi bahwa GKE Identity Service berfungsi seperti yang diharapkan atau Anda mengidentifikasi masalah, tinjau informasi pemecahan masalah LDAP berikut.

Memverifikasi bahwa autentikasi LDAP diaktifkan

Sebelum menguji autentikasi LDAP, pastikan autentikasi LDAP diaktifkan di cluster Anda.

Periksa log GKE Identity Service:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
Contoh output berikut menunjukkan bahwa autentikasi LDAP diaktifkan dengan benar:
```
...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...
```
Jika autentikasi LDAP tidak diaktifkan dengan benar, error yang mirip dengan contoh berikut akan ditampilkan:
```
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
```
Tinjau error tertentu yang dilaporkan dan coba perbaiki.

Menguji autentikasi LDAP

Untuk menggunakan fitur LDAP, gunakan workstation dengan UI dan browser diaktifkan. Anda tidak dapat melakukan langkah-langkah ini dari sesi SSH berbasis teks. Untuk menguji apakah autentikasi LDAP berfungsi dengan benar di cluster Anda, selesaikan langkah-langkah berikut:

Download Google Cloud CLI.
Untuk membuat file konfigurasi login, jalankan perintah gcloud anthos create-login-config berikut:
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Ganti KUBECONFIG dengan jalur ke file cluster pengguna Anda.
Untuk mengautentikasi pengguna, jalankan perintah berikut:
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
Ganti kode berikut:
- CLUSTER_NAME dengan nama cluster pengguna Anda yang akan dihubungkan.
- AUTH_KUBECONFIG dengan file kubeconfig baru untuk membuat file yang menyertakan kredensial untuk mengakses cluster Anda. Untuk mengetahui informasi selengkapnya, lihat Mengautentikasi ke cluster.
Anda akan menerima halaman izin login yang terbuka di browser web default di komputer lokal Anda. Berikan informasi autentikasi yang valid untuk pengguna dalam perintah login ini.

Setelah Anda berhasil menyelesaikan langkah login sebelumnya, file kubeconfig akan dibuat di direktori Anda saat ini.
Untuk menguji file kubeconfig baru yang menyertakan kredensial Anda, cantumkan Pod di cluster pengguna Anda:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Ganti AUTH_KUBECONFIG dengan jalur ke cluster pengguna Anda kubeconfig yang dibuat pada langkah sebelumnya.
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Masalah umum LDAP

Jika Anda mengalami masalah dengan autentikasi LDAP, tinjau masalah umum berikut. Ikuti panduan tentang cara menyelesaikan masalah tersebut.

Pengguna tidak dapat mengautentikasi dengan koma di CN mereka

Saat menggunakan LDAP, Anda mungkin mengalami masalah saat pengguna tidak dapat melakukan autentikasi jika CN mereka berisi koma, seperti CN="a,b". Jika Anda mengaktifkan log proses debug untuk GKE Identity Service, pesan error berikut akan dilaporkan:

  I0207 20:41:32.670377 30 authentication_plugin.cc:977] Unable to query groups from the LDAP server directory.example.com:636, using the LDAP service account
  'CN=svc.anthos_dev,OU=ServiceAccount,DC=directory,DC=example,DC=com'.
  Encountered the following error: Empty entries.

Masalah ini terjadi karena plugin LDAP GKE Identity Service meng-escape koma dua kali. Masalah ini hanya terjadi pada versi Google Distributed Cloud Virtual for VMware 1.13 dan yang lebih lama.

Untuk memperbaiki masalah ini, selesaikan salah satu dari langkah berikut:

Upgrade cluster Anda ke Google Distributed Cloud Virtual for VMware 1.13 atau yang lebih baru.
Pilih identifierAttribute yang berbeda, seperti sAMAccountName, bukan menggunakan CN.
Hapus koma dari dalam CN di direktori LDAP.

Kegagalan autentikasi dengan Google Cloud CLI 1.4.2

Dengan Google Cloud CLI anthos-auth 1.4.2, Anda mungkin melihat pesan error berikut saat menjalankan perintah gcloud anthos auth login:

  Error: LDAP login failed: could not obtain an STS token: Post "https://127.0.0.1:15001/sts/v1beta/token":
  failed to obtain an endpoint for deployment anthos-identity-service/ais: Unauthorized
  ERROR: Configuring Anthos authentication failed

Dalam log GKE Identity Service, Anda juga melihat error berikut:

  I0728 12:43:01.980012      26 authentication_plugin.cc:79] Stopping STS   authentication, unable to decrypt the STS token:
  Decryption failed, no keys in the current key set could decrypt the payload.

Untuk mengatasi error ini, selesaikan langkah-langkah berikut:

Periksa apakah Anda menggunakan Google Cloud CLI anthos-auth versi 1.4.2:
```
gcloud anthos auth version
```
Contoh output berikut menunjukkan bahwa versi tersebut adalah 1.4.2:
```
Current Version: v1.4.2
```
Jika Anda menjalankan Google Cloud CLI anthos-auth versi 1.4.2, upgrade ke versi 1.4.3 atau yang lebih baru.

Masalah umum

Bagian ini menjelaskan masalah autentikasi umum dan cara mengatasinya.

Kehilangan akses ke workstation admin karena error `permission denied` kunci SSH

Error berikut terjadi saat Anda mencoba terhubung ke workstation admin dan menerima pesan "Permission denied" yang mirip dengan contoh berikut:

Authorized users only. All activity may be monitored and reported.
TARGET_MACHINE: Permission denied (publickey).

Error ini terjadi karena penggunaan kunci pribadi yang salah, atau tanpa kunci, saat Anda terhubung ke workstation admin menggunakan SSH.

Untuk mengatasi masalah ini, temukan dan gunakan kunci SSH yang benar. Jika Anda tidak dapat menemukan kunci SSH yang benar, buat pasangan kunci SSH baru untuk workstation admin menggunakan langkah-langkah berikut:

Buat VM penyelamatan sementara. VM penyelamatan ini harus terhubung ke Jaringan dan Datastore yang sama dengan VM workstation admin saat ini.
Matikan VM workstation admin dan rescue VM.
Pasang disk data VM workstation admin ke rescue VM. Disk data umumnya berukuran 512 MB, kecuali jika Anda menentukan ukuran disk yang berbeda dalam file konfigurasi workstation admin, yang berbeda dengan boot disk.
Nyalakan Rescue VM.
Hubungkan ke VM penyelamatan menggunakan SSH.
Di komputer lokal Anda, buat pasangan kunci SSH baru.
Di komputer lokal Anda, salin kunci publik SSH yang baru ke rescue VM menggunakan perintah ssh-copy-id:
```
ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM
```
Ganti kode berikut:
- NEW_SSH_KEY dengan nama kunci SSH baru yang Anda buat di langkah sebelumnya.
- RESCUE_VM dengan alamat IP atau FQDN VM penyelamatan Anda.
Di rescue VM, pasang disk data di rescue VM:
```
sudo mkdir -p /mnt/ext-disk
sudo mount DEVICE /mnt/ext-disk
```
Ganti DEVICE dengan ID unik disk Anda sendiri, seperti /dev/sdb1.
Di rescue VM, salin kunci publik SSH baru ke dalam file authorized_keys di disk data yang terpasang dari VM workstation admin Anda.

Lihat konten file authorized_keys di rescue VM, yang menyertakan kunci publik SSH baru yang disalin menggunakan perintah ssh-copy-id pada langkah sebelumnya:
```
ls ~/.ssh/authorized_keys
```
Salin entri kunci publik SSH terakhir dari file authorized_keys, lalu tutup file tersebut.
Edit file authorized_keys pada disk data yang terpasang dari VM workstation admin Anda:
```
vi /mnt/ext-disk/.ssh/authorized_keys
```
Tempel konten kunci publik SSH dari file authorized_keys rescue VM Anda.
Simpan dan tutup file authorized_keys di disk data yang terpasang dari VM workstation admin Anda.

Pastikan file di /mnt/ext-disk/.ssh/ telah menerapkan izin yang benar:

chown -R ubuntu /mnt/ext-disk/.ssh/*
chmod -R 600 /mnt/ext-disk/.ssh/*

Tutup koneksi SSH Anda ke Rescue VM.
Matikan VM penyelamatan.
Lepaskan disk data dari rescue VM dan pasang kembali disk ke VM workstation admin.
Nyalakan workstation admin.
Setelah VM berhasil berjalan, hubungkan ke workstation admin menggunakan SSH dan pasangan kunci SSH baru.
```
ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM
```
Ganti kode berikut:
- NEW_SSH_KEY dengan nama kunci SSH baru yang Anda buat di langkah sebelumnya dan disalin ke VM workstation admin.
- RESCUE_VM dengan alamat IP atau FQDN VM workstation admin Anda.
Pastikan Anda berhasil terhubung menggunakan SSH.
Menghapus rescue VM.

Langkah selanjutnya