Tentang Workload Identity Federation untuk fleet

Halaman ini menjelaskan Workload Identity Federation armada, yang merupakan mekanisme untuk mengautentikasi permintaan dari workload armada ke API Google Cloud . Di halaman ini, Anda akan mempelajari kesamaan identitas untuk workload, cara kerja Workload Identity Federation armada, dan praktik terbaik untuk mengelolanya dalam skala besar.

Halaman ini ditujukan bagi admin dan operator Platform serta Engineer keamanan yang ingin mengelola otorisasi beban kerja secara lebih efisien dalam skala besar. Untuk mempelajari lebih lanjut peran pengguna dan contoh tugas yang kami referensikan dalam dokumentasi, lihat Peran dan tugas pengguna GKE umum. Google Cloud

Sebelum membaca halaman ini, pastikan Anda memahami konsep berikut:

Tentang identitas workload gabungan di Google Cloud

Workload Identity Federation adalah fitur Google Cloud yang memungkinkan workload di cluster Anda melakukan autentikasi ke Google Cloud tanpa mengharuskan Anda mendownload, memutar secara manual, dan mengelola kredensial secara umum. Sebagai gantinya, beban kerja melakukan autentikasi menggunakan token berjangka pendek yang dibuat oleh Google Cloud.

Workload Identity Federation for GKE adalah penerapan Workload Identity Federation khusus GKE yang menyediakan workload identity pool yang dikelola Google di seluruh project yang digunakan aplikasi yang berjalan di cluster GKE untuk mendapatkan identitas. Workload Identity Federation Fleet memperluas Workload Identity Federation untuk GKE ke semua cluster anggota fleet, terlepas dari apakah cluster tersebut berada dalam project yang berbeda atau berada di luar Google Cloud. Dengan Workload Identity Federation armada, cluster terdaftar yang mengaktifkan Workload Identity Federation pada keanggotaan armadanya akan mendapatkan identitas menggunakan kumpulan workload identity yang dikelola Google di seluruh armada. Kumpulan bersama ini memungkinkan Anda mengonfigurasi autentikasi ke Google Cloud API dan ke layanan lainnya di seluruh fleet, bahkan di beberapa project.

Fleet Workload Identity Federation juga dapat digunakan oleh Connect Agent di beberapa jenis cluster untuk melakukan autentikasi ke Google Cloud sebagai bagian dari keanggotaan fleet, dan diperlukan untuk menggunakan beberapa fitur GKE Enterprise yang berfungsi di seluruh project, seperti Cloud Service Mesh.

Tentang workload identity pool

Workload identity pool adalah entity yang mengelola identitas secara terpusat untuk aplikasi Anda. Saat Anda mengaktifkan Workload Identity Federation untuk GKE di cluster, project cluster akan mendapatkan workload identity pool yang dikelola Google dengan nama tetap dan khusus project. Aplikasi di cluster Anda mendapatkan identitas dari kumpulan identitas workload yang dikelola Google untuk mengautentikasi panggilan API. Google Cloud Workload identity pool yang dikelola Google memiliki sintaksis PROJECT_ID.svc.id.goog, dengan PROJECT_ID adalah ID project cluster.

Dengan Workload Identity Federation fleet, workload identity pool yang dikelola Google di project host fleet juga merupakan workload identity pool untuk semua cluster yang Anda daftarkan ke fleet, terlepas dari apakah cluster tersebut berada di project lain atau di luar Google Cloud. Setiap cluster dalam fleet menggunakan kumpulan identitas workload FLEET_HOST_PROJECT_ID.svc.id.goog, dengan FLEET_HOST_PROJECT_ID adalah project ID project host fleet.

Jika menggunakan cakupan tim, Anda dapat secara opsional mengonfigurasi kumpulan identitas workload IAM yang dikelola sendiri untuk digunakan cluster selain kumpulan yang dikelola Google. Pool yang dikelola sendiri ini memberikan kontrol yang lebih eksplisit atas workload mana yang mendapatkan identitas tertentu.

Setiap aplikasi di armada Anda mendapatkan identitas gabungan yang berbeda dari workload identity pool armada yang dapat digunakan aplikasi untuk melakukan autentikasi ke Google Cloud dan ke layanan lain yang Anda kembangkan. Aplikasi mendapatkan ID prinsipal yang dapat dikenali oleh IAM. ID ini menggunakan sintaksis berikut:

PREFIX://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/SELECTOR

Sintaksis ini memiliki kolom berikut:

  • PREFIX: principal atau principalSet, bergantung pada jenis resource Kubernetes yang Anda pilih di kolom SELECTOR.
  • FLEET_PROJECT_NUMBER: nomor project dari project host fleet.

  • WORKLOAD_IDENTITY_POOL_NAME: workload identity pool untuk fleet Anda. Nilai ini bergantung pada workload identity pool yang Anda siapkan di setiap cluster, sebagai berikut:

    • Workload identity pool yang dikelola Google: FLEET_HOST_PROJECT_ID.svc.id.goog

    • Workload identity pool yang dikelola sendiri (Pratinjau): POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog, dengan POOL_HOST_PROJECT_NUMBER adalah nomor project dari project tempat Anda membuat workload identity pool yang dikelola sendiri.

  • SELECTOR: pemilih resource. Untuk mengetahui daftar selektor yang didukung, lihat bagian ID utama yang didukung. Misalnya, subject/ns/NAMESPACE/sa/SERVICEACCOUNT memilih Akun Layanan Kubernetes tertentu dalam namespace tertentu.

Seluruh fleet berbagi workload identity pool fleet sehingga Anda dapat memberikan akses ke resource yang sama untuk aplikasi di mana saja dalam fleet, termasuk di project atau cloud lain, tanpa perlu mengelola akses tersebut untuk setiap cluster.

Tentang kesamaan identitas

Seperti fitur lain yang mendukung fleet, Workload Identity Federation fleet mengandalkan prinsip kesamaan, yang memperlakukan objek Kubernetes yang memiliki nama dan namespace yang sama di cluster yang berbeda sebagai hal yang sama. Untuk mempelajari lebih lanjut prinsip umum kesamaan dalam fleet, lihat Kesamaan.

Dengan Workload Identity Federation untuk GKE satu project, kesamaan identitas berlaku untuk semua entitas yang berbagi ID utama dalam project tersebut. Namun, dengan Workload Identity Federation armada, kesamaan identitas ini secara implisit berlaku untuk semua entitas yang berbagi ID utama di seluruh armada, terlepas dari project cluster.

Misalnya, pertimbangkan aplikasi dengan backend yang di-deploy di beberapa cluster dalam fleet yang sama. Jika Anda memberikan peran ke ID entity utama yang memilih ServiceAccount Kubernetes default di namespace Kubernetes backend, aplikasi apa pun di namespace tersebut yang menggunakan ServiceAccount tersebut akan mendapatkan akses yang sama.

Jika fleet Anda hanya menjalankan cluster di project host fleet, implikasi kesamaan identitasnya sama seperti Workload Identity Federation for GKE. Namun, jika fleet Anda memiliki cluster yang berjalan di project lain atau di luarGoogle Cloud, kesamaan identitas implisit ini berlaku untuk semua cluster terdaftar di fleet.

Kesamaan identitas di lingkungan multi-tenant atau campuran

Secara default, fleet Anda menggunakan workload identity pool yang dikelola Google dari project host fleet untuk memberikan identitas ke workload di seluruh fleet. Semua cluster dalam project host fleet, termasuk cluster mandiri yang tidak terdaftar ke fleet, menggunakan workload identity pool ini. Dalam lingkungan dengan kepercayaan campuran tempat cluster mandiri ini menjalankan workload yang memiliki model kepercayaan yang berbeda, kesamaan identitas implisit ini dapat menyebabkan akses yang tidak diinginkan.

Fleet memungkinkan Anda mengelola model multi-tenant ini dengan menggunakan cakupan tim dan namespace fleet. Cakupan tim memungkinkan Anda menetapkan subset resource fleet, seperti cluster, untuk digunakan oleh tim tertentu di organisasi Anda. Namespace fleet memungkinkan Anda menentukan namespace Kubernetes dalam cakupan tim tertentu, sehingga tim tertentu hanya dapat menjalankan workload di namespace dalam cakupan timnya. Untuk mengetahui detailnya, lihat Ringkasan pengelolaan tim fleet.

Jika menggunakan cakupan tim, Anda dapat mengurangi kompleksitas kesamaan identitas di fleet multi-tenant dengan mengonfigurasi workload identity pool Anda sendiri untuk digunakan oleh cluster tertentu di fleet Anda, bukan workload identity pool yang dikelola Google. Akibatnya, ID utama untuk workload tersebut secara eksplisit berbeda dengan ID utama untuk cluster mandiri dalam project. Kesamaan identitas eksplisit ini memberi administrator kontrol yang lebih besar atas batas-batas penerapan kesamaan identitas.

Model kesamaan identitas di armada Anda berubah sebagai berikut, berdasarkan apakah Anda hanya menggunakan workload identity pool yang dikelola Google atau mengonfigurasi workload identity pool yang dikelola sendiri:

  • Kesamaan identitas implisit: semua beban kerja dalam fleet menggunakan workload identity pool yang dikelola Google. Akibatnya, setiap workload yang berbagi ID akun utama yang sama secara implisit berbagi akses yang sama.

  • Kesamaan identitas eksplisit (Pratinjau): Anda mengonfigurasi workload identity pool yang dikelola sendiri untuk cakupan tim di fleet. Pool yang dikelola sendiri hanya memberikan identitas ke workload jika Anda mengonfigurasi cluster untuk menggunakan pool yang dikelola sendiri untuk namespace fleet tertentu. Workload yang berjalan di namespace dan cluster Kubernetes lain tidak dapat menggunakan kumpulan yang dikelola sendiri.

    Akibatnya, kesamaan identitas beban kerja yang menggunakan pool yang dikelola sendiri berbeda dengan kesamaan identitas beban kerja yang hanya dapat menggunakan workload identity pool yang dikelola Google.

Kapan harus menggunakan workload identity pool yang dikelola sendiri

Gunakan identity pool yang dikelola Google jika setiap cluster memiliki tingkat kepercayaan yang serupa, di mana entitas yang sama men-deploy aplikasi yang sama. Misalnya, fleet khusus tim dengan cluster di setiap region yang men-deploy aplikasi yang direplikasi di setiap cluster.

Sebaiknya Anda mengonfigurasi workload identity pool yang dikelola sendiri untuk fleet Anda dalam skenario seperti berikut:

  • Beberapa tingkat kepercayaan di fleet: Anda menjalankan cluster yang memiliki beberapa tingkat kepercayaan. Misalnya, pertimbangkan skenario saat tim keuangan dan tim frontend memiliki cluster dalam armada yang sama. Kumpulan identitas workload yang dikelola sendiri membantu Anda memisahkan pemberian akses untuk setiap tim berdasarkan namespace armada. Artinya, bahkan administrator cluster frontend tidak dapat memperoleh identitas di namespace fleet kecuali jika mereka memiliki izin eksplisit.
  • Beberapa tingkat kepercayaan dalam project: project host fleet Anda menjalankan cluster mandiri yang mungkin tidak memiliki tingkat kepercayaan yang sama dengan cluster fleet Anda. Secara default, cluster mandiri ini menggunakan workload identity pool yang dikelola Google dari project host fleet. Cluster fleet Anda juga menggunakan workload identity pool ini, terlepas dari project cluster fleet. Menetapkan workload identity pool yang dikelola sendiri untuk fleet memastikan bahwa pemberian akses pada pool yang dikelola sendiri tidak secara tidak sengaja memberikan akses ke cluster mandiri.
  • Praktik terbaik untuk cakupan tim: Anda sudah menggunakan fitur pengelolaan tim armada dan ingin menerapkan praktik terbaik yang direkomendasikan untuk memberikan akses ke workload. Menetapkan kumpulan identitas beban kerja yang dikelola sendiri memungkinkan Anda memberikan akses ke beban kerja di namespace fleet tertentu dalam cakupan tim tanpa memberikan akses tersebut ke cakupan tim lain yang menjalankan beban kerja di cluster yang sama.

Cara kerja Workload Identity Federation fleet

Bagian berikut menjelaskan cara kerja Workload Identity Federation armada, termasuk alur kredensial autentikasi dan ID utama IAM yang didukung.

Alur kredensial

Agar aplikasi di namespace tertentu dapat melakukan autentikasi menggunakan Fleet Workload Identity Federation, Anda harus melakukan hal berikut:

  1. Deploy ConfigMap di namespace tersebut yang memiliki informasi berikut:

    • Workload identity pool dan penyedia identitas untuk cluster Anda.
    • Jalur di setiap Pod tempat Kubernetes memasang token ServiceAccount. Token ini adalah Token Web JSON (JWT) yang ditandatangani.

    ConfigMap ini berfungsi sebagai file kredensial default aplikasi (ADC) untuk workload.

  2. Buat kebijakan izin IAM yang memberikan akses ke resourceGoogle Cloud tertentu bagi ID entity utama di cluster Anda, seperti ServiceAccount di namespace.

  3. Pastikan beban kerja Anda di namespace memiliki konfigurasi berikut dalam spesifikasi Pod:

    • Variabel lingkungan GOOGLE_APPLICATION_CREDENTIALS ditetapkan ke jalur pemasangan ConfigMap di Pod.
    • Volume yang diproyeksikan yang berisi token ServiceAccount dan ConfigMap yang Anda buat, dipasang di jalur yang sama dengan yang Anda tentukan dalam variabel lingkungan GOOGLE_APPLICATION_CREDENTIALS.
    • Pemasangan volume di container yang mereferensikan volume yang diproyeksikan.

Saat workload membuat panggilan API Google Cloud , langkah-langkah berikut akan terjadi:

  1. Library autentikasi Google Cloud menggunakan Kredensial Default Aplikasi (ADC) untuk menemukan kredensial. ADC memeriksa jalur yang Anda tentukan dalam variabel lingkungan GOOGLE_APPLICATION_CREDENTIALS untuk mencari token autentikasi.
  2. Library autentikasi ADC menggunakan data di ConfigMap untuk menukar JWT ServiceAccount yang Anda pasang di Pod dengan token akses gabungan berjangka pendek dari Security Token Service yang mereferensikan ID utama workload.
  3. ADC menyertakan token akses gabungan dengan permintaan API.
  4. Kebijakan izin IAM mengizinkan ID akun utama untuk melakukan operasi yang diminta pada resource Google Cloud .

ID principal yang didukung untuk Workload Identity Federation armada

Tabel berikut menjelaskan pemilih yang dapat Anda gunakan dalam kebijakan izin IAM untuk mereferensikan akun utama dalam armada:

Jenis ID utama Sintaks
Semua Pod yang menggunakan ServiceAccount Kubernetes tertentu Pilih ServiceAccount berdasarkan nama: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

Ganti kode berikut:

  • PROJECT_NUMBER: nomor project numerik Anda. Untuk mendapatkan nomor project, lihat Mengidentifikasi project.
  • PROJECT_ID: ID project Google Cloud Anda.
  • NAMESPACE: namespace Kubernetes.
  • SERVICEACCOUNT: nama ServiceAccount Kubernetes.
Pilih ServiceAccount menurut UID: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

Ganti kode berikut:

  • PROJECT_NUMBER: nomor project numerik Anda. Untuk mendapatkan nomor project, lihat Mengidentifikasi project.
  • PROJECT_ID: project ID Fleet Anda.
  • SERVICEACCOUNT_UID: UID objek ServiceAccount di server API.

Langkah berikutnya