Container Service for Kubernetes：Keamanan multi-tenancy

Soft multi-tenancy

Anda dapat menggunakan resource native Kubernetes berikut untuk mengimplementasikan soft multi-tenancy: namespaces, roles, role bindings, dan network policies. Hal ini memungkinkan isolasi logis di antara penyewa. Misalnya, Anda dapat menggunakan role-based access control (RBAC) untuk mencegah penyewa mengakses atau memanipulasi resource penyewa lain. Anda juga dapat menggunakan quotas dan limit ranges untuk mengelola jumlah resource kluster yang dapat dikonsumsi oleh setiap penyewa. Selain itu, Anda dapat menggunakan network policies untuk mencegah aplikasi yang diterapkan di namespace berbeda saling berkomunikasi.

Namun, metode kontrol ini tidak dapat mencegah pods dari penyewa berbeda berbagi node yang sama. Untuk memaksa penjadwalan pod dari penyewa berbeda ke node terpisah, Anda dapat menggunakan node selectors, aturan anti-affinity, taints, dan tolerations. Node-node tersebut dikenal sebagai sole tenant nodes. Kompleksitas dan biaya sole tenant nodes meningkat secara signifikan ketika sebuah kluster digunakan bersama oleh banyak penyewa.

Jika Anda menggunakan namespaces untuk mengimplementasikan soft multi-tenancy, Anda tidak boleh memberikan daftar namespace yang difilter kepada penyewa. Hal ini karena namespace merupakan resource dengan cakupan global. Jika penyewa dapat mengakses namespace tertentu dalam kluster, penyewa tersebut dapat mengakses semua namespace dalam kluster tersebut.

Saat menggunakan soft multi-tenancy, penyewa secara default dapat melakukan kueri terhadap CoreDNS untuk semua layanan yang berjalan di kluster. Penyerang dapat mengeksploitasi kemampuan ini dengan menjalankan perintah dig SRV ..svc.cluster.local dari sebuah pod di dalam kluster. Jika Anda ingin membatasi akses ke rekaman DNS layanan yang berjalan di kluster, Anda dapat menggunakan firewall atau plugin kebijakan untuk CoreDNS. Untuk informasi selengkapnya, lihat kubernetes-metadata-multi-tenancy-policy.

• Enterprise setting

  Model soft multi-tenancy banyak digunakan oleh pengguna perusahaan Kubernetes. Jika semua penyewa dalam kluster Kubernetes berasal dari perusahaan yang sama, peran pengguna layanan dapat dikelola dengan baik. Hal ini membantu perusahaan mendapatkan kendali atas keamanan bisnis mereka. Setiap penyewa berkorespondensi dengan divisi administratif, seperti departemen atau tim.

  Dalam skenario ini, administrator kluster bertanggung jawab membuat namespace dan mengelola kebijakan. Administrator kluster dapat menggunakan model administrasi terdelegasi di mana penyewa tertentu diberikan izin pada namespace. Penyewa diberikan izin untuk melakukan operasi CRUD pada objek yang tidak terkait kebijakan, seperti Deployments, Services, pods, dan Jobs.

  Metode isolasi yang disediakan oleh Docker cocok untuk skenario ini. Anda juga dapat menggunakan metode lain, seperti Pod Security Policies (PSPs), sesuai kebutuhan bisnis Anda. Jika diperlukan isolasi yang lebih ketat, Anda mungkin ingin membatasi komunikasi antarlayanan di namespace berbeda.

• Kubernetes as a Service (KaaS)

  Anda dapat menggunakan soft multi-tenancy dalam skenario di mana Anda ingin menyediakan Kubernetes sebagai layanan. Di lingkungan KaaS, aplikasi Anda dihosting di kluster bersama. Kluster bersama tersebut berisi controller dan CustomResourceObjects (CRDs) yang menyediakan serangkaian layanan Platform as a Service (PaaS). Penyewa berinteraksi dengan server API Kubernetes dan diizinkan melakukan operasi CRUD pada objek non-kebijakan. Fitur self-service disediakan. Misalnya, penyewa diizinkan membuat dan mengelola namespace mereka sendiri. Di lingkungan jenis ini, penyewa dianggap menjalankan kode yang tidak tepercaya.

  Jika Anda ingin mengisolasi penyewa di lingkungan jenis ini, Anda mungkin perlu menggunakan kebijakan jaringan dan pod sandboxing. Untuk informasi selengkapnya, lihat Sandboxed container.

• Software as a Service (SaaS)

  Di lingkungan SaaS, setiap penyewa dikaitkan dengan instans aplikasi tertentu yang berjalan di kluster. Setiap instans berisi data dan menggunakan kebijakan kontrol akses terpisah selain Kubernetes RBAC.

  Penyewa di lingkungan SaaS tidak berinteraksi langsung dengan Kubernetes API server. Aplikasi SaaS yang berinteraksi dengan Kubernetes API server untuk membuat objek yang dibutuhkan oleh setiap penyewa.

Konfigurasi Kubernetes

Kubernetes adalah platform orkestrasi single-tenant yang digunakan untuk mengelola beban kerja terkontainerisasi. Saat menggunakan Kubernetes, lapisan kontrol dibagi bersama oleh semua penyewa dalam kluster. Anda dapat menggunakan berbagai objek Kubernetes untuk mengisolasi penyewa. Misalnya, Anda dapat menggunakan namespace dan RBAC untuk mengisolasi penyewa secara logis satu sama lain. Anda juga dapat menggunakan quotas dan limit ranges untuk mengontrol jumlah resource kluster yang dapat dikonsumsi oleh setiap penyewa. Setiap kluster menyediakan batas keamanan yang kuat. Penyerang yang berhasil mengakses host di kluster dapat mengambil semua Secrets, ConfigMaps, dan volumes yang dipasang ke host tersebut. Penyerang juga dapat mengeksploitasi kubelet, yang memungkinkan mereka memanipulasi atribut node atau bergerak lateral di dalam kluster. Resource native Kubernetes berikut dapat membantu Anda mengurangi risiko yang mungkin terjadi saat menggunakan platform orkestrasi single-tenant seperti Kubernetes. Anda juga dapat menggunakan resource Kubernetes ini untuk mengisolasi penyewa dengan metode yang dijelaskan pada bagian sebelumnya.

• Namespaces

  Namespaces merupakan dasar untuk mengimplementasikan soft multi-tenancy. Anda dapat menggunakan namespaces untuk membagi kluster menjadi partisi logis. Quotas, kebijakan jaringan, akun layanan, dan objek lain yang diperlukan untuk mengimplementasikan soft multi-tenancy harus memiliki cakupan di dalam namespace.

• AuthN&AuthZ&Admission

  Otorisasi kluster Container Service for Kubernetes (ACK) terdiri dari otorisasi Resource Access Management (RAM) dan otorisasi RBAC. Anda dapat menggunakan otorisasi RAM untuk mengatur kontrol akses tingkat kluster, termasuk operasi CRUD pada kluster. Misalnya, Anda dapat mengelola visibilitas kluster, melakukan skalabilitas kluster, dan menambahkan node ke kluster dengan memberikan izin yang diperlukan kepada Pengguna RAM. Otorisasi RBAC digunakan untuk mengontrol akses ke resource Kubernetes dalam kluster. Anda dapat menggunakan otorisasi RBAC untuk memberlakukan kontrol akses detail halus pada resource tertentu dalam namespace. ACK menyediakan templat peran pradefinisi yang berbeda untuk pengguna dalam penyewa. Anda juga dapat mengaitkan beberapa peran kluster kustom dengan pengguna dan memberikan izin kepada beberapa pengguna sekaligus. Untuk informasi selengkapnya, lihat Otorisasi.

• Network policies

  Secara default, semua pod dalam kluster Kubernetes diizinkan saling berkomunikasi. Anda dapat menggunakan network policies untuk mengubah pengaturan default ini.

• Network policies membatasi komunikasi antarpod berdasarkan label atau blok CIDR. Jika Anda memerlukan isolasi jaringan di antara penyewa dalam lingkungan multi-tenant, tambahkan aturan berikut:

  • Aturan default yang menolak komunikasi antarpod.

  • Aturan yang mengizinkan pod mengirim kueri DNS ke server DNS.

• Quotas and limit ranges

  Quotas digunakan untuk menetapkan batas pada beban kerja yang dihosting di kluster Anda. Anda dapat menggunakan quotas untuk menentukan jumlah maksimum resource CPU dan memori yang dapat dikonsumsi oleh pod. Anda juga dapat menggunakan quotas untuk menentukan jumlah resource yang dapat dialokasikan untuk kluster atau namespace. Limit ranges memungkinkan Anda menentukan nilai minimum, maksimum, dan default untuk setiap batas.

  Untuk memaksimalkan pemanfaatan resource, Anda dapat melakukan overcommit resource di kluster bersama. Jika akses ke kluster tidak dibatasi, resource di kluster dapat habis. Hal ini menurunkan performa kluster dan memengaruhi ketersediaan aplikasi Anda. Jika Anda menetapkan ambang batas permintaan pod ke nilai kecil dan pemanfaatan resource aktual melebihi kapasitas node, resource CPU atau memori node tersebut dapat habis. Ketika resource CPU atau memori habis, pod mungkin direstart atau dihapus dari node.

  Untuk mencegah masalah ini, Anda harus menambahkan quotas untuk namespace di lingkungan multi-tenant. Hal ini memaksa penyewa menentukan ambang batas permintaan dan batas saat menjadwalkan pod di kluster. Selain itu, jumlah resource yang dapat dikonsumsi oleh pod dibatasi. Hal ini mengurangi risiko ketidaktersediaan layanan.

  Di skenario KaaS, Anda dapat menggunakan quotas untuk mengalokasikan resource kluster guna memenuhi kebutuhan penyewa.

• Pod priority and preemption

  Jika Anda ingin menyediakan tingkat kualitas layanan (QoS) yang berbeda untuk pelanggan, Anda dapat menggunakan pod priority dan preemption. Misalnya, Anda dapat menentukan nilai prioritas lebih tinggi untuk pod Pelanggan A dibandingkan Pelanggan B. Jika kapasitas resource tidak mencukupi, kubelet akan menghapus pod dengan nilai prioritas lebih rendah milik Pelanggan B untuk memenuhi pod dengan nilai prioritas lebih tinggi milik Pelanggan A. Anda dapat menggunakan metode ini di lingkungan SaaS untuk menyediakan tingkat QoS lebih tinggi bagi pelanggan yang membayar biaya premium.

Metode mitigasi

Perhatian utama administrator di lingkungan multi-tenant adalah mencegah penyerang mendapatkan akses ke host yang mendasari. Anda dapat menggunakan salah satu metode berikut untuk mencegah penyerang mendapatkan akses ke host yang mendasari:

• Sandboxed-Container

  Sandboxed-Container merupakan alternatif runtime Docker. Sandboxed-Container memungkinkan Anda menjalankan aplikasi di mesin virtual ringan yang di-sandbox dengan kernel khusus. Hal ini meningkatkan isolasi resource dan memperkuat keamanan.

  Sandboxed-Container cocok untuk skenario seperti isolasi aplikasi tidak tepercaya, isolasi kesalahan, isolasi performa, dan isolasi beban di antara banyak pengguna. Sandboxed-Container menyediakan keamanan yang ditingkatkan, berdampak minimal pada performa aplikasi, serta menawarkan pengalaman pengguna yang sama seperti Docker dalam hal logging, pemantauan, dan skalabilitas elastis. Untuk informasi selengkapnya, lihat Sandboxed containers.

• Open Policy Agent (OPA) & Gatekeeper

  Open Policy Agent (OPA) adalah mesin kebijakan yang kuat. OPA mendukung keputusan kebijakan yang terpisah dan digunakan di Kubernetes. Jika persyaratan keamanan aplikasi perusahaan tidak terpenuhi setelah RBAC digunakan untuk melakukan isolasi di tingkat namespace, Anda dapat mengontrol kebijakan akses di tingkat objek dengan menggunakan OPA. Gatekeeper adalah admission controller Kubernetes yang memberlakukan kebijakan yang dibuat oleh OPA selama penerapan aplikasi. Untuk informasi selengkapnya, lihat Gatekeeper.

  Selain itu, OPA mendukung kebijakan jaringan Lapisan 7 dan kontrol akses lintas namespace berdasarkan label dan anotasi. Anda dapat menggunakan OPA untuk mengelola kebijakan jaringan Kubernetes secara efisien.

• Kyverno

  Kyverno adalah mesin kebijakan native Kubernetes. Kyverno menyediakan kebijakan yang dapat digunakan untuk memvalidasi, memodifikasi, dan menghasilkan konfigurasi untuk resource Kubernetes. Kyverno menggunakan overlay bergaya Kustomize untuk validasi dan mendukung strategic merge patch untuk mutasi. Selain itu, Kyverno dapat mengkloning resource lintas namespace berdasarkan pemicu yang fleksibel. Untuk informasi selengkapnya, lihat Kyverno.

  Anda dapat menggunakan Kyverno untuk mengisolasi namespace, memberlakukan keamanan pod dan praktik terbaik lainnya, serta menghasilkan konfigurasi default, seperti kebijakan jaringan. Untuk informasi selengkapnya, lihat Policy repository.

Hard multi-tenancy

Tren masa depan

Komunitas Kubernetes menyadari kekurangan soft multi-tenancy dan tantangan hard multi-tenancy. Multi-Tenancy Special Interest Group (SIG) berupaya mengatasi kekurangan tersebut melalui beberapa proyek:

• Proposal Virtual Cluster menjelaskan mekanisme untuk membuat instans terpisah dari layanan lapisan kontrol untuk setiap penyewa di kluster, termasuk server API, controller manager, dan penjadwal. Penyewa di kluster tersebut merujuk pada Kubernetes on Kubernetes. Untuk informasi selengkapnya, kunjungi Virtual Cluster.

• Proposal Hierarchical Namespace Controller (HNC) dalam Kubernetes Enhancement Proposal (KEP) menjelaskan cara membuat hubungan induk-anak antara namespace dengan pewarisan objek kebijakan. HNC juga memungkinkan administrator penyewa membuat subnamespace. Untuk informasi selengkapnya, lihat HNC.

• Proposal Multi-Tenancy Benchmarks menyediakan panduan tentang cara berbagi kluster setelah kluster diisolasi dan disegmentasi menggunakan namespace. Proposal ini juga menjelaskan cara menggunakan CLI kubectl-mtb untuk memastikan kepatuhan terhadap panduan tersebut. Untuk informasi selengkapnya, lihat Multi-Tenancy Benchmarks.