Praktik terbaik untuk menggunakan Workload Identity fleet

Seperti yang Anda ketahui dari bagian Mengautentikasi ke API dan layanan dari workload fleet, Workload Identity Federation di seluruh fleet adalah fitur fleet canggih yang mempermudah penyiapan autentikasi ke Google Cloud untuk aplikasi Anda di seluruh project. Namun, platform ini dapat memiliki pertimbangan kontrol akses melebihi dan melebihi workload untuk Workload Identity Federation for GKE. Panduan ini memberikan beberapa contoh potensi masalah tersebut dan cara mengatur armada Anda untuk meminimalkan kemungkinan risiko.

Sebelum membaca panduan ini, Anda harus memahami konsep yang dijelaskan dalam Mengautentikasi ke API dan layanan dari workload fleet.

Untuk praktik terbaik seputar mengadopsi fitur perangkat lainnya, lihat Merencanakan fitur fleet.

Kumpulan identitas project dan fleet

Untuk memahami alasan Workload Identity Federation di seluruh fleet memerlukan adopsi yang cermat terutama saat bekerja dengan fleet multi-project, mari kita lihat lebih dekat cara kerja Workload Identity Federation for GKE dan fleet Workload Identity Federation. Dalam kedua kasus tersebut, workload mengautentikasi menggunakan token berumur singkat yang dihasilkan oleh cluster, dengan setiap cluster ditambahkan sebagai penyedia identitas ke kumpulan workload identity khusus. Beban kerja yang berjalan di namespace tertentu kemudian dapat memiliki identitas IAM yang sama di seluruh cluster.

Berikut adalah hal yang terjadi dengan Workload Identity Federation reguler untuk GKE saat diaktifkan untuk cluster Anda. Perlu diperhatikan bahwa Workload Identity Federation untuk GKE diaktifkan untuk cluster Autopilot secara default.

  1. GKE membuat kumpulan workload identity yang dikelola Google di project cluster: PROJECT_ID.svc.goog.id.
  2. GKE menambahkan cluster sebagai penyedia identitas ke kumpulan tersebut.
  3. Akibatnya, workload yang berjalan di namespace tertentu memiliki identitas IAM yang sama di seluruh cluster dalam sebuah project. Identitasnya berupa: serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME].

Workload Identity Federation di seluruh inventaris otomatis diaktifkan saat Anda menambahkan cluster dengan Workload Identity Federation untuk GKE yang diaktifkan ke fleet, termasuk cluster Autopilot, cluster Standar dengan fitur yang diaktifkan secara eksplisit, dan cluster GKE di luar Google Cloud.

Berikut adalah hal yang terjadi jika pengguna mendaftarkan cluster ke sebuah fleet dengan Workload Identity Federation untuk GKE:

  1. Kumpulan identitas workload seluruh fleet yang dikelola Google FLEET_PROJECT_ID.svc.goog.id dalam project host fleet dibuat, jika kumpulan tersebut belum ada. Ini sama dengan kumpulan workload identity project untuk project host fleet.
  2. Cluster ditambahkan sebagai penyedia identitas ke kumpulan.
  3. Akibatnya, workload yang berjalan di namespace tertentu memiliki identitas IAM yang sama di seluruh cluster dalam fleet. Kami menyebutnya sebagai kesamaan implisit dari identitas workload fleet. Identitasnya berupa: serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]. Beban kerja perangkat di berbagai project kemudian dapat memanggil Google API menggunakan identitas yang sama untuk autentikasi.

Seperti yang ditunjukkan, jika fleet hanya menyertakan cluster dari satu project, dan semuanya terdaftar ke fleet, maka hasilnya sama seperti jika Anda hanya menggunakan Workload Identity Federation untuk GKE tanpa fleet: semua cluster adalah penyedia identitas dalam pool workload identity pool, dan workload menggunakan identitas yang sama dengan yang akan digunakan di Workload Identity Federation for GKE. Namun, jika fleet memiliki cluster anggota di beberapa project, Workload Identity Federation fleet menggabungkan kumpulan identitas per project ke dalam satu kumpulan identitas seluruh fleet, yang dihosting di project host fleet.

Seperti yang akan Anda lihat dalam contoh berikut, beberapa kerumitan dapat terjadi ketika hanya ada tumpang tindih sebagian antara kumpulan cluster dalam sebuah project dan kumpulan cluster dalam project tersebut yang merupakan anggota fleet.

Skenario 1: Armada project tunggal dengan semua cluster terdaftar

Dalam skenario ini, semua cluster anggota fleet berada dalam project host fleet, dan semua cluster dalam project tersebut adalah anggota fleet.

Diagram yang menunjukkan project dengan semua cluster di fleet yang sama

Seperti dijelaskan di bagian sebelumnya, menggunakan Workload Identity Federation seluruh fleet dalam skenario ini sama dengan menggunakan Workload Identity Federation reguler untuk GKE, dan tidak ada risiko tambahan.

Skenario 2: Armada project tunggal dengan beberapa cluster terdaftar

Dalam skenario ini, fleet berisi dua klaster, keduanya dalam project host fleet Project 1. Project host fleet juga berisi cluster ketiga yang bukan merupakan anggota fleet, dengan Workload Identity Federation for GKE aktif.

Diagram yang menunjukkan project dengan beberapa cluster di fleet yang sama.

Hal ini berarti:

  • Cluster 1, 2, dan 3 ditambahkan oleh GKE ke kumpulan workload identity project project-1.svc.goog.id.
  • Cluster 1 dan 2 ditambahkan oleh fleet ke kumpulan workload identity pool, yang (karena ini adalah project host fleet) juga merupakan kumpulan identitas workload project project-1.svc.goog.id.

Administrator ingin memberikan izin untuk beban kerja yang berjalan di namespace pada semua cluster di seluruh fleet. Dia menggunakan serviceAccount:project-1.svc.goog.id[namespace/ksa] sebagai identitas untuk memberikan akses. Namun, workload dalam namespace tersebut di Cluster 3, yang bukan bagian dari fleet, kini memiliki akses yang sama. Hal ini karena Cluster 3 berada dalam kumpulan identitas workload project, yang (karena ini adalah project host fleet) sama dengan kumpulan identitas workload fleet. Dengan kata lain, administrator mungkin bermaksud memberikan izin hanya ke cluster dalam suatu fleet, tetapi mengingat implementasi fleet Workload Identity Federation, cluster non-fleet juga mungkin mendapatkan akses.

Kemungkinan mitigasi

Salah satu solusi yang memungkinkan di sini adalah membuat project khusus untuk menghosting fleet tanpa cluster di dalamnya, yang diberlakukan oleh Kebijakan Organisasi Kustom pada API container. Hal ini memberikan pemisahan yang jelas antara domain kepercayaan kumpulan workload identity pool dari domain kepercayaan level project GKE.

Diagram yang menunjukkan dua project, satu dengan cluster, yang satu bertindak sebagai project host fleet

Kemudian, administrator dapat memilih domain kepercayaan yang sesuai saat memberikan izin ke beban kerja. Misalnya, mereka dapat menggunakan serviceAccount:project-0.svc.goog.id[namespace/ksa] untuk memberikan izin ke workload dengan namespace di seluruh fleet. Cluster 3 anggota non-fleet bukan bagian dari kumpulan workload identity dalam penyiapan ini, sehingga tidak akan mendapatkan akses.

Solusi ini berfungsi untuk cluster di Google Cloud dan cluster yang terpasang.

Skenario 3: Armada multi-project dengan beberapa cluster terdaftar

Dalam skenario ini, fleet memiliki anggota dari dua project, Project 1 dan Project 2.

Diagram yang menunjukkan fleet dengan cluster dari dua project.

Administrator ingin memberikan izin untuk workload yang berjalan di namespace di semua cluster pada Project 1, menggunakan Workload Identity Federation reguler untuk GKE. Namun, karena Cluster 4 terdaftar ke fleet, dan Project 1 adalah project host fleet, workload pada Cluster 4 di Project 2 juga akan mendapatkan izin yang sama.

Kemungkinan mitigasi

Seperti dalam skenario sebelumnya, mitigasi yang mungkin dilakukan di sini adalah dengan membuat project host fleet khusus tanpa cluster di dalamnya. Sekali lagi, hal ini memungkinkan administrator membedakan antara identitas dari kumpulan identitas fleet dan kumpulan identitas project setiap cluster saat menyiapkan kontrol akses.

Skenario 4: Mempertimbangkan kesamaan namespace

Kumpulan workload identity bukan satu-satunya hal yang berpotensi menimbulkan kebingungan saat menggunakan Workload Identity Federation. Seperti yang Anda ketahui dari Fitur fleet rencana, banyak fitur fleet, termasuk Workload Identity Federation fleet menggunakan asumsi kesamaan namespace untuk menyederhanakan konfigurasi dan pengelolaan di seluruh fleet. Artinya, fitur tersebut memperlakukan namespace dengan nama yang sama di beberapa cluster anggota fleet seolah-olah namespace tersebut sama. Dalam contoh ini, administrator telah memberikan izin ke beban kerja di namespace NS1 yang berjalan di cluster anggota fleet Cluster 1 dan Cluster 2.

Diagram yang menampilkan cluster dari dua project dengan namespace yang sama.

Namun, pengguna (tidak sengaja atau dengan niat jahat) membuat namespace dengan nama yang sama di cluster anggota fleet lainnya. Karena asumsi kesamaan namespace, beban kerja dalam namespace tersebut otomatis mendapatkan hak istimewa yang sama seperti beban kerja NS1 yang sah di Cluster 1 dan Cluster 2.

Kemungkinan mitigasi

Tetapkan izin agar hanya sekelompok kecil peran tepercaya yang dapat membuat namespace dalam cluster.