Workload Identity Federation for GKE adalah cara yang direkomendasikan untuk beban kerja Anda yang berjalan di Google Kubernetes Engine (GKE) untuk mengakses layanan Google Cloud dengan cara yang aman dan terkelola.
Workload Identity Federation for GKE tersedia melalui IAM Workload Identity Federation, yang menyediakan identitas untuk workload yang berjalan di lingkungan di dalam dan di luar Google Cloud. Anda dapat menggunakan IAM Workload Identity Federation untuk melakukan autentikasi dengan aman ke Google Cloud API yang didukung dari workload yang berjalan, misalnya, AWS, Azure, dan Kubernetes yang dikelola sendiri. Di GKE, Google Cloud mengelola kumpulan dan penyedia workload identity untuk Anda dan tidak memerlukan penyedia identitas eksternal.
- Untuk mempelajari Workload Identity Federation di lingkungan lain, lihat Workload Identity Federation.
- Untuk mengaktifkan dan menggunakan Workload Identity Federation for GKE, lihat Mengakses Google Cloud API dari workload GKE.
- Untuk memberikan dukungan Workload Identity Federation bagi cluster dalam fleet, gunakan fleet workload identity.
Terminologi
Dokumen ini membedakan antara akun layanan Kubernetes dan akun layanan Identity and Access Management (IAM).
- Akun layanan Kubernetes
- Resource Kubernetes yang memberikan identitas untuk proses yang berjalan di pod GKE Anda.
- Akun layanan IAM
- Resource Google Cloud yang memungkinkan aplikasi melakukan panggilan yang sah ke Google Cloud API.
Apa yang dimaksud dengan Workload Identity Federation for GKE?
Aplikasi yang berjalan di GKE mungkin memerlukan akses ke Google Cloud API seperti Compute Engine API, BigQuery Storage API, atau Machine Learning API.
Dengan Workload Identity Federation for GKE, Anda dapat menggunakan kebijakan IAM untuk memberi workload Kubernetes di cluster GKE akses ke Google Cloud API tertentu tanpa memerlukan konfigurasi manual atau metode yang kurang aman seperti file kunci akun layanan. Dengan Workload Identity Federation for GKE, Anda dapat menetapkan identitas dan otorisasi yang berbeda dan mendetail untuk setiap aplikasi di cluster.
Workload Identity Federation for GKE menggantikan kebutuhan penggunaan Penyembunyian metadata. Metadata sensitif yang dilindungi oleh penyembunyian metadata juga dilindungi oleh Workload Identity Federation untuk GKE.
Cara kerja Workload Identity Federation for GKE
Saat Anda mengaktifkan Workload Identity Federation for GKE di cluster, GKE akan melakukan hal berikut:
Membuat kumpulan identitas workload tetap untuk project Google Cloud cluster dengan format berikut:
PROJECT_ID.svc.id.goog
Kumpulan workload identity menyediakan format penamaan yang memungkinkan IAM memahami dan memercayai kredensial Kubernetes.
Mendaftarkan cluster GKE sebagai penyedia identitas di kumpulan identitas workload.
Men-deploy server metadata GKE, yang mencegat permintaan kredensial dari workload, di setiap node.
Membuat kebijakan izin IAM di resource Google Cloud
Untuk menyediakan akses dengan Workload Identity Federation for GKE, Anda perlu membuat kebijakan izin IAM yang memberikan akses pada resource Google Cloud tertentu ke akun utama yang sesuai dengan identitas aplikasi Anda. Misalnya, Anda dapat memberikan izin baca pada bucket Cloud Storage ke semua Pod yang menggunakan ServiceAccount Kubernetes database-reader
.
Untuk daftar resource yang mendukung kebijakan izinkan, lihat Jenis resource yang menerima kebijakan izin.
Anda juga dapat membatasi cakupan akses dengan menetapkan conditions dalam kebijakan izin. Misalnya, jika Anda hanya ingin memberikan akses baca pada bucket
ke Pod yang menggunakan ServiceAccount database-reader
di cluster mysql
,
Anda dapat menetapkan kondisi tersebut dalam kebijakan izin. Untuk mempelajari cara menggunakan
kondisi dalam kebijakan izinkan, lihat
Mengelola binding peran bersyarat.
Mereferensikan resource Kubernetes dalam kebijakan IAM
Dalam kebijakan IAM, Anda merujuk ke resource Kubernetes menggunakan ID utama IAM untuk memilih resource. ID ini memiliki sintaksis berikut:
PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.svc.id.goog/SELECTOR
Dalam contoh ini, pertimbangkan kolom berikut:
PREFIX
: harusprincipal
atauprincipalSet
bergantung pada resource yang Anda pilih.principal
ditujukan untuk resource tertentu, seperti satu ServiceAccount.principalSet
ditujukan untuk beberapa resource yang termasuk dalam resource yang ditentukan, seperti semua Pod dalam cluster tertentu.SELECTOR
: string yang memilih jenis utama. Misalnya,kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID
memilih ServiceAccount berdasarkan UID-nya.
Tabel berikut menunjukkan jenis utama yang didukung di GKE:
Jenis ID utama | Sintaksis |
---|---|
Semua Pod yang menggunakan ServiceAccount Kubernetes tertentu | Pilih ServiceAccount menurut nama:
principal://iam.googleapis.com/projects/
Ganti kode berikut:
Pilih ServiceAccount by UID: principal://iam.googleapis.com/projects/
Ganti kode berikut:
|
Semua Pod dalam cluster tertentu | principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME Ganti kode berikut:
|
Alur kredensial
Saat beban kerja mengirim permintaan untuk mengakses Google Cloud API, misalnya saat menggunakan library klien Google Cloud, langkah-langkah autentikasi berikut akan terjadi:
- Application default credentials (ADC) meminta token akses Google Cloud dari server metadata Compute Engine yang berjalan pada VM.
- Server metadata GKE mencegat permintaan token dan meminta token ServiceAccount Kubernetes ke server Kubernetes API yang mengidentifikasi beban kerja yang meminta. Kredensial ini adalah token web JSON (JWT) yang ditandatangani oleh otoritas sertifikat (CA) cluster.
- Server metadata GKE menggunakan Security Token Service untuk menukar JWT dengan token akses Google Cloud gabungan berumur pendek yang mereferensikan identitas workload Kubernetes.
- Server metadata GKE menyediakan token akses federasi ke workload.
Selanjutnya, beban kerja dapat mengakses Google Cloud API apa pun yang dapat diakses oleh ID utama IAM dari beban kerja.
Kesamaan identitas
Jika metadata pada ID utama Anda sama untuk beban kerja di beberapa cluster yang memiliki kumpulan workload identity yang sama, IAM akan mengidentifikasi beban kerja tersebut sebagai beban kerja yang sama. Misalnya, jika Anda memiliki namespace yang sama di dua cluster dan memberikan akses ke namespace tersebut di IAM, workload dalam namespace tersebut di kedua cluster akan mendapatkan akses tersebut. Anda dapat membatasi akses ini ke cluster tertentu menggunakan kebijakan IAM bersyarat.
Misalnya, perhatikan diagram berikut. Cluster A, B, dan C termasuk dalam
project Google Cloud yang sama, sehingga berada dalam workload identity pool yang sama.
Google Cloud mengidentifikasi aplikasi yang menggunakan back-ksa
ServiceAccount dalam namespace backend
Cluster A dan Cluster B sebagai identitas yang sama. IAM tidak membedakan cluster
yang melakukan panggilan.
Kesamaan identitas ini juga berarti bahwa Anda harus dapat memercayai setiap cluster dalam workload identity pool tertentu. Misalnya, jika Cluster C di contoh sebelumnya dimiliki oleh tim yang tidak tepercaya, mereka dapat membuat namespace backend
dan mengakses Google Cloud API menggunakan ServiceAccount back-ksa
, seperti Cluster A dan Cluster B.
Untuk menghindari akses yang tidak tepercaya, tempatkan cluster Anda dalam project terpisah untuk memastikannya mendapatkan kumpulan workload identity yang berbeda, atau pastikan nama namespace berbeda satu sama lain untuk menghindari ID utama yang umum.
Memahami server metadata GKE
Setiap node di GKE dengan Workload Identity Federation for GKE yang aktif menyimpan metadatanya di server metadata GKE. Server metadata GKE adalah subset endpoint server metadata Compute Engine yang diperlukan untuk workload Kubernetes.
Server metadata GKE berjalan sebagai DaemonSet, dengan satu Pod di
setiap node Linux atau layanan Windows native di setiap node Windows di
cluster. Server metadata mencegat permintaan HTTP ke http://metadata.google.internal
(169.254.169.254:80
). Misalnya, permintaan GET
/computeMetadata/v1/instance/service-accounts/default/token
mengambil token untuk akun layanan IAM yang telah dikonfigurasi oleh Pod untuk ditiru.
Traffic ke server metadata GKE tidak pernah keluar dari instance VM yang menghosting Pod.
Tabel berikut menjelaskan subset endpoint server metadata Compute Engine yang tersedia dengan server metadata GKE. Untuk mengetahui daftar lengkap endpoint yang tersedia di server metadata Compute Engine, baca Nilai metadata VM default.
Metadata instance
Metadata instance disimpan di direktori berikut ini.
http://metadata.google.internal/computeMetadata/v1/instance/
Entri | Deskripsi |
---|---|
hostname |
Nama host node Anda. |
id |
ID unik node Anda. |
service-accounts/ |
Direktori akun layanan yang terkait dengan node. Untuk setiap akun layanan, tersedia informasi berikut:
|
zone |
Zona Compute Engine dari node GKE Anda. |
Atribut instance
Atribut instance disimpan di direktori berikut.
http://metadata.google.internal/computeMetadata/v1/instance/attributes/
Entri | Deskripsi |
---|---|
cluster-location |
Zona atau region Compute Engine dari cluster Anda. |
cluster-name |
Nama cluster GKE Anda. |
cluster-uid |
UID cluster GKE Anda. |
Metadata project
Metadata project cluster disimpan di direktori berikut.
http://metadata.google.internal/computeMetadata/v1/project/
Entri | Deskripsi |
---|---|
project-id |
ID Project Google Cloud Anda. |
numeric-project-id |
Nomor project Google Cloud Anda. |
Pembatasan Workload Identity Federation untuk GKE
Anda tidak dapat mengubah nama workload identity pool yang dibuat GKE untuk project Google Cloud.
Saat GKE mengaktifkan server metadata GKE pada suatu node pool, Pod tidak dapat lagi mengakses server metadata Compute Engine. Sebagai gantinya, server metadata GKE mencegat permintaan yang dibuat dari pod ini ke endpoint metadata, kecuali Pod yang berjalan di jaringan host.
Server metadata GKE memerlukan waktu beberapa detik untuk mulai menerima permintaan pada Pod yang baru dibuat. Oleh karena itu, upaya melakukan autentikasi menggunakan Workload Identity Federation for GKE dalam beberapa detik pertama masa aktif Pod mungkin akan gagal. Mencoba kembali panggilan akan menyelesaikan masalah. Baca artikel Pemecahan masalah untuk mengetahui detail selengkapnya.
Agen logging dan pemantauan bawaan GKE terus menggunakan akun layanan node.
Workload Identity Federation for GKE memerlukan penyiapan manual agar Cloud Run for Anthos dapat terus merilis metrik permintaan.
Workload Identity Federation for GKE menetapkan batas 200 koneksi ke server metadata GKE untuk setiap node guna menghindari masalah memori. Anda mungkin akan mengalami waktu tunggu jika node Anda melebihi batas ini.
Workload Identity Federation for GKE untuk node Windows Server tersedia di GKE versi 1.18.16-gke.1200, 1.19.8-gke.1300, 1.20.4-gke.1500 dan yang lebih baru.
Server metadata GKE menggunakan resource memori yang sebanding dengan total jumlah akun layanan Kubernetes di cluster Anda. Jika cluster Anda memiliki lebih dari 3.000 akun layanan Kubernetes, kubelet mungkin akan menghentikan Pod server metadata. Untuk melakukan mitigasi, lihat Pemecahan masalah.
Alternatif untuk Workload Identity Federation untuk GKE
Anda dapat menggunakan salah satu alternatif berikut untuk Workload Identity Federation for GKE, guna mengakses Google Cloud API dari GKE. Sebaiknya gunakan Workload Identity Federation for GKE karena alternatif ini mengharuskan Anda melakukan penyusupan keamanan tertentu.
Gunakan akun layanan default Compute Engine untuk node Anda. Anda dapat menjalankan node pool sebagai akun layanan IAM apa pun dalam project. Jika Anda tidak menentukan akun layanan selama pembuatan node pool, GKE akan menggunakan akun layanan default Compute Engine untuk project tersebut. Akun layanan Compute Engine digunakan bersama oleh semua beban kerja yang di-deploy pada node tersebut. Hal ini dapat mengakibatkan penyediaan izin yang berlebihan, sehingga melanggar prinsip hak istimewa terendah dan tidak sesuai untuk cluster multi-tenant.
Ekspor kunci akun layanan dan simpan sebagai Kubernetes Secret yang Anda pasang ke Pod sebagai volume.
Langkah selanjutnya
- Pelajari cara mengaktifkan dan mengonfigurasi Workload Identity Federation untuk GKE.
- Pelajari server metadata Compute Engine lebih lanjut.