Multi-tenancy cluster

Halaman ini berisi penjelasan tentang multi-tenancy cluster di Google Kubernetes Engine (GKE). Hal ini mencakup cluster yang dibagikan kepada pengguna berbeda di satu organisasi, serta cluster yang dibagikan kepada instance per pelanggan dari aplikasi Software as a Service (SaaS). Multi-tenancy cluster adalah solusi alternatif untuk mengelola banyak cluster tenant tunggal.

Halaman ini juga berisi rangkuman berbagai fitur Kubernetes dan GKE yang dapat digunakan untuk mengelola cluster multi-tenant.

Apa yang dimaksud dengan multi-tenancy?

Cluster multi-tenant digunakan bersama oleh beberapa pengguna dan/atau workload yang disebut sebagai "tenant". Operator cluster multi-tenant harus memisahkan tenant satu sama lain untuk meminimalkan kerugian yang dapat terjadi pada cluster atau tenant lain akibat tenant yang berbahaya atau disusupi. Selain itu, resource cluster harus dialokasikan secara merata ke tiap-tiap tenant.

Saat merencanakan arsitektur multi-tenant, Anda harus mempertimbangkan lapisan isolasi resource di Kubernetes: cluster, namespace, node, Pod, dan container. Anda juga harus mempertimbangkan implikasi keamanan dari membagikan jenis resource yang berbeda kepada banyak tenant. Misalnya, menjadwalkan Pod dari tenant berbeda di node yang sama dapat mengurangi jumlah mesin yang diperlukan di cluster. Di samping itu, Anda mungkin perlu mencegah agar workload tertentu tidak ditempatkan bersama-sama. Misalnya, Anda mungkin tidak mengizinkan kode yang tidak tepercaya dari luar organisasi untuk berjalan di node yang sama dengan kontainer yang memproses informasi sensitif.

Kubernetes tidak dapat menjamin isolasi yang benar-benar aman di antara tenant, tetapi ada sejumlah fitur yang mungkin cukup untuk kasus penggunaan tertentu. Anda dapat memisahkan setiap tenant dan resource Kubernetes-nya ke dalam namespace-nya masing-masing. Kemudian, Anda dapat menggunakan kebijakan untuk menerapkan isolasi tenant. Kebijakan biasanya dicakup oleh namespace dan dapat digunakan untuk membatasi akses API, membatasi penggunaan resource, dan membatasi kontainer mana yang diizinkan.

Tenant dari cluster multi-tenant berbagi:

Terdapat beberapa keuntungan dari mengoperasikan cluster multi-tenant dibandingkan dengan mengoperasikan beberapa cluster tenant tunggal:

  • Mengurangi overhead pengelolaan
  • Mengurangi fragmentasi resource
  • Tidak perlu menunggu pembuatan cluster untuk tenant baru

Kasus penggunaan multi-tenancy

Bagian ini menjelaskan cara mengonfigurasi cluster untuk berbagai kasus penggunaan multi-tenancy.

Multi-tenancy perusahaan

Di lingkungan perusahaan, tenant cluster-nya adalah tim yang berbeda dalam organisasi. Biasanya, setiap tenant memiliki namespace masing-masing. Model alternatif multi-tenancy dengan satu tenant per cluster, atau satu tenant per Google Cloud project, lebih sulit dikelola. Traffic jaringan dalam namespace tidak dibatasi. Traffic jaringan antar-namespace harus diizinkan secara eksplisit. Kebijakan ini dapat diterapkan menggunakan kebijakan jaringan Kubernetes.

Pengguna cluster dikelompokkan ke dalam 3 peran berbeda, bergantung pada hak istimewa mereka:

Administrator cluster
Peran ini ditujukan untuk administrator dari seluruh cluster, yang mengelola semua tenant. Administrator cluster dapat membuat, membaca, mengupdate, dan menghapus objek kebijakan apa pun. Mereka dapat membuat namespace dan menetapkannya kepada administrator namespace.
Administrator namespace
Peran ini ditujukan untuk administrator tenant tunggal tertentu. Administrator namespace dapat mengelola pengguna di namespace mereka.
Developer
Anggota peran ini dapat membuat, membaca, mengupdate, dan menghapus objek non-kebijakan dalam namespace, seperti Pod, Tugas, dan Ingress. Developer hanya memiliki hak istimewa di namespace yang mereka miliki aksesnya.

Untuk mengetahui informasi tentang cara menyiapkan beberapa cluster multi-tenant untuk organisasi perusahaan, baca Praktik terbaik untuk multi- tenancy perusahaan.

Multi-tenancy penyedia SaaS

Tenant untuk cluster penyedia SaaS adalah instance per pelanggan aplikasi, dan bidang kontrol SaaS-nya. Untuk memanfaatkan kebijakan dalam cakupan namespace, instance aplikasi harus diatur ke dalam namespace-nya masing-masing, demikian pula dengan komponen bidang kontrol SaaS. Pengguna akhir tidak dapat berinteraksi dengan bidang kontrol Kubernetes secara langsung. Sebagai gantinya, mereka menggunakan antarmuka SaaS, yang kemudian berinteraksi dengan bidang kontrol Kubernetes.

Sebagai contoh, platform blogging dapat berjalan di cluster multi-tenant. Dalam kasus ini, tenant-nya adalah instance blog setiap pelanggan dan juga bidang kontrol platform itu sendiri. Bidang kontrol platform dan setiap blog yang dihosting akan berjalan di namespace terpisah. Pelanggan akan membuat dan menghapus blog, serta mengupdate versi software blogging mereka melalui antarmuka platform tanpa mengetahui cara cluster beroperasi:

Penerapan kebijakan multi-tenancy

GKE dan Kubernetes memberikan beberapa fitur yang dapat digunakan untuk mengelola cluster multi-tenant. Berikut ringkasan dari beberapa fitur tersebut:

Kontrol akses

GKE memiliki dua sistem kontrol akses, yaitu Identity and Access Management (IAM) dan role-based access control (RBAC). IAM adalah sistem kontrol akses untuk mengelola autentikasi dan otorisasi untuk resource. Google CloudGoogle CloudAnda dapat menggunakan IAM untuk memberi pengguna akses ke resource GKE dan Kubernetes. RBAC telah disertakan dalam Kubernetes dan memberikan izin terperinci untuk resource dan operasi tertentu dalam cluster Anda.

Lihat Ringkasan kontrol akses untuk mengetahui informasi selengkapnya tentang berbagai opsi ini dan kapan harus menggunakannya.

Baca Panduan cara kerja RBAC dan panduan cara kerja IAM untuk mempelajari cara menggunakan sistem kontrol akses ini.

Anda dapat menggunakan izin IAM dan RBAC beserta namespace untuk membatasi interaksi pengguna dengan resource cluster di Google Cloud konsol. Untuk mengetahui informasi selengkapnya, lihat Mengaktifkan akses dan melihat resource cluster berdasarkan namespace.

Kebijakan jaringan

Kebijakan jaringan cluster memberi Anda kontrol atas komunikasi di antara Pod cluster. Kebijakan menentukan namespace, label, dan rentang alamat IP mana saja yang dapat berkomunikasi dengan Pod.

Lihat panduan kebijakan jaringan untuk mengetahui petunjuk tentang cara mengaktifkan penerapan kebijakan jaringan di GKE.

Ikuti tutorial kebijakan jaringan untuk mempelajari cara menulis kebijakan jaringan.

Kuota resource

Kuota resource mengelola jumlah resource yang digunakan oleh objek dalam namespace. Anda dapat menetapkan kuota untuk penggunaan CPU dan memori, atau untuk jumlah objek. Kuota resource memungkinkan Anda untuk memastikan bahwa tidak ada tenant yang menggunakan resource cluster melebihi jumlah yang ditetapkan untuknya.

Lihat dokumentasi kuota resource untuk mengetahui informasi selengkapnya.

Kontrol penerimaan Pod berbasis kebijakan

Agar Pod yang melanggar batas keamanan tidak berjalan di cluster Anda, gunakan pengontrol penerimaan. Pengontrol penerimaan dapat memeriksa spesifikasi Pod berdasarkan kebijakan yang Anda tetapkan, dan dapat mencegah Pod yang melanggar kebijakan tersebut agar tidak berjalan di cluster.

GKE mendukung jenis kontrol akses berikut:

Anti-afinitas Pod

Anda dapat menggunakan anti-afinitas Pod untuk mencegah Pod dari tenant berbeda dijadwalkan pada node yang sama. Batasan anti-afinitas didasarkan pada label Pod labels. Sebagai contoh, spesifikasi Pod di bawah mendeskripsikan Pod dengan label "team": "billing", dan aturan anti-afinitas yang mencegah Pod agar tidak dijadwalkan bersama dengan Pod yang tidak memiliki label.

apiVersion: v1
kind: Pod
metadata:
  name: bar
  labels:
    team: "billing"
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: "kubernetes.io/hostname"
        labelSelector:
          matchExpressions:
          - key: "team"
            operator: NotIn
            values: ["billing"]

Kekurangan dari teknik ini adalah pengguna yang berbahaya dapat mengakali aturan ini dengan menerapkan label team: billing ke Pod arbitrer. Anti-afinitas Pod saja tidak dapat menerapkan kebijakan dengan aman di cluster yang memiliki tenant tidak tepercaya.

Lihat dokumentasi anti-afinitas Pod untuk mengetahui informasi selengkapnya.

Node khusus dengan taint dan toleransi

Taint node adalah cara alternatif untuk mengontrol penjadwalan workload. Anda dapat menggunakan taint node untuk mencadangkan node khusus agar hanya digunakan oleh tenant tertentu. Sebagai contoh, Anda dapat menetapkan node yang dilengkapi GPU secara khusus kepada tenant tertentu yang workload-nya memerlukan GPU. Untuk cluster Autopilot, toleransi node hanya didukung untuk pemisahan workload. Taint node secara otomatis ditambahkan oleh penyediaan otomatis node sesuai kebutuhan.

Untuk menetapkan node pool secara khusus ke tenant tertentu, terapkan taint dengan effect: "NoSchedule" ke node pool. Kemudian, hanya Pod dengan toleransi yang sesuai yang dapat dijadwalkan ke node dalam node pool.

Kekurangan dari teknik ini adalah pengguna yang berbahaya dapat menambahkan toleransi ke Pod mereka untuk mendapatkan akses ke node pool khusus. Taint dan toleransi node saja tidak dapat menerapkan kebijakan dengan aman di cluster yang memiliki tenant tidak tepercaya.

Untuk mengetahui informasi selengkapnya, lihat Taint dan Toleransi dalam dokumentasi Kubernetes.

GKE Sandbox

GKE Sandbox memberikan lapisan keamanan tambahan untuk cluster multi-tenant dengan mengisolasi workload yang tidak tepercaya dari kernel host di node cluster Anda. GKE Sandbox menggunakan gVisor, teknologi sandboxing container open source, untuk menyediakan kernel ruang pengguna terpisah untuk setiap Pod.

GKE Sandbox sangat berguna untuk penyedia SaaS atau organisasi yang menjalankan kode yang tidak tepercaya, karena membantu mencegah tenant yang berbahaya keluar dari containernya atau memengaruhi kernel host. Untuk mengetahui informasi selengkapnya, lihat GKE Sandbox.

Pengelolaan memori multi-tenant

Kernel Linux memastikan bahwa halaman memori yang dialokasikan ke proses baru diisi dengan nol (dibersihkan) pada saat alokasi. Proses tersebut juga berlaku untuk pembuatan container, dan mencegah container baru membaca data sisa yang tertinggal dalam memori oleh container sebelumnya. Namun, ini adalah batas logis yang dikelola oleh sistem operasi host. Penyerang yang keluar dari container, atau pengguna dengan hak istimewa root di VM node, dapat melewati perlindungan ini untuk mengakses konten memori mentah dari container lain.

Untuk memperkuat batas ini, gunakan GKE Sandbox untuk melindungi dari container breakout, gunakan kebijakan penerimaan untuk membatasi Pod agar tidak mengakses host, dan batasi akses langsung ke node.

Resource GPU dan TPU standar tidak otomatis membersihkan High Bandwidth Memory (HBM), Static Ram (SRAM), atau Control Registers di antara penetapan Pod. Data sisa dari workload sebelumnya mungkin tetap ada di memori akselerator. Jika VM tidak di-reboot di antara workload, konfigurasi hanya cocok untuk multi-tenancy tepercaya, yang semua workload yang dijadwalkan pada akselerator yang sama berbagi sensitivitas keamanan yang sama.

Untuk workload tanpa kepercayaan bersama, VM reboot diperlukan untuk menghapus memori akselerator di antara setiap workload yang dijadwalkan. Menghapus VM juga akan menyebabkan memori dihapus sebelum akselerator dilampirkan kembali ke VM baru. Untuk mengetahui informasi selengkapnya tentang konfigurasi dan berbagi akselerator, lihat dokumentasi TPU dan GPU GKE.

Berbagi akselerator seperti GPU dan TPU

Berbagi akselerator GPU atau TPU antar-Pod membawa risiko tambahan. GPU dan TPU mungkin atau mungkin tidak memberikan perlindungan terhadap akses bersama. Perlindungan ini dapat bergantung pada versi hardware, versi driver, dan konfigurasi sistem runtime. Tabel berikut menyoroti berbagai pendekatan dan risiko yang terkait dengan setiap pendekatan.

Pod yang saling memercayai dapat memutuskan untuk menerima spektrum risiko yang luas. Tabel ini menunjukkan tingkat risiko untuk setiap tingkat isolasi.

Arsitektur Permukaan Serangan Utama Ringkasan Keamanan
Pod di node yang sama secara langsung berbagi akselerator, termasuk GPU time-sharing dan NVIDIA MPS. Memori GPU &Status Global Pod rentan satu sama lain, dan harus saling memercayai.
Pod di node yang sama secara langsung berbagi akselerator dan menggunakan GKE Sandbox, termasuk GPU time-sharing dan NVIDIA MPS. Memori GPU &Driver Host GKE Sandbox mengisolasi kernel workload dari kernel host. Meskipun gVisor mengurangi permukaan serangan GPU yang diekspos ke aplikasi, gVisor tidak memberikan pemisahan di dalam lingkungan GPU, yang tetap dibagikan. Untuk mengetahui informasi selengkapnya, lihat: Dukungan GPU - Keamanan.
Pod di node yang sama memiliki akselerator khusus, termasuk NVIDIA MIG. Kernel Host (melalui Driver) Pod mungkin masih disusupi oleh kerentanan akselerator atau driver yang memungkinkan eskalasi ke kernel host.
Pod di node yang sama memiliki akselerator khusus, termasuk NVIDIA MIG, dan menggunakan GKE Sandbox. Antarmuka Driver Host (nvproxy) GKE Sandbox mengisolasi kernel, tetapi antarmuka driver GPU host (nvproxy) tetap menjadi permukaan serangan bersama. Eksploitasi driver mungkin memungkinkan host kernel escape. Kebocoran side-channel antara instance MIG juga memungkinkan.
Setiap Pod berjalan di node khusus, yang memiliki akselerator khusus. Batas VM / Hypervisor Direkomendasikan untuk workload yang tidak tepercaya. Setiap kompromi terkandung dalam satu VM.

Langkah berikutnya