Mengurangi risiko kesamaan identitas di fleet multi-tenant

Halaman ini ditujukan untuk admin dan operator Platform serta Engineer keamanan yang ingin meminimalkan risiko yang terkait dengan kesamaan identitas di fleet.

Sebelum membaca halaman ini, pastikan Anda memahami konsep dalam Tentang Workload Identity Federation armada.

Terminologi

Halaman ini menggunakan terminologi berikut:

• Workload Identity Federation for GKE: fitur yang memberikan identitas ke workload GKE dalam satu Google Cloud project.
• Fleet Workload Identity Federation: fitur yang memperluas Workload Identity Federation for GKE ke beban kerja di seluruh fleet, termasuk di luar Google Clouddan di beberapa project.
• Workload identity pool: entity yang menyediakan identitas untuk workload dalam format yang kompatibel dengan Identity and Access Management (IAM). Setiap cluster adalah penyedia identitas di workload identity pool.

Kesamaan identitas di fleet

Workload identity pool adalah entitas yang menyediakan identitas untuk workload dalam format yang dapat digunakan IAM saat mengautentikasi dan mengizinkan permintaan. Dengan Workload Identity Federation untuk GKE, setiap project memiliki workload identity pool tetap yang dikelola Google secara default dan unik untuk project tersebut.

Dengan Workload Identity Federation fleet, workload identity pool yang dikelola Google untuk project host fleet adalah workload identity pool default untuk semua cluster yang Anda daftarkan ke fleet, terlepas dari apakah cluster tersebut berada di project lain atau cloud lain. Anda dapat secara opsional menyiapkan kumpulan identitas workload yang dikelola sendiri untuk cluster tertentu agar digunakan, bukan kumpulan default.

Di Penggabungan Workload Identity fleet dan Penggabungan Workload Identity untuk GKE, Anda menggunakan kebijakan izin IAM untuk memberikan peran pada resource Google Cloud tertentu kepada entitas di cluster Anda, seperti ServiceAccount Kubernetes atau Pod. Dalam kebijakan izin, Anda merujuk ke entitas ini menggunakan ID utama, yang merupakan sintaksis penamaan yang dapat dibaca IAM. ID utama mencakup nama kumpulan identitas workload yang digunakan cluster dan informasi lain yang memilih entity tertentu di cluster. Misalnya, ID entity utama berikut memilih Akun Layanan Kubernetes dalam namespace:

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

Dalam contoh ini, kolom berikut memiliki informasi tentang pemegang akun:

• PROJECT_NUMBER: nomor project dari project host fleet.
• WORKLOAD_IDENTITY_POOL_NAME: nama workload identity pool.
• NAMESPACE: nama namespace.
• SERVICEACCOUNT: nama ServiceAccount Kubernetes.

Permintaan ke Google Cloud API diautentikasi menggunakan token akses OAuth 2.0 berumur pendek yang dibuat oleh cluster. Token akses ini mencakup ID utama entitas yang membuat permintaan. IAM menggunakan ID akun utama untuk memastikan bahwa kebijakan izin mengizinkan entitas melakukan operasi yang diminta.

Implikasi kesamaan identitas untuk fleet multi-tenant

ID entity utama menghasilkan kesamaan identitas, yang berarti bahwa setiap entity di lingkungan yang cocok dengan ID entity utama tertentu dianggap oleh IAM sebagai hal yang sama. 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 fleet, kesamaan identitas ini berlaku untuk semua entitas yang berbagi ID utama di seluruh fleet, terlepas dari project cluster.

Misalnya, dengan ID utama di bagian sebelumnya, permintaan dari Pod yang menggunakan ServiceAccount yang sama, namespace yang sama, dan workload identity pool yang sama akan mendapatkan ID utama yang sama, terlepas dari cluster atau project.

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, kesamaan identitas akan diperluas ke semua cluster yang terdaftar di fleet.

Contoh kompleksitas untuk kesamaan identitas fleet

Contoh skenario berikut menjelaskan potensi kompleksitas kesamaan identitas yang dapat terjadi saat Anda menerapkan Workload Identity Federation armada. Setiap skenario memberikan kemungkinan mitigasi yang dapat membantu Anda mengatasi kompleksitas ini.

Fleet project tunggal dengan semua cluster terdaftar dan workload identity pool yang sama

Pertimbangkan konfigurasi armada berikut:

• Semua cluster anggota fleet berada di project host fleet.
• Semua cluster dalam project adalah anggota fleet.
• Semua cluster menggunakan workload identity pool yang sama.

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

Seperti yang dijelaskan di bagian Implikasi kesamaan identitas untuk fleet, menggunakan Workload Identity Federation fleet dalam skenario ini sama dengan menggunakan Workload Identity Federation untuk GKE, dan tidak ada risiko tambahan.

Fleet project tunggal dengan beberapa cluster yang terdaftar dan workload identity pool yang sama

Pertimbangkan konfigurasi armada berikut:

• Fleet berisi dua cluster, yang keduanya berjalan di project host fleet.
• Project host fleet berisi cluster ketiga yang bukan anggota fleet.
• Cluster yang bukan anggota fleet juga mengaktifkan Workload Identity Federation untuk GKE.
• Semua cluster dalam project menggunakan kumpulan identitas beban kerja yang sama

Dengan konfigurasi ini, setiap peran yang Anda berikan ke suatu entitas dalam satu cluster di project akan berlaku untuk entitas lain dalam project yang cocok dengan ID prinsipal. Hal ini dapat mengakibatkan pemberian izin yang tidak disengaja kepada entitas yang bukan bagian dari armada. Misalnya, memberikan peran ke ID principal yang memilih akun layanan tertentu dalam namespace memiliki implikasi berikut:

• Workload yang berjalan di namespace yang ditentukan dan menggunakan akun layanan yang ditentukan di cluster anggota fleet berbagi akses.
• Beban kerja yang berjalan di cluster non-anggota ketiga yang menggunakan namespace dan nama akun layanan yang sama juga mendapatkan akses yang sama.

Saran berikut dapat membantu mengatasi kerumitan ini:

• Konfigurasi cluster anggota fleet untuk menggunakan kumpulan identitas workload yang dikelola sendiri (Pratinjau). Hal ini memastikan bahwa entitas di cluster anggota fleet memiliki ID utama yang berbeda dari cluster non-anggota. Untuk mengetahui detailnya, lihat Mengautentikasi ke Google Cloud API dari beban kerja armada campuran.

• Buat project host fleet khusus dan gunakan kebijakan organisasi untuk mencegah project host fleet khusus menjalankan cluster. Hal ini memisahkan domain tepercaya workload identity pool di seluruh fleet dari domain tepercaya tingkat project GKE. Hanya cluster terdaftar yang berbagi kumpulan workload identity di seluruh fleet.

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

Armada multi-project dengan beberapa cluster terdaftar dan workload identity pool yang sama

Pertimbangkan konfigurasi armada berikut:

• Fleet berisi cluster anggota yang berjalan di dua project Google Cloud: project-1 dan project-2.
• project-1 adalah project host fleet. Semua cluster di project-1 adalah anggota fleet.
• project-2 berisi satu cluster anggota fleet dan satu cluster yang tidak terdaftar.
• Semua cluster di project-1 menggunakan workload identity pool yang dikelola Google di project, yang juga merupakan workload identity pool default di seluruh fleet.
• Cluster anggota fleet di project-2 menggunakan pool workload identity di seluruh fleet.

Dalam skenario ini, semua izin yang Anda berikan kepada entity di project host fleet juga berlaku untuk entity di cluster anggota dari project-2, karena semuanya berbagi workload identity pool yang sama.

Untuk mencoba mengatasi kompleksitas ini, buat project Google Cloud khusus untuk digunakan sebagai project host fleet. Cluster anggota fleet di project-1 dan di project-2 kemudian berbagi workload identity pool project khusus secara default. Kemudian, Anda dapat memberikan akses cakupan project ke cluster di project-1 dengan menggunakan workload identity pool untuk project-1 di ID utama.

Mencegah pembuatan identitas serupa

Kesamaan identitas di fleet mengharuskan Anda menerapkan kontrol akses dengan cermat untuk mencegah pembuatan identitas serupa secara sengaja atau tidak sengaja. Misalnya, pertimbangkan skenario saat Anda memberikan akses ke semua Pod yang menggunakan ServiceAccount tertentu di namespace. Jika seseorang membuat namespace dan ServiceAccount tersebut di cluster anggota fleet yang berbeda, Pod di cluster tersebut akan mendapatkan akses yang sama.

Untuk mengurangi kemungkinan masalah ini, gunakan mekanisme otorisasi agar hanya sekumpulan pengguna tepercaya yang dapat membuat, mengupdate, atau menghapus namespace dan akun layanan Kubernetes.

• Untuk IAM, izin berikut memberikan akses ini:

  • container.namespaces.*
  • container.serviceAccounts.*

• Untuk role-based access control (RBAC) Kubernetes, contoh ClusterRole berikut mengonfigurasi akses khusus untuk berinteraksi dengan resource Kubernetes ini:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: namespace-admin
  rules:
  - apiGroups: [""]
    resources: ["namespaces"]
    verbs: ["create","delete","update","patch"]
  ---
  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: serviceaccount-admin
  rules:
  - apiGroups: [""]
    resources: ["serviceaccounts"]
    verbs: ["create","delete","update","patch","impersonate"]
  

Langkah berikutnya

• Mengelola fitur tingkat fleet
• Mengamankan fleet Anda