Cluster Anthos di VMware kini menjadi Google Distributed Cloud (khusus software) untuk VMware. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

Memecahkan masalah autentikasi Google Distributed Cloud

Dokumen ini membantu memecahkan masalah autentikasi di Google Distributed Cloud. Informasi dan panduan pemecahan masalah umum diberikan, beserta informasi khusus untuk OpenID Connect (OIDC) dan Lightweight Directory Access Protocol (LDAP).

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

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

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.

Pemecahan masalah umum

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

Memastikan `gcloud anthos auth` selalu terbaru

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 dipaketkan secara terpisah.

Untuk mengupdate Google Cloud CLI:
```
gcloud components update
```
Untuk memperbarui 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 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 menyelesaikan alur autentikasi, tetapi masih tidak melihat detail cluster, pastikan Anda telah memberikan izin RBAC yang benar ke akun yang Anda gunakan 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, tambahkan prompt=consent ke kolom authentication.oidc.extraParams. Kemudian, buat ulang file autentikasi klien.

Masa berlaku token refresh telah habis

Masalah berikut terjadi saat token refresh dalam file kubeconfig telah berakhir 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.

gcloud anthos auth login gagal dengan `proxyconnect tcp`

Masalah ini terjadi jika ada error dalam konfigurasi variabel lingkungan https_proxy atau HTTPS_PROXY. Jika ada https:// yang ditentukan dalam variabel lingkungan, library klien HTTP GoLang mungkin 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 menghapus 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 saat 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 dihasilkan oleh gcloud anthos auth login, salin nilai id-token.

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

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

Resource ClientConfig memiliki kolom group dan username. Kolom ini digunakan untuk menetapkan flag --oidc-group-claim dan --oidc-username-claim di server Kubernetes API. Saat server API menerima token, server akan meneruskan token ke Layanan Identitas GKE, yang menampilkan group-claim dan username-claim yang 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 satu \ 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 ditampilkan dengan 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 yang log-nya ingin Anda lihat.
- 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. Kemudian, periksa apakah resource ClientConfig ada di cluster:

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

Ganti USER_CLUSTER_KUBECONFIG dengan jalur ke file kubeconfig cluster 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

Jika autentikasi OIDC tidak berfungsi untuk Google Distributed Cloud, biasanya spesifikasi OIDC di resource ClientConfig telah dikonfigurasi dengan tidak benar. Referensi ClientConfig memberikan petunjuk untuk meninjau log dan spesifikasi OIDC guna membantu mengidentifikasi penyebab masalah OIDC.

Tinjau panduan pemecahan masalah penyedia identitas Identity Service GKE untuk mengetahui informasi tentang cara mengaktifkan dan meninjau log identitas serta menguji konektivitas. Setelah mengonfirmasi bahwa Identity Service GKE 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 di namespace kube-public.

Gunakan kubectl get untuk mencetak resource OIDC untuk cluster pengguna Anda:
```
kubectl --kubeconfig KUBECONFIG -n kube-public get \
  clientconfig.authentication.gke.io default -o yaml
```
Ganti KUBECONFIG dengan jalur ke file kubeconfig cluster pengguna Anda.
Tinjau nilai kolom untuk mengonfirmasi bahwa spesifikasi 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 sendiri, hubungi dukungan Google Cloud.

Dukungan Google Cloud memerlukan log Identity Service GKE dan spesifikasi OIDC untuk mendiagnosis dan menyelesaikan masalah OIDC.

Memastikan 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 yang 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 kubeconfig 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 yang akan dihubungkan.
- AUTH_KUBECONFIG dengan file kubeconfig baru yang akan dibuat 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 workstation lokal Anda. Berikan informasi autentikasi yang valid untuk pengguna di perintah login ini.

Setelah Anda berhasil menyelesaikan langkah login sebelumnya, file kubeconfig akan dibuat di direktori 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 di langkah sebelumnya.

Contoh pesan berikut mungkin ditampilkan yang menunjukkan bahwa Anda berhasil melakukan autentikasi, tetapi tidak ada kontrol akses berbasis peran (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 mengautentikasi dengan OIDC, log Identity Service GKE akan memberikan informasi yang paling relevan dan berguna untuk men-debug masalah.

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

Misalnya, resource ClientConfig mungkin memiliki kesalahan ketik di kolom issuerURL, seperti htps://accounts.google.com (tidak ada t di https). Log Layanan Identitas GKE 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 Identity Service GKE dan spesifikasi OIDC untuk mendiagnosis dan menyelesaikan masalah OIDC.

Masalah OIDC umum

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

Tidak ada endpoint yang tersedia untuk layanan "ais"

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

  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 Identity Service GKE yang tidak sehat. Pod Identity Service GKE tidak dapat menayangkan webhook validasi.

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

Contoh output berikut berarti Pod Identity Service GKE Anda 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 kubeconfig cluster pengguna Anda.

Contoh output berikut melaporkan error izin saat mengambil gambar:

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 Identity Service GKE:

  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 dalam log dengan salah satu cara berikut:

Jarang muncul di log: Error cadangan kemungkinan bukan masalah utama, dan mungkin merupakan masalah jaringan yang terputus-putus.

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

Jika Anda menemukan error cadangan dalam log, lanjutkan dengan langkah pemecahan masalah tambahan.
Selalu muncul di log, atau Identity Service GKE tidak pernah berhasil mencapai endpoint yang dikenal: Masalah konstan ini menunjukkan masalah konektivitas antara Identity Service 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 Layanan Identitas GKE.
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 Identity Service GKE dan server penyedia identitas OIDC.

Anda harus login 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 masalahnya, tinjau bagian sebelumnya untuk Memeriksa spesifikasi OIDC di cluster Anda dan Mengonfigurasi resource ClientConfig.

Gagal membuat permintaan pengautentikasi webhook

Di log Identity Service GKE, 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 membuat koneksi dengan Pod Layanan Identitas GKE.

Untuk memverifikasi apakah endpoint Identity Service GKE 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 tunggu permintaan habis, mulai ulang Pod Identity Service GKE. Jika error berlanjut, artinya server HTTP Layanan Identitas GKE gagal dimulai. Untuk bantuan tambahan, hubungi dukungan Google Cloud.

URL login tidak ditemukan

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

Untuk mengatasi masalah ini, tinjau langkah-langkah pemecahan masalah berikut. Setelah 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 proxy dimulai. 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 terkenal, Anda harus memberikan nilai untuk oidc.caPath di resource kustom ClientConfig agar proxy HTTP berhasil dimulai.
Jika server otorisasi meminta izin, dan Anda belum menyertakan parameter extraparam prompt=consent, edit resource kustom ClientConfig, dan tambahkan parameter prompt=consent ke 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 Logout.

Memecahkan masalah LDAP

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

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

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

Memastikan 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 yang 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 kubeconfig 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 yang akan dihubungkan.
- AUTH_KUBECONFIG dengan file kubeconfig baru yang akan dibuat 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 workstation lokal Anda. Berikan informasi autentikasi yang valid untuk pengguna di perintah login ini.

Setelah Anda berhasil menyelesaikan langkah login sebelumnya, file kubeconfig akan dibuat di direktori 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 kubeconfig cluster pengguna yang dibuat di langkah sebelumnya.
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Masalah LDAP umum

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

Pengguna tidak dapat mengautentikasi dengan koma di CN mereka

Saat menggunakan LDAP, Anda mungkin mengalami masalah saat pengguna tidak dapat mengautentikasi 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 Layanan Identitas GKE melakukan escape ganda pada koma. Masalah ini hanya terjadi di versi Google Distributed Cloud 1.13 dan yang lebih lama.

Untuk memperbaiki masalah ini, selesaikan salah satu langkah berikut:

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

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

Di log Identity Service GKE, Anda juga akan 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 anthos-auth Google Cloud CLI versi 1.4.2:
```
gcloud anthos auth version
```
Contoh output berikut menunjukkan bahwa versinya 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 menggunakan kunci pribadi yang salah, atau tidak ada 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 VM penyelamatan.
Pasang disk data VM workstation admin ke VM penyelamatan. Data disk umumnya berukuran 512 MB, kecuali jika Anda menentukan ukuran disk yang berbeda di file konfigurasi workstation admin, yang berbeda dari boot disk.
Aktifkan VM penyelamatan.
Hubungkan ke VM penyelamatan menggunakan SSH.
Di komputer lokal, buat pasangan kunci SSH baru.
Di komputer lokal, salin kunci SSH publik baru ke VM penyelamatan 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 VM penyelamatan, pasang disk data di VM penyelamatan:
```
sudo mkdir -p /mnt/ext-disk
sudo mount DEVICE /mnt/ext-disk
```
Ganti DEVICE dengan ID unik disk Anda sendiri, seperti /dev/sdb1.
Di VM penyelamatan, salin kunci SSH publik baru ke file authorized_keys di disk data yang terpasang dari VM workstation admin Anda.

Lihat konten file authorized_keys di VM penyelamatan, yang menyertakan kunci publik SSH baru yang disalin menggunakan perintah ssh-copy-id di langkah sebelumnya:
```
ls ~/.ssh/authorized_keys
```
Salin entri kunci publik SSH terakhir dari file authorized_keys, lalu tutup file.
Edit file authorized_keys di disk data yang dipasang dari VM workstation admin Anda:
```
vi /mnt/ext-disk/.ssh/authorized_keys
```
Tempel konten kunci publik SSH dari file authorized_keys VM penyelamatan Anda.
Simpan dan tutup file authorized_keys di disk data yang terpasang dari VM workstation admin Anda.
Verifikasi bahwa file di /mnt/ext-disk/.ssh/ memiliki izin yang benar yang diterapkan pada file tersebut:
```
chown -R ubuntu /mnt/ext-disk/.ssh/*
chmod -R 600 /mnt/ext-disk/.ssh/*
```
Keluar dari koneksi SSH ke VM penyelamatan.
Matikan VM penyelamatan.
Lepaskan disk data dari VM penyelamatan 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.
Hapus VM penyelamatan.

Langkah selanjutnya