Menyiapkan akses pengguna untuk GKE Identity Service

Dokumen ini ditujukan untuk administrator cluster yang telah mengonfigurasi cluster untuk GKE Identity Service dengan mengikuti petunjuk dalam Mengonfigurasi cluster untuk GKE Identity Service tingkat fleet atau Mengonfigurasi cluster untuk GKE Identity Service dengan OIDC. Panduan ini menjelaskan cara menyiapkan (dan membatasi) akses ke cluster yang dikonfigurasi untuk developer organisasi Anda dan pengguna cluster lainnya.

Menyiapkan akses login pengguna

Setelah mengonfigurasi cluster, Anda perlu membuat file konfigurasi login dan mendistribusikannya kepada pengguna cluster. Dengan file ini, pengguna dapat login ke cluster dari command line dengan penyedia pilihan Anda, seperti dijelaskan dalam Mengakses cluster dengan GKE Identity Service.

Dengan penyedia OIDC saja, pengguna juga dapat login ke cluster dari Konsol Google Cloud tanpa file login, seperti yang dijelaskan dalam Bekerja dengan cluster dari Konsol Google Cloud.

Membuat konfigurasi login

Konsol

(Khusus Penyiapan tingkat perangkat)

Salin perintah gcloud yang ditampilkan dan jalankan untuk membuat file.

gcloud

Jika Anda mengonfigurasi cluster menggunakan CLI gcloud atau jika Anda perlu membuat file lagi, jalankan perintah berikut untuk membuat file:

gcloud anthos create-login-config --kubeconfig=KUBECONFIG

dengan KUBECONFIG adalah jalur ke file kubeconfig untuk cluster. Jika ada beberapa konteks dalam kubeconfig, konteks saat ini akan digunakan. Anda mungkin perlu mereset konteks saat ini ke cluster yang benar sebelum menjalankan perintah.

Anda dapat melihat detail referensi lengkap untuk perintah ini, termasuk parameter opsional tambahan, di panduan referensi Google Cloud CLI.

Nama default untuk file konfigurasi login adalah kubectl-anthos-config.yaml, yaitu nama yang diharapkan Google Cloud CLI saat menggunakan file untuk login. Jika Anda ingin mengubahnya menjadi nama non-default, lihat bagian yang relevan dalam Mendistribusikan konfigurasi login di bawah.

Untuk memecahkan masalah terkait akses pengguna, lihat Memecahkan masalah akses pengguna.

Mendistribusikan konfigurasi login

Berikut adalah beberapa pendekatan yang memungkinkan untuk mendistribusikan file konfigurasi:

• Hosting file di URL yang dapat diakses. Pengguna dapat menentukan lokasi ini dengan flag --login-config saat menjalankan gcloud anthos auth login, sehingga Google Cloud CLI bisa mendapatkan file tersebut.

  Pertimbangkan untuk menghosting file di host yang aman. Lihat flag --login-config-cert dari gcloud CLI untuk mengetahui informasi lebih lanjut tentang penggunaan sertifikat PEM untuk akses HTTPS yang aman.

• Berikan file secara manual kepada setiap pengguna, dengan informasi tentang tempat untuk menyimpannya di komputer lokal. Google Cloud CLI akan menemukan file tersebut di lokasi default khusus OS. Jika file memiliki nama atau lokasi non-default, pengguna Anda harus menggunakan tanda --login-config untuk menentukan lokasi file konfigurasi saat menjalankan perintah pada cluster. Petunjuk bagi pengguna untuk menyimpan file dapat ditemukan di Cluster akses dengan GKE Identity Service.

• Gunakan alat internal Anda untuk mengirim file konfigurasi autentikasi ke setiap komputer pengguna. Google Cloud CLI mengharapkan file tersebut ditemukan di lokasi berikut, bergantung pada OS pengguna:

  Linux

  $HOME/.config/google/anthos/kubectl-anthos-config.yaml

  macOS

  $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

  Windows

  %APPDATA%\google\anthos\kubectl-anthos-config.yaml

Menyiapkan akses login pengguna melalui proses autentikasi alternatif

Pratinjau

Fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dalam Persyaratan Khusus Layanan. Fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Daripada mendistribusikan file konfigurasi kepada semua pengguna, Anda dapat menyiapkan akses login pengguna menggunakan proses autentikasi alternatif. Pengguna dapat melakukan autentikasi secara langsung di server GKE Identity Service dengan nama domain yang sepenuhnya memenuhi syarat (FQDN). Untuk penyedia SAML, akses login pengguna hanya didukung melalui proses autentikasi alternatif ini.

Catatan: Proses autentikasi alternatif ini didukung untuk GKE di VMware dan GKE pada Bare Metal mulai 1.28. Versi CLI gcloud yang harus Anda upgrade adalah 456.0.0.

Membagikan FQDN kepada pengguna

Sebagai ganti file konfigurasi, administrator cluster dapat membagikan FQDN server GKE Identity Service mereka dengan pengguna. Pengguna dapat menggunakan FQDN ini untuk login ke cluster. URL server GKE Identity Service disediakan dalam salah satu format berikut:

• https://CLUSTER-SERVER-NAME.com
• CLUSTER-SERVER-NAME.com

Akses login pengguna menggunakan sertifikat SNI tepercaya

Sertifikat SNI menyederhanakan akses cluster dengan memanfaatkan sertifikat tepercaya yang sudah ada di perangkat perusahaan. Administrator menggunakan sertifikat ini pada saat pembuatan cluster. Sebagai pengguna, Anda harus menggunakan FQDN yang disediakan oleh administrator untuk login ke cluster. Atau, Anda dapat menggunakan file kubeconfig yang aman tempat token disimpan setelah autentikasi berhasil.

Sebelum menjalankan perintah berikut, pastikan sertifikat yang digunakan oleh server GKE Identity Service dipercaya oleh perangkat tempat aktivitas login pengguna dilakukan.

gcloud anthos auth login --server APISERVER_URL --kubeconfig OUTPUT_FILE

Ganti kode berikut:

• APISERVER_URL: FQDN server GKE Identity Service.
• OUTPUT_FILE: Gunakan tanda ini jika file kubeconfig Anda berada di lokasi selain lokasi default. Jika flag ini dihilangkan, token autentikasi akan ditambahkan ke file kubeconfig di lokasi default. Contoh: --kubeconfig /path/to/custom.kubeconfig.

Akses login pengguna menggunakan sertifikat yang diterbitkan CA cluster

Sebagai pengguna, jika Anda tidak menggunakan sertifikat SNI tepercaya di tingkat cluster, sertifikat yang digunakan oleh layanan identitas akan diterbitkan oleh certificate authority (CA) cluster tersebut. Administrator mendistribusikan sertifikat CA ini kepada pengguna. Jalankan perintah berikut menggunakan sertifikat CA cluster untuk login ke cluster Anda:

gcloud anthos auth login --server APISERVER_URL --kubeconfig OUTPUT_FILE --login-config-cert CLUSTER_CA_CERTIFICATE

Catatan: Sebagai rekomendasi, pengguna dapat memercayai sertifikat CA di perangkat dan browser mereka dengan mengikuti petunjuk khusus perangkat. Aktivitas ini hanya dilakukan satu kali. Setelah sertifikat CA dipercaya, Anda dapat login ke cluster tanpa menentukan argumen --login-config-cert dalam perintah.

Menyiapkan kontrol akses berbasis peran (Role-based access control/RBAC)

Autentikasi sering dikombinasikan dengan Role-based access control (RBAC) Kubernetes untuk memberikan kontrol akses yang lebih mendetail ke cluster bagi pengguna terautentikasi dan akun layanan. Jika memungkinkan, sebaiknya buat kebijakan RBAC yang menggunakan nama grup, bukan ID pengguna. Dengan menautkan kebijakan RBAC secara eksplisit ke grup, Anda dapat mengelola hak istimewa akses pengguna sepenuhnya dengan Penyedia Identitas Anda, sehingga cluster tidak perlu diperbarui setiap kali hak istimewa pengguna berubah. Perlu diperhatikan bahwa untuk mengonfigurasi kontrol akses berdasarkan keanggotaan grup keamanan dengan OIDC, Anda harus memastikan bahwa GKE Identity Service telah disiapkan untuk mendukung pengambilan informasi keanggotaan grup dari penyedia identitas Anda.

Misalnya, jika Anda ingin pengguna terautentikasi tertentu memiliki akses ke Pod cluster, buat ClusterRole yang memberikan akses ke resource ini, seperti dalam contoh berikut:

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

Kemudian, buat ClusterRoleBinding yang sesuai untuk memberikan izin di ClusterRole kepada pengguna yang relevan—dalam hal ini, anggota grup keamanan us-east1-cluster-admins dan pengguna dengan ID u98523-4509823:

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

Catatan: Jika Penyedia Identitas Anda menampilkan nama grup yang berisi karakter garis miring terbalik ganda, salah satu karakter garis miring terbalik harus dihilangkan saat Anda mereferensikan nama grup di resource ClusterRoleBinding. Misalnya, jika Anda telah membuat grup bernama corp\\my-group, referensikan grup tersebut dalam resource ClusterRoleBinding sebagai corp\my-group. Hal ini karena karakter garis miring terbalik pertama diperlakukan sebagai karakter escape.

Pada contoh berikut, ClusterRoleBinding ini memberikan izin di ClusterRole ke grup yang relevan dengan ID 12345678-BBBb-cCCCC-0000-123456789012. Perlu diperhatikan bahwa setelan ini hanya relevan untuk penyedia Azure AD dan tersedia untuk cluster Google Distributed Cloud Virtual untuk Bare Metal.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-reader-binding
subjects:
  # Retrieves group information for the group ID mentioned
- kind: Group
  name: 12345678-BBBb-cCCCC-0000-123456789012
  apiGroup: rbac.authorization.k8s.io

Untuk mengetahui informasi selengkapnya tentang penggunaan RBAC, lihat Mengonfigurasi kontrol akses berbasis peran dan Menggunakan Otorisasi RBAC.

Membuat peran RBAC untuk akses konsol Google Cloud

Pengguna yang diautentikasi menggunakan penyedia OIDC dapat login ke cluster dari konsol Google Cloud serta command line.

Pengguna terautentikasi yang ingin mengakses resource cluster di konsol Google Cloud harus memiliki izin Kubernetes yang relevan untuk melakukannya. Jika tidak ingin memberikan izin yang lebih luas kepada pengguna tersebut, seperti izin admin cluster, Anda dapat membuat peran RBAC kustom yang mencakup izin minimum untuk melihat node, volume persisten, pod, dan kelas penyimpanan cluster. Anda dapat menentukan kumpulan izin ini dengan membuat resource RBAC ClusterRole, cloud-console-reader, dalam cluster.

cloud-console-reader memberikan izin get, list, dan watch kepada penggunanya di node cluster, volume persisten, pod, dan kelas penyimpanan, yang memungkinkan mereka melihat detail tentang resource ini.

kubectl

Untuk membuat cloud-console-reader ClusterRole dan menerapkannya ke cluster, jalankan perintah berikut:

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

Anda kemudian dapat memberikan ClusterRole ini kepada pengguna saat menyiapkan kebijakan izin, seperti yang dijelaskan di bagian sebelumnya. Perlu diingat bahwa pengguna juga memerlukan izin IAM untuk melihat cluster di Konsol Google Cloud.