Memecahkan masalah autentikasi Google Distributed Cloud

Dokumen ini membantu memecahkan masalah autentikasi di Google Distributed Cloud. Informasi dan panduan pemecahan masalah umum disediakan, beserta dengan informasi spesifik terkait OpenID Connect (OIDC) dan Lightweight Directory Access Protokol (LDAP).

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

Ulas Panduan pemecahan masalah penyedia identitas GKE Identity Service untuk mendapatkan informasi tentang cara mengaktifkan dan meninjau log identitas serta menguji konektivitas.

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.

Pemecahan masalah umum

Kiat pemecahan masalah berikut dapat membantu otentikasi umum dan otorisasi pada Google Distributed Cloud. Jika masalah ini tidak terjadi atau Anda memiliki masalah dengan OIDC atau LDAP, lanjutkan ke bagian tentang pemecahan masalah GKE Identity Service.

Pastikan gcloud anthos auth selalu diupdate

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

Ada dua bagian yang harus diverifikasi. gcloud anthos auth perintah ini memiliki logika di komponen inti Google Cloud CLI, dan instance komponen anthos-auth yang dipaketkan.

  1. Untuk mengupdate Google Cloud CLI:

    gcloud components update

  2. Untuk mengupdate komponen anthos-auth:

    gcloud components install anthos-auth

Konfigurasi penyedia tidak valid

Jika konfigurasi penyedia identitas Anda tidak valid, Anda akan melihat error dari penyedia identitas Anda setelah Anda mengklik LOGIN. Ikuti petunjuk khusus penyedia untuk mengonfigurasi penyedia atau cluster Anda.

Konfigurasi tidak valid

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

Izin tidak valid

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

Token refresh tidak ada

Masalah berikut terjadi saat server otorisasi meminta izin, tetapi parameter otentikasi yang diperlukan tidak disediakan.

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

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

Token refresh sudah tidak berlaku

Masalah berikut terjadi saat token refresh di file kubeconfig memiliki kedaluwarsa:

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

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

Proses login autentikasi gcloud anthos gagal dengan proxyconnect tcp

Masalah ini terjadi saat terjadi error di https_proxy atau HTTPS_PROXY konfigurasi variabel lingkungan tertentu. Jika ada https:// yang ditentukan dalam variabel lingkungan yang berbeda, maka pustaka klien HTTP GoLang mungkin akan gagal jika {i>proxy<i} 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 lingkungan https_proxy dan HTTPS_PROXY variabel untuk menghilangkan https:// prefix. Pada Windows, modifikasi sistem variabel lingkungan. Misalnya, ubah nilai https_proxy variabel lingkungan dari https://webproxy.example.com:8000 hingga 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 mengizinkan . Hal ini dapat terjadi jika RBAC yang tepat tidak ada atau salah, atau terjadi error pada konfigurasi OIDC untuk cluster. Hal berikut contoh error mungkin ditampilkan:

Unauthorized

Untuk mengatasi masalah ini, selesaikan beberapa langkah berikut:

  1. Di file kubeconfig yang dibuat oleh gcloud anthos auth login, salin senilai id-token.

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

  2. Instal jwt-cli dan jalankan:

    jwt ID_TOKEN

  3. Verifikasi konfigurasi OIDC.

    Resource ClientConfig memiliki kolom group dan username. Ini kolom digunakan untuk menetapkan --oidc-group-claim dan --oidc-username-claim pada server Kubernetes API. Saat server API diberikan token ini, token ini akan meneruskan token ke GKE Identity Service, yang menampilkan mengekstrak group-claim dan username-claim kembali ke server API. API server menggunakan respons untuk memverifikasi bahwa grup atau pengguna yang sesuai telah izin akses yang benar.

    Verifikasi bahwa klaim ditetapkan untuk group dan user di ClientConfig resource ada dalam token ID.

  4. Periksa RBAC yang diterapkan.

    Verifikasi bahwa ada RBAC dengan izin yang benar untuk pengguna ditentukan oleh username-claim atau salah satu grup yang mencantumkan group-claim dari langkah sebelumnya. Nama pengguna atau grup di RBAC harus diawali dengan usernameprefix atau groupprefix yang telah ditentukan dalam Resource ClientConfig.

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

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

    Referensi 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 pod-reader kepada grup ini dan pengguna peran cluster. Perhatikan garis miring tunggal di kolom nama, bukan tanda ganda garis miring:

    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

  5. Periksa log server Kubernetes API.

    Jika plugin OIDC yang dikonfigurasi di server Kubernetes API tidak dapat dijalankan dengan benar, server API akan menampilkan error Unauthorized 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 Anda untuk lihat log.
    • ADMIN_CLUSTER_KUBECONFIG: Cluster admin {i>kubeconfig<i}.

gkectl create-login-config gagal mendapatkan clientconfig

Masalah ini terjadi ketika file {i>kubeconfig<i} diteruskan ke gkectl create-login-config bukan untuk cluster pengguna atau ClientConfig resource 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 :

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

Ganti USER_CLUSTER_KUBECONFIG dengan jalur ke pengguna Anda file kubeconfig cluster.

Create-login-config gkectl gagal karena nama cluster duplikat

Masalah ini terjadi jika Anda mencoba menulis data konfigurasi login yang berisi nama cluster yang sudah ada di file tujuan. Setiap login file konfigurasi 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 tujuan baru .

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

Memecahkan masalah OIDC

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

Ulas Panduan pemecahan masalah penyedia identitas GKE Identity Service untuk mendapatkan informasi tentang cara mengaktifkan dan meninjau log identitas serta menguji konektivitas. Setelah Anda mengonfirmasi bahwa GKE Identity Service berfungsi seperti yang identifikasi masalah, tinjau informasi pemecahan masalah OIDC berikut.

Memeriksa spesifikasi OIDC di cluster Anda

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

  1. 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 cluster pengguna Anda {i>kubeconfig<i}.

  2. Tinjau nilai kolom untuk memastikan spesifikasi telah dikonfigurasi dengan benar untuk penyedia OIDC Anda.

  3. Jika Anda mengidentifikasi masalah konfigurasi dalam spesifikasi, mengonfigurasi ulang OIDC.

  4. Jika Anda tidak dapat mendiagnosis dan menyelesaikan masalah sendiri, berinteraksi dengan dukungan Google Cloud.

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

Memverifikasi bahwa autentikasi OIDC sudah aktif

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

  1. Periksa log GKE Identity Service:

    kubectl logs -l k8s-app=ais -n anthos-identity-service

    Contoh output berikut menunjukkan bahwa autentikasi OIDC sudah benar diaktifkan:

    ...
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 ditampilkan:

    Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:

    Tinjau error spesifik yang dilaporkan dan coba perbaiki.

Menguji autentikasi OIDC

Untuk menggunakan fitur OIDC, gunakan workstation yang mengaktifkan UI dan browser. 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:

  1. Download Google Cloud CLI.

  2. Untuk membuat file konfigurasi login, jalankan perintah berikut gcloud anthos create-login-config berikut:

    gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG

    Ganti KUBECONFIG dengan jalur ke cluster pengguna Anda {i>kubeconfig<i}.

  3. 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 untuk hubungkan.
    • AUTH_KUBECONFIG dengan file kubeconfig baru untuk membuat yang mencakup kredensial untuk mengakses cluster Anda. Untuk selengkapnya informasi, lihat Autentikasi ke cluster.

  4. Anda akan menerima halaman izin login yang terbuka di browser web default {i>workstation<i} lokal Anda. Berikan informasi otentikasi yang valid untuk pengguna yang berada di perintah login ini.

    Setelah Anda berhasil menyelesaikan langkah login sebelumnya, file kubeconfig akan dibuat di direktori Anda saat ini.

  5. 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 jalur baru file {i>kubeconfig<i} yang dibuat pada langkah sebelumnya.

    Contoh pesan berikut mungkin ditampilkan yang menunjukkan bahwa Anda dapat berhasil diotentikasi, 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

Tinjau log autentikasi OIDC

Jika Anda tidak dapat melakukan autentikasi dengan OIDC, GKE Identity Service akan mencatat log memberikan informasi yang paling relevan dan berguna untuk {i>debugging<i} masalah.

  1. 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 cluster pengguna Anda {i>kubeconfig<i}.

  2. Tinjau log untuk menemukan error yang dapat membantu Anda mendiagnosis masalah OIDC.

    Misalnya, mungkin ada kesalahan ketik pada resource ClientConfig di issuerURL seperti htps://accounts.google.com (tidak ada t dalam https). Tujuan Log GKE Identity Service akan berisi entri seperti berikut contoh:

    OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.

  3. Jika Anda mengidentifikasi masalah konfigurasi di log, Mengonfigurasi ulang OIDC dan memperbaiki masalah konfigurasi.

  4. 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 masalah performa. Ikuti panduan cara menyelesaikan masalah tersebut.

Tidak ada endpoint yang tersedia untuk layanan "ais"

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

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

  1. Untuk mengonfirmasi bahwa GKE Identity Service Pod tidak responsif, jalankan perintah berikut:

    kubectl get pods -n anthos-identity-service \
  --kubeconfig KUBECONFIG

    Ganti KUBECONFIG dengan jalur ke cluster pengguna Anda {i>kubeconfig<i}.

    Contoh output berikut menunjukkan bahwa GKE Identity Service Pod Anda gak jalan:

    NAME                  READY  STATUS            RESTARTS  AGE
ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s

  2. Untuk memahami alasan Pod memiliki masalah, lihat peristiwa Pod:

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

    Ganti KUBECONFIG dengan jalur ke cluster pengguna Anda {i>kubeconfig<i}.

    Contoh output berikut melaporkan error izin saat menarik 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"

  3. Jika peristiwa Pod melaporkan masalah, lanjutkan pemecahan masalah di area yang terpengaruh area tersebut. Jika Anda membutuhkan 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 jarang di log: Error cadangan kemungkinan bukan masalah utama, dan bisa berupa masalah jaringan yang terputus-putus.

    Plugin GKE Identity Service OIDC memiliki proses daemon untuk menyinkronkan URL penemuan OIDC secara berkala setiap 5 detik. Jika koneksi jaringan tidak stabil, permintaan keluar ini mungkin gagal. Jarang kegagalannya tidak mempengaruhi otentikasi OIDC. Data dalam {i>cache<i} yang ada dapat digunakan kembali.

    Jika Anda menemukan error cadangan di log, lanjutkan dengan langkah-langkah pemecahan masalah.

  • Muncul terus-menerus di log, atau GKE Identity Service tidak pernah berhasil mencapai endpoint yang dikenal: Masalah konstan ini menunjukkan masalah konektivitas antara GKE Identity Service dan OIDC Anda penyedia identitas.

    Langkah pemecahan masalah berikut dapat membantu mendiagnosis konektivitas tersebut masalah:

    1. Pastikan bahwa {i>firewall<i} tidak memblokir permintaan keluar dari GKE Identity Service.
    2. Pastikan server penyedia identitas berjalan dengan benar.
    3. Pastikan URL penerbit OIDC di resource ClientConfig sudah dikonfigurasi dengan benar.
    4. Jika Anda mengaktifkan kolom proxy di resource ClientConfig, tinjau status atau log server proxy keluar Anda.
    5. Menguji konektivitas antara pod GKE Identity Service dan server penyedia identitas OIDC.

Anda harus login ke server (Tidak sah)

Saat Anda 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. Tetapi, {i>error<i} ini menunjukkan adanya konfigurasi masalah.

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

Gagal membuat permintaan pengautentikasi webhook

Dalam 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

Kesalahan ini menunjukkan bahwa server API tidak dapat membuat koneksi dengan Pod GKE Identity Service.

  1. Untuk memverifikasi apakah endpoint GKE Identity Service dapat dijangkau dari di 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 API Anda server tertentu.

    Respons yang diharapkan adalah kode status HTTP 400. Jika waktu permintaan habis, memulai ulang GKE Identity Service Pod. Jika {i>error<i} masih berlanjut, server HTTP GKE Identity Service gagal dimulai. Untuk tambahan bantuan, hubungi Dukungan Google Cloud.

URL login tidak ditemukan

Masalah berikut terjadi saat Konsol Google Cloud tidak dapat menjangkau identitas penyedia layanan. Upaya untuk login dialihkan ke halaman dengan URL not found {i>error<i}.

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

  1. Jika Penyedia Identitas tidak dapat dijangkau melalui internet publik, aktifkan Proxy HTTP OIDC untuk login menggunakan Konsol Google Cloud. Edit ClientConfig resource kustom 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.

  2. Jika {i>proxy<i} HTTP diaktifkan dan Anda masih mengalami {i>error<i} ini, mungkin ada ada masalah ketika {i>proxy<i} 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.

    Meskipun penyedia identitas Anda memiliki CA yang sudah dikenal, Anda harus memberikan nilai untuk oidc.caPath dalam resource khusus ClientConfig Anda untuk proxy HTTP agar berhasil dimulai.

  3. Jika server otorisasi meminta izin, dan Anda belum menyertakan parameter extraparam prompt=consent, edit parameter kustom ClientConfig resource, dan 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.

  4. Jika pengaturan konfigurasi diubah pada layanan penyimpanan, Anda mungkin perlu secara eksplisit logout dari sesi yang ada. Di Konsol Google Cloud, buka halaman detail cluster, lalu pilih Logout.

Memecahkan masalah LDAP

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

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

Ulas Panduan pemecahan masalah penyedia identitas GKE Identity Service untuk mendapatkan informasi tentang cara mengaktifkan dan meninjau log identitas serta menguji konektivitas. Setelah Anda mengonfirmasi bahwa GKE Identity Service berfungsi seperti yang mengidentifikasi masalah, tinjau informasi pemecahan masalah LDAP berikut ini.

Memverifikasi bahwa autentikasi LDAP diaktifkan

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

  1. Periksa log GKE Identity Service:

    kubectl logs -l k8s-app=ais -n anthos-identity-service

    Contoh {i>output<i} berikut menunjukkan bahwa otentikasi LDAP sudah benar diaktifkan:

    ...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...

    Jika otentikasi LDAP tidak diaktifkan dengan benar, error yang mirip dengan contoh berikut ditampilkan:

    Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:

    Tinjau error spesifik yang dilaporkan dan coba perbaiki.

Menguji autentikasi LDAP

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

  1. Download Google Cloud CLI.

  2. Untuk membuat file konfigurasi login, jalankan perintah berikut gcloud anthos create-login-config berikut:

    gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG

    Ganti KUBECONFIG dengan jalur ke cluster pengguna Anda {i>kubeconfig<i}.

  3. 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 untuk hubungkan.
    • AUTH_KUBECONFIG dengan file kubeconfig baru untuk yang mencakup kredensial untuk mengakses cluster Anda. Untuk selengkapnya informasi, lihat Autentikasi ke cluster.

  4. Anda akan menerima halaman izin login yang terbuka di browser web default {i>workstation<i} lokal Anda. Berikan informasi otentikasi yang valid untuk pengguna yang berada di perintah login ini.

    Setelah Anda berhasil menyelesaikan langkah login sebelumnya, file kubeconfig akan dibuat di direktori Anda saat ini.

  5. 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 {i>kubeconfig<i} 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 terkait autentikasi LDAP, tinjau masalah umum berikut masalah performa. Ikuti panduan cara menyelesaikan masalah tersebut.

Pengguna tidak dapat mengautentikasi dengan koma di CN

Saat menggunakan LDAP, Anda mungkin menemui masalah di mana pengguna tidak dapat mengotentikasi jika CN-nya berisi koma, seperti CN="a,b". Jika Anda mengaktifkan log {i>debugging<i} untuk GKE Identity Service, pesan error berikut telah 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 menggandakan escape koma. Masalah ini hanya terjadi pada versi Google Distributed Cloud 1.13 dan sebelumnya.

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

  1. Upgrade cluster Anda ke Google Distributed Cloud 1.13 atau yang lebih baru.
  2. Pilih identifierAttribute yang lain, seperti sAMAccountName, sebagai gantinya menggunakan CN.
  3. 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 error berikut saat Anda 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 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:

  1. 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

  2. Jika Anda menjalankan anthos-auth Google Cloud CLI 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.

Akses ke workstation admin hilang karena kunci SSH permission denied error

Error berikut terjadi saat Anda mencoba terhubung ke workstation admin dan terima 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 tidak ada kunci saat Anda terhubung ke {i>workstation<i} admin menggunakan SSH.

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

  1. Buat VM penyelamatan sementara. VM penyelamatan ini harus terhubung ke Network dan Datastore sebagai VM workstation admin saat ini.

  2. Matikan VM workstation admin dan rescue VM.

  3. Pasang disk data VM workstation admin ke VM penyelamatan. Data biasanya berukuran 512 MB kecuali Anda menentukan ukuran disk yang berbeda file konfigurasi workstation admin, yang berbeda dari {i>boot disk<i}.

  4. Nyalakan rescue VM.

  5. Hubungkan ke rescue VM menggunakan SSH.

  6. Di komputer lokal Anda, membuat pasangan kunci SSH baru.

  7. 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 yang Anda buat di langkah sebelumnya.
    • RESCUE_VM dengan alamat IP atau FQDN Anda rescue VM.

  8. 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 Anda sendiri seperti /dev/sdb1.

  9. Di VM penyelamatan, salin kunci publik SSH yang baru ke authorized_keys ke 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 di langkah sebelumnya:

    ls ~/.ssh/authorized_keys

    Salin entri kunci publik SSH terakhir dari file authorized_keys, lalu menutup file tersebut.

  10. Edit file authorized_keys di disk data yang terpasang dari admin Anda VM workstation:

    vi /mnt/ext-disk/.ssh/authorized_keys

    Tempel konten kunci publik SSH dari file authorized_keys pada VM penyelamatan Anda.

  11. Simpan dan tutup file authorized_keys pada disk data yang terpasang dari VM workstation admin.

  12. Pastikan file di /mnt/ext-disk/.ssh/ memiliki izin yang benar yang diterapkan pada aset tersebut:

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

  13. Keluar dari koneksi SSH ke rescue VM.

  14. Matikan rescue VM.

  15. Lepaskan disk data dari rescue VM, lalu pasang kembali disk ke VM workstation admin.

  16. Nyalakan workstation admin.

  17. Setelah VM berhasil berjalan, hubungkan ke workstation admin menggunakan SSH dan pasangan kunci SSH yang baru.

    ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM

    Ganti kode berikut:

    • NEW_SSH_KEY dengan nama kunci SSH baru yang yang Anda buat di langkah sebelumnya dan menyalin ke VM workstation admin.
    • RESCUE_VM dengan alamat IP atau FQDN Anda VM workstation admin.

    Pastikan Anda berhasil terhubung menggunakan SSH.

  18. Hapus rescue VM.

Langkah selanjutnya

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.