GKE Sandbox

Halaman ini menjelaskan cara GKE Sandbox melindungi kernel host di node Anda saat container di Pod menjalankan kode yang tidak dikenal atau tidak tepercaya. Misalnya, cluster multi-tenant seperti penyedia software-as-a-service (SaaS) sering menjalankan kode tidak dikenal yang dikirimkan oleh penggunanya. GKE Sandbox juga merupakan pengukuran defense-in-depth yang berguna untuk menjalankan container bernilai tinggi.

Halaman ini ditujukan bagi spesialis Keamanan untuk mempelajari manfaat GKE Sandbox. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.

Sebelum membaca halaman ini, pastikan Anda sudah memahami dokumentasi gVisor resmi, project open source yang digunakan GKE Sandbox.

Untuk mengetahui petunjuk cara mengaktifkan dan menggunakan GKE Sandbox, lihat Mengonfigurasi GKE Sandbox.

Ringkasan

GKE Sandbox memberikan lapisan keamanan tambahan untuk mencegah kode yang tidak tepercaya memengaruhi kernel host di node cluster Anda. Sebelum membahas cara kerja GKE Sandbox, sebaiknya pahami sifat potensi risiko yang dapat dimitigasi.

Runtime container seperti containerd memberikan beberapa 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.

Potensi ancaman

Cluster multi-tenant dan cluster yang container-nya menjalankan workload yang tidak tepercaya lebih rentan terhadap kerentanan keamanan daripada cluster lain. Contohnya meliputi penyedia SaaS, penyedia hosting web, atau organisasi lain yang mengizinkan penggunanya untuk mengupload dan menjalankan kode. Cacat pada runtime container atau kernel host memungkinkan proses berjalan di container untuk "kabur" dari container dan memengaruhi kernel node, yang berpotensi menghilangkan node.

Ada juga potensi tenant yang berbahaya mendapatkan akses ke dan memindahkan data tenant lain di memori atau disk, dengan mengeksploitasi kerusakan tersebut.

Terakhir, workload yang tidak tepercaya berpotensi mengakses layanan Google Cloud atau metadata cluster lainnya.

Cara GKE Sandbox mengurangi ancaman ini

gVisor adalah penerapan ulang ruang pengguna dari API kernel Linux yang tidak memerlukan hak istimewa yang ditingkatkan. Bersama dengan runtime container seperti containerd , kernel ruang pengguna menerapkan ulang sebagian besar panggilan sistem dan melayaninya atas nama kernel host. Akses langsung ke kernel host dibatasi. Lihat panduan arsitektur gVisor untuk mengetahui informasi mendetail tentang cara kerjanya. Dari sudut pandang container, gVisor hampir transparan, dan tidak memerlukan perubahan apa pun pada aplikasi dalam container.

Saat Anda meminta GKE Sandbox di Pod di cluster Autopilot, GKE menjalankan Pod tersebut dalam sandbox. Di GKE Standard, jika Anda mengaktifkan GKE Sandbox di node, semua Pod yang berjalan di node tersebut berjalan di sandbox.

Setiap sandbox menggunakan kernel ruang penggunanya sendiri. Dengan mempertimbangkan hal ini, Anda dapat memutuskan cara mengelompokkan container ke dalam Pod, berdasarkan tingkat isolasi yang diperlukan dan karakteristik aplikasi.

GKE Sandbox sangat cocok untuk jenis aplikasi berikut. Lihat Keterbatasan untuk mengetahui informasi selengkapnya guna membantu Anda memutuskan aplikasi mana yang di-sandbox.

  • Aplikasi pihak ketiga atau tidak tepercaya yang menggunakan runtime seperti Rust, Java, Python, PHP, Node.js, atau Golang
  • Front-end, cache, atau proxy server web
  • Aplikasi yang memproses media atau data eksternal menggunakan CPU
  • Workload machine learning yang menggunakan CPU
  • Aplikasi yang menggunakan CPU atau memori secara intensif
  • Workload intensif GPU

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 untuk 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 ID project, 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

Di GKE versi 1.29.2-gke.1108000 dan yang lebih baru, GKE Sandbox mendukung penggunaan GPU NVIDIA.

GKE Sandbox tidak memitigasi semua kerentanan driver NVIDIA, tetapi tetap mempertahankan perlindungan terhadap kerentanan kernel Linux. Untuk mengetahui detail tentang cara project gVisor melindungi workload GPU, lihat Panduan Dukungan GPU

Batasan berikut berlaku untuk workload GPU dalam GKE Sandbox:

  • Hanya versi driver NVIDIA latest pada versi GKE tertentu yang didukung. Cluster Autopilot otomatis menginstal versi driver NVIDIA yang mendukung GKE Sandbox.
  • Hanya workload CUDA yang didukung.
  • Model GPU berikut didukung: nvidia-tesla-t4, nvidia-tesla-a100, nvidia-a100-80gb, nvidia-l4, dan nvidia-h100-80gb.

Anda dapat menggunakan GKE Sandbox dengan workload GPU tanpa biaya tambahan.

Konfigurasi node pool

Berlaku untuk cluster Standard

  • Anda tidak dapat menggunakan GKE Sandbox di node pool Windows Server.
  • Anda tidak dapat mengaktifkan GKE Sandbox di node pool default untuk memisahkan layanan sistem yang berjalan di node pool default dari workload tidak tepercaya menggunakan GKE Sandbox.
  • Saat menggunakan GKE Sandbox, cluster Anda harus memiliki setidaknya dua node pool. Anda harus selalu memiliki setidaknya satu node pool di mana GKE Sandbox dinonaktifkan. Node pool ini harus berisi setidaknya satu node, meskipun semua workload Anda di-sandbox.
  • GKE versi yang lebih lama dari 1.24.2-gke.300 tidak mendukung jenis mesin e2-micro, e2-small, dan e2-medium. GKE versi 1.24.2-gke.300 dan yang lebih baru mendukung jenis mesin ini.
  • Node harus menggunakan Container-Optimized OS dengan image node containerd (cos_containerd).

Akses ke metadata cluster

Berlaku untuk cluster Autopilot dan Standard

  • Node yang menjalankan Pod yang di-sandbox dicegah untuk mengakses metadata cluster di level sistem operasi di node.
  • Di GKE Standard, Anda dapat menjalankan Pod reguler di node yang telah mengaktifkan GKE Sandbox. Namun, secara default Pod reguler tersebut tidak dapat mengakses layanan Google Cloud atau metadata cluster.
  • Gunakan Workload Identity Federation for GKE untuk memberi Pod akses ke layanan Google Cloud.

SMT mungkin dinonaktifkan

Berlaku untuk cluster Autopilot dan Standard

Setelan multithreading simultan (SMT) digunakan untuk mengurangi kerentanan side-channel yang memanfaatkan status thread dengan inti bersama, seperti kerentanan Sampling Data Mikroarsitektur (MDS).

Di GKE versi 1.25.5-gke.2500 atau yang lebih baru dan 1.26.0-gke.2500 atau yang lebih baru, gVisor dikonfigurasi untuk menggunakan Penjadwalan Inti Linux untuk mengurangi serangan side-channel. Setelan SMT tidak berubah dari default. Penjadwalan Inti hanya digunakan untuk workload yang berjalan dengan gVisor.

Mulai GKE versi 1.24.2-gke.300, SMT dikonfigurasi menurut jenis mesin berdasarkan seberapa rentan mesin tersebut terhadap MDS, yaitu sebagai berikut:

  • Pod Autopilot yang berjalan di class komputasi Scale-Out: SMT dinonaktifkan.

  • Jenis mesin dengan pemroses Intel: SMT dinonaktifkan secara default.

  • Jenis mesin tanpa pemroses Intel: SMT diaktifkan secara default.

  • Jenis mesin dengan hanya satu thread per inti: tidak ada dukungan SMT. Semua vCPU yang diminta terlihat.

Sebelum versi 1.24.2-gke.300, SMT dinonaktifkan di semua jenis mesin.

Mengaktifkan SMT

Berlaku untuk cluster Standard

Di cluster GKE Standard, Anda dapat mengaktifkan SMT jika dinonaktifkan pada jenis mesin yang dipilih. Anda ditagih untuk setiap vCPU, terlepas dari apakah Anda mengaktifkan SMT atau menonaktifkannya. Untuk mengetahui informasi harga, lihat harga Compute Engine.

GKE versi 1.24.2-gke.300 dan yang lebih baru

Tetapkan flag --threads-per-core saat membuat node pool GKE Sandbox:

gcloud container node-pools create smt-enabled \
  --cluster=CLUSTER_NAME \
  --machine-type=MACHINE_TYPE \
  --threads-per-core=2 \
  --sandbox type=gvisor
  • CLUSTER_NAME: nama cluster yang ada.
  • MACHINE_TYPE: jenis mesin.

Untuk mengetahui informasi selengkapnya tentang --threads-per-core, lihat Menetapkan jumlah thread per inti.

GKE versi sebelum 1.24.2-gke.300

  1. Buat node pool baru di cluster Anda dengan label node cloud.google.com/gke-smt-disabled=false:

    gcloud container node-pools create smt-enabled \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --node-labels=cloud.google.com/gke-smt-disabled=false \
    --image-type=cos_containerd \
    --sandbox type=gvisor

  2. Deploy DaemonSet ke node pool. DaemonSet hanya akan berjalan di node dengan 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 yang 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 fungsi 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, Google Cloud 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

Anda tidak dapat menggunakan GKE Sandbox dengan fitur Kubernetes berikut:

Karakteristik workload

Berlaku untuk cluster Autopilot dan Standard

Menerapkan lapisan tidak langsung tambahan untuk mengakses kernel node menurunkan performa. GKE Sandbox memberikan manfaat yang paling nyata di cluster multi-tenant besar yang mementingkan isolasi. Perhatikan panduan berikut saat menguji workload Anda dengan GKE Sandbox.

Panggilan sistem

Berlaku untuk cluster Autopilot dan Standard

Workload yang menghasilkan panggilan sistem dengan overhead rendah dalam volume besar, seperti sejumlah operasi I/O kecil, mungkin memerlukan lebih banyak resource sistem saat dijalankan di sandbox, sehingga Anda mungkin perlu menggunakan node yang lebih canggih atau menambahkan node tambahan ke cluster Anda.

Akses langsung ke hardware atau virtualisasi

Berlaku untuk cluster Autopilot dan Standard

Jika workload Anda memerlukan salah satu hal berikut, GKE Sandbox mungkin tidak cocok karena mencegah akses langsung ke kernel host di node:

  • Akses langsung ke hardware node
  • Fitur virtualisasi level kernel
  • Container dengan hak istimewa

Langkah berikutnya