GKE Sandbox

Container yang menjalankan kode yang tidak dikenal atau tidak tepercaya di cluster Google Kubernetes Engine (GKE) berpotensi menimbulkan risiko keamanan pada kernel host node Anda. Anda dapat melindungi kernel host dari ancaman ini dengan mengisolasi kode dari kernel. Dokumen ini menjelaskan cara GKE Sandbox membuat lapisan isolasi ini menggunakan teknologi seperti gVisor dan microVM.

Dokumen ini ditujukan untuk spesialis Keamanan yang ingin mengurangi permukaan serangan di node GKE mereka dan melindungi node mereka dari kode yang tidak tepercaya. Anda seharusnya sudah memahami hal-hal berikut:

• Panggilan sistem
• Arsitektur node GKE
• Sandbox dalam sistem komputer

Tentang sandboxing di GKE

Runtime container yang diinstal pada node, seperti containerd, memberikan tingkat isolasi antara proses container dan kernel yang berjalan di node. Namun, runtime container sering berjalan sebagai pengguna dengan hak istimewa di node dan memiliki akses ke sebagian besar panggilan sistem ke kernel host.

Di Kubernetes dan GKE, sandbox mengisolasi container yang sedang berjalan untuk membatasi potensi dampak eksploitasi atau error yang memengaruhi container lain atau runtime container. Anda dapat menjalankan container di sandbox untuk melindungi kernel instance Compute Engine yang mendasarinya dari kode yang tidak tepercaya atau tidak dikenal. Sandbox juga merupakan pengukuran defense-in-depth yang baik untuk melindungi container bernilai tinggi agar tidak terpengaruh oleh workload lain. Anda dapat menjalankan workload di sandbox menggunakan GKE Sandbox.

Potensi ancaman

Cacat pada runtime container atau kernel host dapat memungkinkan proses yang berjalan di dalam container untuk "keluar" dari container dan memengaruhi kernel node. Cluster multi-tenant dan cluster yang containernya menjalankan workload yang tidak tepercaya lebih rentan terhadap kerentanan keamanan daripada cluster lain. Contohnya mencakup:

• Organisasi yang mengizinkan pengguna mengupload dan menjalankan kode, seperti penyedia SaaS dan penyedia hosting web.
• Agen AI yang membuat dan menjalankan kode, sering kali tanpa pengawasan.

Teknologi sandbox yang digunakan GKE Sandbox membantu mengurangi potensi dampak berikut dari pelarian kontainer:

• Kode berbahaya atau rusak yang menyebabkan kernel host mengalami error dan membuat node tidak berfungsi.
• Tenant berbahaya yang memindahkan data tenant lain yang ada di memori atau di disk.
• Workload yang tidak tepercaya yang mengakses layanan Cloud de Confiance by S3NS atau metadata cluster lainnya.

Teknologi Sandbox di GKE

GKE Sandbox mendukung teknologi sandbox berikut, yang masing-masing menggunakan pendekatan berbeda untuk mengisolasi workload dan berfungsi baik untuk berbagai kasus penggunaan:

• gVisor: penerapan ulang ruang pengguna dari Linux kernel API yang tidak memerlukan hak istimewa yang ditingkatkan. Kernel ruang pengguna dan runtime container menerapkan ulang sebagian besar panggilan sistem dan melayaninya atas nama kernel host. Akses langsung ke kernel host dibatasi. Untuk mengetahui informasi selengkapnya tentang cara kerja kernel tamu, lihat panduan arsitektur gVisor.

• MicroVMs: virtual machine ringan yang menjalankan kernel dan sistem operasi Linux lengkap. Setiap Pod berjalan di microVM-nya sendiri, yang memberikan isolasi ketat dari Pod lain dan dari node host. GKE Sandbox menggunakan software Kata Containers open source dan monitor virtual machine (VMM) Cloud Hypervisor untuk membuat dan mengelola microVM.

Tabel berikut merangkum perbedaan utama antara gVisor dan microVM. Gunakan informasi ini untuk memilih teknologi sandbox yang sesuai dengan kasus penggunaan Anda.

Untuk mengetahui informasi selengkapnya yang dapat membantu Anda memutuskan aplikasi mana yang akan dijalankan di jenis sandbox tertentu, lihat Batasan.

Cara kerja permintaan sandbox

Untuk menjalankan aplikasi di sandbox, Anda melakukan hal berikut:

1. Aktifkan teknologi sandbox di node dengan menggunakan ComputeClass untuk membuat node secara otomatis atau dengan membuat node pool secara manual.
2. Minta sandbox untuk Pod menggunakan RuntimeClass yang sesuai untuk jenis sandbox tersebut, seperti gvisor atau microvm. Untuk mengetahui informasi selengkapnya, lihat Melakukan hardening pada pemisahan workload dengan GKE Sandbox.

GKE menjadwalkan Pod di node yang menggunakan teknologi sandbox yang diminta, yang kemudian menangani jalannya aplikasi di sandbox. Anda dapat secara opsional menjalankan Pod yang tidak meminta sandbox di node yang telah mengaktifkan GKE Sandbox dengan menggunakan pemilih dan toleransi node, yang berguna untuk workload tepercaya seperti alat pemantauan yang ingin Anda jalankan di setiap node.

Rekomendasi keamanan tambahan

Saat menggunakan GKE Sandbox, sebaiknya ikuti juga rekomendasi berikut:

• Tentukan batas resource pada semua container yang berjalan di sandbox. Tindakan ini melindungi GKE Sandbox dari risiko aplikasi rusak atau berbahaya yang menghabiskan node resource dan berdampak negatif pada aplikasi lain atau proses sistem yang berjalan di node tersebut.

• Jika Anda menggunakan Workload Identity Federation for GKE, blokir akses metadata cluster menggunakan Kebijakan Jaringan untuk memblokir akses ke 169.254.169.254. Tindakan ini melindungi GKE Sandbox dari risiko aplikasi berbahaya yang mengakses informasi ke data yang berpotensi bersifat pribadi seperti project ID, nama node, dan zona. Workload Identity Federation for GKE selalu diaktifkan di cluster Autopilot GKE.

Batasan

GKE Sandbox berfungsi baik dengan banyak aplikasi, tetapi tidak semuanya. Bagian ini memberikan informasi selengkapnya tentang keterbatasan GKE Sandbox saat ini.

GPU di GKE Sandbox

Anda dapat menjalankan workload GPU di sandbox menggunakan gVisor. gVisor tidak memitigasi semua kerentanan driver NVIDIA, tetapi tetap memberikan perlindungan terhadap kerentanan kernel Linux. Jangan gunakan GPU berbagi waktu di Pod yang di-sandbox, karena GPU tidak terisolasi sepenuhnya di antara Pod. Untuk mengetahui informasi selengkapnya tentang cara gVisor melindungi beban kerja GPU, lihat Panduan Dukungan GPU.

Batasan berikut berlaku untuk workload GPU di GKE Sandbox:

• MicroVM tidak mendukung GPU.
• Untuk gVisor, batasan berikut berlaku:
  • Hanya workload CUDA yang didukung.
  • Hanya sebagian model GPU yang tersedia yang didukung. Untuk mengetahui informasi selengkapnya, lihat Dukungan model GPU.
  • Hanya versi driver NVIDIA latest dan default yang didukung untuk setiap versi GKE. Versi driver lain mungkin tidak berfungsi.
  • Tidak semua fitur GPU, seperti RDMA atau IMEX, didukung. Bergantung pada kebutuhan pelanggan, gVisor mungkin mendukung fitur tertentu berdasarkan kasus per kasus. Untuk meminta dukungan terkait fitur tertentu, buka kasus dukungan atau buka permintaan fitur gVisor.

Dukungan model GPU

Tabel berikut menjelaskan dukungan untuk berbagai model GPU di GKE Sandbox:

TPU di GKE Sandbox

Pada GKE versi 1.31.3-gke.1111001 dan yang lebih baru, Anda dapat menjalankan beban kerja TPU di sandbox menggunakan gVisor. gVisor tidak mengurangi semua kerentanan driver TPU, tetapi tetap memberikan perlindungan terhadap kerentanan kernel Linux. Untuk mengetahui informasi selengkapnya tentang cara project gVisor melindungi workload TPU, lihat Panduan Dukungan TPU.

Batasan berikut berlaku untuk workload TPU di GKE Sandbox:

• MicroVM tidak mendukung TPU.

• gVisor mendukung versi TPU berikut:

  • V4pod
  • V4lite
  • V5litepod
  • V5pod
  • V6e

Konfigurasi node

Batasan berikut berlaku untuk node yang menggunakan GKE Sandbox:

• gVisor dan microVM hanya mendukung node Linux. Node Windows Server tidak didukung.
• gVisor hanya mendukung image node Container-Optimized OS. MicroVM mendukung image node Container-Optimized OS dan Ubuntu.
• MicroVM memerlukan virtualisasi bertingkat yang diaktifkan di node. Semua persyaratan dan batasan virtualisasi bertingkat berlaku.
• Di cluster Standard, Anda tidak dapat mengaktifkan GKE Sandbox di node pool default. Cluster harus selalu memiliki setidaknya satu node pool yang tidak menggunakan GKE Sandbox. Node pool tersebut harus berisi setidaknya satu node, meskipun semua workload Anda di-sandbox. Batasan ini ada untuk memisahkan layanan sistem dari workload yang tidak tepercaya.

Akses ke metadata cluster

Jika node Anda menggunakan jenis sandbox gVisor, Pod di node tidak dapat mengakses metadata cluster di tingkat OS node. Pod juga tidak dapat mengakses layanan Cloud de Confiance kecuali jika Anda menggunakan Workload Identity Federation for GKE untuk memberikan peran ke identitas Pod.

Batasan ini tidak berlaku untuk jenis sandbox microVM. Untuk mencegah akses metadata cluster dari Pod di microVM, gunakan NetworkPolicy yang menolak traffic keluar ke 169.254.169.252/32 di port 988 atau, di cluster yang menggunakan GKE Dataplane V2, ke 169.254.169.254/32 di port 80.

SMT mungkin dinonaktifkan

Setelan multithreading simultan (SMT) (juga dikenal sebagai Hyper-Threading di CPU Intel) digunakan untuk mengurangi kerentanan side-channel yang memanfaatkan thread yang berbagi status inti, seperti kerentanan Sampling Data Mikroarsitektur (MDS).

Untuk mengurangi serangan side-channel, gVisor menggunakan Penjadwalan Inti Linux. Setelan SMT tidak berubah dari nilai default. Penjadwalan Inti Linux hanya berlaku untuk Pod yang berjalan di sandbox gVisor.

Setelan SMT atau Hyper-Threading default untuk jenis mesin bergantung pada seberapa rentan mesin tersebut terhadap MDS, yaitu sebagai berikut:

• Pod Autopilot yang menggunakan ComputeClass Scale-Out: SMT selalu dinonaktifkan.
• Jenis mesin yang menggunakan pemroses Intel: Hyper-Threading dinonaktifkan secara default.
• Jenis mesin yang menggunakan pemroses AMD: SMT diaktifkan secara default.
• Jenis mesin yang hanya menggunakan satu thread per inti, seperti pemroses Arm: tidak ada dukungan SMT. Semua vCPU yang diminta terlihat.

Mengaktifkan SMT

Di node pool GKE Standard, Anda dapat mengaktifkan SMT jika dinonaktifkan secara default untuk jenis mesin yang dipilih. Anda ditagih untuk setiap vCPU, terlepas dari apakah Anda mengaktifkan SMT atau menonaktifkannya. Untuk mengetahui informasi selengkapnya, lihat harga saat Anda mengubah jumlah thread per core. Untuk mengubah setelan SMT, lakukan salah satu hal berikut:

• Tetapkan flag --threads-per-core saat Anda membuat node pool GKE Sandbox yang menggunakan gVisor:

  gcloud container node-pools create smt-enabled \
      --cluster=CLUSTER_NAME \
      --location=LOCATION \
      --machine-type=MACHINE_TYPE \
      --threads-per-core=2 \
      --sandbox=type=gvisor
  

  • CLUSTER_NAME: nama cluster yang ada tempat Anda ingin membuat node pool baru.
  • LOCATION: region atau zona Compute Engine cluster.
  • MACHINE_TYPE: jenis mesin.

• Gunakan DaemonSet untuk mengaktifkan SMT pada node pool yang ada:

  1. Tambahkan label node cloud.google.com/gke-smt-disabled=false ke node pool yang ada yang menggunakan gVisor:

     gcloud container node-pools update NODE_POOL_NAME \
         --cluster=CLUSTER_NAME \
         --location=LOCATION \
         --node-labels=cloud.google.com/gke-smt-disabled=false
     

     Ganti kode berikut:

     • NODE_POOL_NAME: nama node pool yang ada.
     • CLUSTER_NAME: nama cluster yang ada tempat Anda ingin membuat node pool baru.
     • LOCATION: region atau zona Compute Engine cluster.

  2. Deploy DaemonSet. DaemonSet hanya berjalan di node yang memiliki label cloud.google.com/gke-smt-disabled=false.

     kubectl create -f \
         https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yaml
     

  3. Pastikan Pod DaemonSet berada dalam status berjalan.

     kubectl get pods --selector=name=enable-smt -n kube-system
     

     Outputnya mirip dengan hal berikut ini:

     NAME               READY     STATUS    RESTARTS   AGE
     enable-smt-2xnnc   1/1       Running   0          6m
     

  4. Pastikan SMT has been enabled muncul dalam log Pod:

     kubectl logs enable-smt-2xnnc enable-smt -n kube-system
     

Kemampuan

Berlaku untuk cluster Standard

Secara default, container dicegah untuk membuka socket mentah, untuk mengurangi potensi serangan berbahaya. Alat tertentu terkait jaringan seperti ping dan tcpdump membuat socket mentah sebagai bagian dari operasi intinya. Untuk mengaktifkan socket mentah, Anda harus secara eksplisit menambahkan kemampuan NET_RAW ke konteks keamanan container:

spec:
  containers:
  - name: my-container
    securityContext:
      capabilities:
        add: ["NET_RAW"]

Jika Anda menggunakan GKE Autopilot, Cloud de Confiance mencegah Anda menambahkan izin NET_RAW ke container karena implikasi keamanan dari kemampuan ini.

Dependensi eksternal

Berlaku untuk cluster Autopilot dan Standard

Kode tidak tepercaya yang berjalan di dalam sandbox mungkin diizinkan untuk menjangkau layanan eksternal seperti server database, API, container lain, dan driver CSI. Layanan ini berjalan di luar batas sandbox dan harus dilindungi satu per satu. Penyerang dapat mencoba mengeksploitasi kerentanan dalam layanan ini untuk keluar dari sandbox. Anda harus mempertimbangkan risiko dan dampak layanan ini jika dapat dijangkau oleh kode yang berjalan di dalam sandbox, dan menerapkan langkah yang diperlukan untuk mengamankannya.

Hal ini mencakup penerapan sistem file untuk volume container seperti driver ext4 dan CSI. Driver CSI berjalan di luar isolasi sandbox dan mungkin memiliki akses dengan hak istimewa ke host dan layanan. Eksploitasi di driver ini dapat memengaruhi kernel host dan menyusupi seluruh node. Sebaiknya jalankan driver CSI di dalam container dengan jumlah izin minimal yang diperlukan, untuk mengurangi eksposur jika terjadi eksploitasi. GKE Sandbox mendukung penggunaan driver CSI Persistent Disk Compute Engine.

Fitur yang Tidak Kompatibel

Batasan fitur berikut berlaku untuk GKE Sandbox:

• Batasan berikut berlaku untuk sandbox gVisor dan microVM:

  • Cloud Service Mesh tidak didukung untuk sandbox di cluster Autopilot.
  • Modul keamanan kernel Linux seperti seccomp, AppArmor, SELinux, flag No New Privileges, propagasi pemasangan dua arah, dan procMount konteks keamanan Pod tidak didukung di Pod yang di-sandbox.
  • Metrik penggunaan memori di tingkat penampung tidak didukung. Namun, penggunaan memori Pod didukung.

• Batasan berikut hanya berlaku untuk sandbox gVisor:

  • Container yang menggunakan mode dengan hak istimewa tidak didukung.
  • Volume blok mentah tidak didukung.
  • Penerusan port, seperti dengan menggunakan kubectl port-forward, tidak didukung.
  • Penyimpanan hostpath tidak didukung.
  • Menetapkan parameter kernel sysctl tidak didukung.
  • Batas CPU dan memori hanya berlaku untuk Pod yang memiliki class QoS Guaranteed atau Burstable, dan hanya jika batas CPU dan memori ditentukan untuk semua container di Pod.

• Batasan berikut hanya berlaku untuk sandbox microVM:

  • Pod yang menggunakan setelan hostNetwork: true tidak didukung. Pod yang berjalan di sandbox microVM dan menggunakan setelan hostNetwork: true tidak dapat mengakses resource apa pun di luar Pod.
  • Alat diagnostik apa pun yang mengandalkan pelacakan tingkat soket hanya dapat mengakses antarmuka jaringan yang terpasang ke microVM.

Langkah berikutnya

• Mengonfigurasi GKE Sandbox.
• Baca Ringkasan keamanan.
• Pelajari siklus proses Pod.