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 menjalankangcloud 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
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.
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 filekubeconfig
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
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
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.