Tentang Workload Identity Federation for GKE

Halaman ini menjelaskan Federasi Identitas Beban Kerja untuk GKE, termasuk cara kerjanya, pengaruh pengaktifannya terhadap cluster GKE Anda, dan cara memberikan peran ke entitas Kubernetes dalam kebijakan Identity and Access Management. Dalam sebagian besar kasus, Workload Identity Federation untuk GKE adalah cara yang direkomendasikan agar workload Anda yang berjalan di GKE dapat mengakses layanan dengan cara yang aman dan mudah dikelola. Google Cloud

Halaman ini ditujukan untuk Spesialis dan Operator Keamanan yang mengelola workload di GKE yang memerlukan akses ke layanan Google Cloud lainnya. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud , lihat Peran dan tugas pengguna umum GKE Enterprise.

Sebelum membaca halaman ini, pastikan Anda memahami referensi berikut:

• 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 untuk cluster di fleet, gunakan fleet workload identity.

Terminologi

Halaman 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

Google Cloud resource yang memungkinkan aplikasi melakukan panggilan yang sah ke Google Cloud API.

Apa yang dimaksud dengan Workload Identity Federation untuk GKE?

Aplikasi yang berjalan di GKE mungkin memerlukan akses ke Google Cloud API seperti Compute Engine API, BigQuery Storage API, atau Machine Learning API.

Workload Identity Federation untuk GKE memungkinkan Anda menggunakan kebijakan IAM untuk memberikan akses workload Kubernetes di cluster GKE Anda keGoogle Cloud API tertentu tanpa memerlukan konfigurasi manual atau metode yang kurang aman seperti file kunci akun layanan. Dengan menggunakan Workload Identity Federation untuk GKE, Anda dapat menetapkan identitas dan otorisasi yang berbeda secara terperinci untuk setiap aplikasi di cluster.

Workload Identity Federation for GKE menggantikan kebutuhan untuk menggunakan Penyembunyian metadata. Metadata sensitif yang dilindungi oleh penyembunyian metadata juga dilindungi oleh Workload Identity Federation untuk GKE.

Workload Identity Federation for GKE tersedia melalui IAM Workload Identity Federation, yang menyediakan identitas untuk beban kerja yang berjalan di lingkungan di dalam dan di luar Google Cloud. Anda dapat menggunakan IAM Workload Identity Federation untuk melakukan autentikasi secara aman ke API yang didukung Google Cloud dari beban kerja yang berjalan di, misalnya, AWS, Azure, dan Kubernetes yang dikelola sendiri. Di GKE,Google Cloud mengelola workload identity pool dan penyedia untuk Anda dan tidak memerlukan penyedia identitas eksternal.

Cara kerja Workload Identity Federation for GKE

Saat Anda mengaktifkan Workload Identity Federation untuk GKE di cluster, GKE akan melakukan hal berikut:

• Membuat workload identity pool tetap untuk project Google Cloud cluster dengan format berikut:

  PROJECT_ID.svc.id.goog
  

  Workload identity pool menyediakan format penamaan yang memungkinkan IAM memahami dan memercayai kredensial Kubernetes. GKE tidak menghapus workload identity pool ini meskipun Anda menghapus semua cluster dalam project Anda.

• Mendaftarkan cluster GKE sebagai penyedia identitas di workload identity pool.

• Men-deploy server metadata GKE, yang mencegat permintaan kredensial dari workload, di setiap node.

Membuat kebijakan izin IAM pada Google Cloud resource

Untuk memberikan akses dengan Workload Identity Federation untuk GKE, Anda membuat kebijakan izin IAM yang memberikan akses pada resource Google Cloud tertentu kepada prinsipal yang sesuai dengan identitas aplikasi Anda. Misalnya, Anda dapat memberikan izin baca pada bucket Cloud Storage ke semua Pod yang menggunakan database-reader Kubernetes ServiceAccount.

Untuk daftar resource yang mendukung kebijakan izin, lihat Jenis resource yang menerima kebijakan izin.

Menggunakan kondisi dalam kebijakan IAM

Anda juga dapat membatasi cakupan akses dengan menetapkan kondisi dalam kebijakan izin Anda. Kondisi adalah metode yang dapat diperluas untuk menentukan kapan kebijakan izinkan harus diterapkan. Misalnya, Anda dapat menggunakan kondisi untuk memberikan akses sementara ke workload pada resource Google Cloud tertentu, sehingga tidak perlu mengelola akses tersebut secara manual.

Kondisi juga dapat berguna jika Anda menetapkan kebijakan izin di tingkat project, folder, atau organisasi, bukan pada resource tertentu seperti secret Secret Manager atau bucket Cloud Storage.

Untuk menambahkan kondisi ke kebijakan izin, gunakan referensi berikut:

• Mengelola binding peran bersyarat: Menambahkan, mengubah, atau menghapus binding peran bersyarat.
• Mengonfigurasi akses sementara: Gunakan kondisi untuk menetapkan akses yang akan berakhir ke Google Cloud resource dalam kebijakan izinkan.
• Tag dan akses bersyarat: Gunakan kondisi untuk hanya menerapkan kebijakan izinkan saat resource memiliki tag tertentu.

Contoh ekspresi berikut adalah untuk skenario umum saat Anda dapat menggunakan kondisi. Untuk mengetahui daftar atribut yang tersedia dalam ekspresi, lihat Referensi atribut untuk IAM Conditions.

request.time < timestamp('TIMESTAMP')

resource.matchTag('TAG_KEY', 'TAG_VALUE')

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: harus principal atau principalSet, bergantung pada resource yang Anda pilih. principal adalah untuk resource tertentu, seperti ServiceAccount tunggal. principalSet adalah untuk beberapa resource yang termasuk dalam resource yang ditentukan, seperti semua Pod dalam cluster tertentu.
• SELECTOR: string yang memilih jenis akun utama. Misalnya, kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID memilih ServiceAccount berdasarkan UID-nya.

Tabel berikut menunjukkan jenis prinsipal yang didukung di GKE:

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE

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

Alur kredensial

Saat workload mengirim permintaan untuk mengakses Google Cloud API, misalnya saat menggunakan Google Cloud library klien, langkah-langkah autentikasi berikut akan terjadi:

1. Kredensial default aplikasi (ADC) meminta Google Cloud token akses dari server metadata Compute Engine yang berjalan di VM.
2. Server metadata GKE mencegat permintaan token dan meminta token ServiceAccount Kubernetes dari server Kubernetes API yang mengidentifikasi workload yang meminta. Kredensial ini adalah token web JSON (JWT) yang ditandatangani oleh server API.
3. Server metadata GKE menggunakan Security Token Service untuk menukar JWT dengan token akses gabungan yang berumur pendek yang mereferensikan identitas workload Kubernetes.

Token akses gabungan yang ditampilkan oleh Layanan Token Keamanan mungkin memiliki batasan saat mencoba mengakses beberapa layanan, seperti yang dijelaskan dalam Produk dan batasan yang didukung. Google Cloud Jika layanan Google Cloud yang Anda pilih memiliki batasan, Anda dapat mengonfigurasi peniruan identitas akun layanan secara opsional. Metode ini menghasilkan token akses untuk akun layanan IAM yang dapat digunakan oleh workload Anda untuk mengakses layanan target. Untuk mengetahui detailnya, lihat menautkan ServiceAccount Kubernetes ke IAM.

Workload kemudian dapat mengakses API apa pun yang dapat diakses oleh ID akun utama IAM workload. Google Cloud

Kuota untuk Exchange Token API di Security Token Service

Exchange Token API di Layanan Token Keamanan memiliki batas kuota sebanyak 6.000 permintaan per menit. Jika melihat error QUOTA_EXCEEDED, Anda dapat meminta penambahan kuota Token exchange requests per minute melalui halaman Quotas & System Limits.

Kesamaan identitas

Jika metadata di ID entity utama Anda sama untuk workload di beberapa cluster yang berbagi workload identity pool karena termasuk dalam project yang sama, IAM mengidentifikasi workload tersebut sebagai workload yang sama. Google Cloud Misalnya, jika Anda memiliki namespace yang sama di dua cluster dan Anda memberikan akses ke namespace tersebut di IAM, beban kerja di namespace tersebut di kedua cluster akan mendapatkan akses tersebut. Anda dapat membatasi akses ini ke cluster tertentu dengan menggunakan kebijakan IAM bersyarat.

Misalnya, perhatikan diagram berikut. Cluster A dan B termasuk dalam workload identity pool yang sama. Google Cloud mengidentifikasi aplikasi yang menggunakan ServiceAccount back-ksa di namespace backend Cluster A dan Cluster B sebagai identitas yang sama. IAM tidak membedakan berbagai cluster yang melakukan panggilan.

Kesamaan identitas ini juga berarti bahwa Anda harus dapat memercayai setiap cluster dalam workload identity pool tertentu. Misalnya, jika cluster baru, Cluster C dalam contoh sebelumnya dimiliki oleh tim yang tidak tepercaya, mereka dapat membuat namespace backend dan mengakses API Google Cloud menggunakan ServiceAccount back-ksa, sama seperti Cluster A dan Cluster B.

Untuk menghindari akses yang tidak tepercaya, tempatkan cluster Anda dalam project terpisah untuk memastikan bahwa cluster tersebut mendapatkan workload identity pool yang berbeda, atau pastikan bahwa nama namespace berbeda satu sama lain untuk menghindari ID principal yang sama.

Server metadata GKE

Setiap node di GKE yang mengaktifkan Workload Identity Federation for GKE 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.

Masa berlaku token

Secara default, token akses yang ditampilkan memiliki masa berlaku 1 jam (3.600 detik). Untuk mengurangi latensi klien, server metadata GKE menyimpan token akses dalam cache. Dalam beberapa situasi, token yang di-cache yang ditampilkan server metadata mungkin mendekati waktu habis masa berlakunya.

Library Klien Cloud memiliki logika bawaan yang secara default memeriksa apakah token akses akan habis masa berlakunya dalam 3 menit 45 detik ke depan. Jika token masih dalam periode habis masa berlaku, GKE akan memperbarui token. Panggilan API berurutan dapat menggunakan token yang diperbarui.

Jika Anda menggunakan kode Anda sendiri untuk mengakses Google Cloud API secara langsung, terapkan logika serupa untuk menangani masa berlaku token. Kode Anda harus melakukan hal berikut:

1. Periksa apakah masa berlaku token akses berakhir setelah jangka waktu 3 menit dan 45 detik. Parameter exp dalam payload token menunjukkan stempel waktu masa berlaku token.
2. Jika token akan habis masa berlakunya dalam 3 menit 45 detik ke depan, buat permintaan token.

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/

Atribut instance

Atribut instance disimpan di direktori berikut.

http://metadata.google.internal/computeMetadata/v1/instance/attributes/

Atribut yang tercantum dalam tabel adalah satu-satunya atribut yang didukung. Jika Anda mencoba mengakses atribut yang tidak didukung, Pod gke-metadata-server di namespace kube-system akan menghasilkan dan mencatat error 404. Errornya mirip dengan yang berikut ini:

HTTP/404: generic::not_found: no child "", Reason: "NOT_FOUND", UserMessage: "Not Found"

Jika menggunakan istio-proxy, Anda akan melihat pesan error seperti berikut:

Error fetching GCP Metadata property gcp_gce_instance_template: metadata: GCE metadata "instance/attributes/UNSUPPORTED_ATTRIBUTE" not defined

Metadata project

Metadata project cluster disimpan di direktori berikut.

http://metadata.google.internal/computeMetadata/v1/project/

Batasan Workload Identity Federation for GKE

• Anda tidak dapat mengubah nama workload identity pool yang dibuat GKE untuk project Google Cloud Anda.

• 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 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 untuk layanan Knative agar 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 untuk 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.

• Workload Identity Federation for GKE beroperasi dalam perimeter Kontrol Layanan VPC, sehingga memungkinkan akses ke resource di dalamnya. Namun, Kontrol Layanan VPC tidak menerapkan kontrol akses untuk permintaan lintas perimeter berdasarkan identitas gabungan ini. Anda dapat menggunakan peniruan akun layanan untuk mengakses resource dalam perimeter yang berbeda.

Alternatif untuk Workload Identity Federation for GKE

Anda dapat menggunakan salah satu alternatif berikut untuk Workload Identity Federation for GKE guna mengaksesGoogle Cloud API dari GKE. Sebaiknya gunakan Workload Identity Federation untuk GKE karena alternatif ini mengharuskan Anda mengorbankan 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 kumpulan node, 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.

• Mengekspor kunci akun layanan dan menyimpannya sebagai Secret Kubernetes yang Anda pasang ke Pod sebagai volume.

Langkah berikutnya

• Pelajari cara mengaktifkan dan mengonfigurasi Workload Identity Federation for GKE.
• Pelajari server metadata Compute Engine lebih lanjut.