Praktik terbaik untuk menggunakan Workload Identity fleet

Seperti yang Anda ketahui dari Melakukan autentikasi ke API dan layanan dari workload fleet, Workload Identity Federation di seluruh fleet adalah fitur fleet yang canggih yang mempermudah penyiapan autentikasi ke Google Cloud untuk aplikasi Anda di seluruh project. Namun, Workload Identity Federation for GKE dapat memiliki pertimbangan kontrol akses di atas dan di luar pertimbangan untuk Workload Identity Federation reguler untuk GKE. Panduan ini memberikan beberapa contoh potensi masalah ini 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 terkait penerapan fitur armada lainnya, lihat Merencanakan fitur armada.

Kumpulan identitas project dan fleet

Untuk memahami mengapa Workload Identity Federation di seluruh fleet memerlukan penerapan yang cermat, terutama saat menggunakan fleet multi-project, mari kita pelajari lebih lanjut cara kerja Workload Identity Federation reguler untuk GKE dan Workload Identity Federation fleet. Dalam kedua kasus tersebut, beban kerja diautentikasi menggunakan token berumur pendek yang dihasilkan oleh cluster, dengan setiap cluster ditambahkan sebagai penyedia identitas ke kumpulan workload identity khusus. Workload yang berjalan di namespace tertentu kemudian dapat berbagi identitas IAM yang sama di seluruh cluster.

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

  1. GKE membuat workload identity pool yang dikelola Google di project cluster: PROJECT_ID.svc.goog.id.
  2. GKE menambahkan cluster sebagai penyedia identitas ke kumpulan.
  3. Akibatnya, beban kerja yang berjalan di namespace tertentu akan memiliki identitas IAM yang sama di seluruh cluster dalam project. Identitas dalam bentuk ini: serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME].

Workload Identity Federation secara keseluruhan fleet otomatis diaktifkan saat Anda menambahkan cluster dengan Workload Identity Federation for GKE yang diaktifkan ke fleet, termasuk cluster Autopilot, cluster Standard dengan fitur yang diaktifkan secara eksplisit, dan cluster GKE di luar Google Cloud.

Berikut adalah yang terjadi saat pengguna mendaftarkan cluster dengan Workload Identity Federation untuk GKE yang diaktifkan ke fleet:

  1. FLEET_PROJECT_ID.svc.goog.id workload identity pool seluruh fleet yang dikelola Google di project host fleet akan dibuat, jika kumpulan belum ada. Ini sama dengan workload identity pool project untuk project host fleet.
  2. Cluster ditambahkan sebagai penyedia identitas ke kumpulan.
  3. Akibatnya, workload yang berjalan di namespace tertentu akan memiliki identitas IAM yang sama di seluruh cluster dalam fleet. Kami menyebutnya sebagai kesamaan implisit identitas workload fleet. Identitas dalam bentuk ini: serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]. Workload fleet di project yang berbeda 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, hasilnya sama seperti jika Anda hanya menggunakan Workload Identity Federation untuk GKE tanpa fleet: semua cluster adalah penyedia identitas dalam workload identity pool seluruh project, dan beban kerja menggunakan identitas yang sama dengan yang akan digunakan dengan Workload Identity Federation untuk GKE. Namun, jika fleet memiliki cluster anggota di beberapa project, Workload Identity Federation fleet akan menggabungkan kumpulan identitas per project menjadi satu kumpulan identitas seluruh fleet, yang dihosting di project host fleet.

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

Skenario 1: Satu fleet project 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 dalam fleet yang sama

Seperti yang 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: Satu fleet project dengan beberapa cluster yang terdaftar

Dalam skenario ini, fleet berisi dua cluster, keduanya dalam project host fleet Project 1. Project host fleet juga berisi cluster ketiga yang bukan anggota fleet, yang telah mengaktifkan Workload Identity Federation untuk GKE.

Diagram yang menampilkan project dengan beberapa cluster dalam fleet yang sama.

Hal ini berarti:

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

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

Kemungkinan mitigasi

Salah satu solusi yang mungkin di sini adalah membuat project khusus untuk menghosting fleet tanpa cluster di dalamnya, yang diterapkan oleh Kebijakan Organisasi Kustom di API penampung. Hal ini memberikan pemisahan yang jelas antara domain kepercayaan kumpulan identitas beban kerja armada dari domain kepercayaan tingkat project GKE.

Diagram yang menampilkan dua project, satu dengan cluster, satu lagi 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 beban kerja dengan namespace di seluruh fleet. Cluster 3 yang bukan anggota fleet bukan bagian dari kumpulan identitas workload tersebut dalam penyiapan ini, sehingga tidak mendapatkan akses.

Solusi ini berfungsi untuk cluster di Google Cloud dan cluster terlampir.

Skenario 3: Fleet multi-project dengan beberapa cluster terdaftar

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

Diagram yang menampilkan fleet dengan cluster dari dua project.

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

Kemungkinan mitigasi

Seperti pada skenario sebelumnya, mitigasi yang mungkin dilakukan di sini adalah 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: Pertimbangkan kesamaan namespace

Workload identity pool bukan satu-satunya area yang berpotensi membingungkan saat menggunakan Workload Identity Federation. Seperti yang Anda ketahui dari Merencanakan fitur fleet, banyak fitur fleet termasuk Workload Identity Federation fleet menggunakan asumsi kesamaan namespace untuk menyederhanakan konfigurasi dan pengelolaan di seluruh fleet. Artinya, fitur ini memperlakukan namespace dengan nama yang sama di beberapa cluster anggota fleet seolah-olah namespace tersebut sama. Dalam contoh ini, administrator telah memberikan izin ke workload 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 telah (secara tidak sengaja atau dengan niat jahat) membuat namespace dengan nama yang sama di cluster anggota fleet lain. Karena asumsi kesamaan namespace, workload di namespace tersebut secara otomatis mendapatkan hak istimewa yang sama dengan workload NS1 yang sah di Cluster 1 dan Cluster 2.

Kemungkinan mitigasi

Tetapkan izin sehingga hanya sekelompok kecil peran tepercaya yang dapat membuat namespace di cluster.