Mengurangi risiko kesamaan identitas di fleet multi-tenant

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Halaman ini ditujukan untuk admin dan operator Platform serta untuk engineer Keamanan yang ingin meminimalkan risiko yang terkait dengan kesamaan identitas dalam 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 Cloud dan di beberapa project.
• Workload identity pool: entitas yang menyediakan identitas ke workload dalam format yang kompatibel dengan Identity and Access Management (IAM). Setiap cluster adalah penyedia identitas dalam workload identity pool.

Kesamaan identitas di fleet

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

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

Di Workload Identity Federation fleet dan Workload Identity Federation untuk GKE, Anda menggunakan kebijakan izin IAM untuk memberikan peran pada resource Google Cloud tertentu kepada entitas di cluster, seperti Akun Layanan Kubernetes atau Pod. Dalam kebijakan izin, Anda merujuk ke entitas ini menggunakan ID akun utama, yang merupakan sintaksis penamaan yang dapat dibaca oleh IAM. ID utama mencakup nama kumpulan identitas workload yang digunakan cluster dan informasi lain yang memilih entity tertentu dalam cluster. Misalnya, ID akun 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 akun utama:

• 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 sementara yang dihasilkan cluster. Token akses ini mencakup ID akun utama entitas yang membuat permintaan. IAM menggunakan ID akun utama untuk memastikan bahwa kebijakan izin mengizinkan entitas untuk melakukan operasi yang diminta.

Implikasi kesamaan identitas untuk fleet multi-tenant

ID akun utama menghasilkan kesamaan identitas, yang berarti bahwa setiap entity di lingkungan yang cocok dengan ID akun utama tertentu dianggap oleh IAM sebagai hal yang sama. Dengan Workload Identity Federation untuk GKE project tunggal, kesamaan identitas berlaku untuk semua entitas yang memiliki ID utama yang sama dalam project tersebut. Namun, dengan Workload Identity Federation fleet, kesamaan identitas ini berlaku untuk semua entity yang memiliki ID utama yang sama di seluruh fleet, terlepas dari project cluster.

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

Jika fleet Anda hanya menjalankan cluster di project host fleet, implikasi kesamaan identitasnya sama dengan Workload Identity Federation untuk GKE. Namun, jika fleet Anda memiliki cluster yang berjalan di project lain, kesamaan identitas akan diperluas ke semua cluster terdaftar dalam 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.

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

Pertimbangkan konfigurasi armada berikut:

• Semua cluster anggota fleet berada dalam 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 dalam 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.

Satu fleet project dengan beberapa cluster 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 entitas dalam satu cluster dalam project berlaku untuk entitas lain dalam project yang cocok dengan ID akun utama. Hal ini dapat mengakibatkan pemberian izin yang tidak disengaja kepada entitas yang bukan bagian dari armada. Misalnya, memberikan peran ke ID akun utama yang memilih akun layanan tertentu di 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 kompleksitas ini:

• Konfigurasikan cluster anggota fleet untuk menggunakan kumpulan workload identity yang dikelola sendiri (Pratinjau). Hal ini memastikan bahwa entitas dalam cluster anggota fleet memiliki ID utama yang berbeda dari cluster non-anggota. Untuk mengetahui detailnya, lihat Mengautentikasi ke Google Cloud API dari workload fleet dengan kepercayaan campuran.

• Buat project host fleet khusus dan gunakan kebijakan organisasi untuk mencegah project host fleet khusus menjalankan cluster. Hal ini memisahkan domain kepercayaan workload identity pool seluruh fleet dari domain kepercayaan tingkat project GKE. Hanya cluster terdaftar yang berbagi kumpulan workload identity secara keseluruhan 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 dibatalkan pendaftarannya.
• Semua cluster di project-1 menggunakan kumpulan workload identity project yang dikelola Google, yang juga merupakan kumpulan workload identity seluruh fleet default.
• Cluster anggota fleet di project-2 menggunakan workload identity pool secara keseluruhan fleet.

Dalam skenario ini, izin apa pun yang Anda berikan ke entity dalam project host fleet juga berlaku untuk entity dalam cluster anggota dari project-2, karena semuanya memiliki workload identity pool yang sama.

Untuk mencoba dan 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 akan 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 yang serupa

Kesamaan identitas dalam 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 untuk hanya mengizinkan sekumpulan pengguna tepercaya membuat, memperbarui, atau menghapus namespace dan akun layanan Kubernetes.

• Untuk IAM, izin berikut memberikan akses ini:

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

• Untuk kontrol akses berbasis peran (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