Catatan perev. : Artikel asli ditulis oleh seorang insinyur dari Swedia - Christian Abdelmassih, yang gemar arsitektur tingkat perusahaan, keamanan TI, dan komputasi awan. Baru-baru ini, ia menerima gelar master di bidang Ilmu Komputer dan sedang terburu-buru untuk berbagi karyanya - tesis master, atau lebih tepatnya, bagian dari itu, dikhususkan untuk masalah mengisolasi aplikasi kemas [dan diluncurkan dalam Kubernet]. Sebagai "klien" untuk siapa penelitian ini dipersiapkan, bertindak tidak kurang dari polisi di tanah airnya.
Orkestrasi kontainer dan komputasi awan-asli telah menjadi sangat populer dalam beberapa tahun terakhir. Adaptasi mereka telah mencapai tingkat yang bahkan perusahaan keuangan, bank, dan sektor publik menunjukkan minat pada mereka. Dibandingkan dengan perusahaan lain, mereka dibedakan oleh persyaratan luas di bidang keamanan informasi dan TI.
Salah satu aspek penting adalah bagaimana wadah dapat digunakan dalam lingkungan produksi dan pada saat yang sama, pemisahan sistem antara aplikasi dapat dipertahankan. Karena organisasi tersebut menggunakan lingkungan cloud pribadi berdasarkan virtualisasi di atas bare metal, kehilangan isolasi seperti itu ketika bermigrasi ke lingkungan dengan wadah yang diatur tidak dapat diterima. Dengan batasan-batasan ini, disertasi saya ditulis, dan Polisi Swedia dianggap sebagai klien target.
Masalah spesifik dari penelitian yang dipertimbangkan dalam tesis adalah:
Bagaimana demarkasi aplikasi didukung di Docker dan Kubernetes dibandingkan dengan mesin virtual yang berjalan di atas ESXi hypervisor yang berjalan pada bare metal?
Masalah ini membutuhkan studi yang cermat. Untuk memulai dengan sesuatu, lihat common denominator - application.
Aplikasi web membingungkan
Kerentanan dalam aplikasi web - kebun binatang vektor serangan nyata. Risiko paling signifikan disajikan dalam OWASP Top 10 (
2013 ,
2017 ). Sumber daya ini membantu mendidik pengembang dalam mengurangi risiko tipikal. Namun, bahkan jika pengembang menulis kode tanpa cacat, aplikasi masih bisa rentan - misalnya, melalui dependensi paket.
David Gilbertson menulis
kisah hebat tentang bagaimana Anda dapat menyuntikkan kode melalui paket jahat yang didistribusikan, misalnya, sebagai bagian dari NPM untuk aplikasi berbasis Node.js. Untuk mendeteksi kerentanan, Anda dapat menggunakan pemindai ketergantungan, tetapi mereka hanya
mengurangi risiko, tetapi tidak sepenuhnya menghilangkannya.
Bahkan jika Anda membuat aplikasi tanpa ketergantungan pihak ketiga, masih tidak realistis untuk percaya bahwa aplikasi tersebut tidak akan pernah menjadi rentan.
Karena risiko ini, kami tidak dapat mengatakan bahwa aplikasi web aman.Sebaliknya, tetap berpegang pada strategi
pertahanan dalam (DID). Mari kita lihat tingkat selanjutnya: wadah dan mesin virtual.
Kontainer versus mesin virtual - kisah isolasi
Wadah adalah lingkungan ruang-pengguna yang terisolasi yang sering diimplementasikan menggunakan kemampuan kernel. Misalnya,
Docker menggunakan ruang nama Linux, grup, dan kemampuan untuk ini. Dalam hal ini, isolasi wadah Docker
sangat berbeda dari mesin virtual yang diluncurkan oleh hypervisor tipe 1
(mis., Bekerja secara langsung pada perangkat keras; hypervisor bare-metal) .
Diferensiasi untuk mesin virtual semacam itu dapat diimplementasikan pada level rendah seperti pada perangkat keras nyata, misalnya, melalui
Intel VT . Kontainer Docker, pada gilirannya, bergantung pada kernel Linux untuk demarkasi. Perbedaan ini sangat penting untuk dipertimbangkan ketika datang ke
serangan layer-bawah .
Jika seorang penyerang dapat mengeksekusi kode dalam mesin atau wadah virtual, ia berpotensi dapat mencapai tingkat yang lebih rendah dengan melakukan
serangan melarikan diri .
tergantung pada apakah wadah atau mesin virtual digunakan pada perangkat keras, diferensiasi diimplementasikan pada berbagai tingkat infrastruktur.Kemungkinan serangan tersebut terbukti untuk hypervisor
VMware ESXi selama kontes hacker Pwn2Own 2017, serta GeekPwn2018. Hasilnya adalah sepasang
CVE (
CVE-2017–4902 ,
CVE-2018–6981 ) yang dapat digunakan dalam serangan lapisan-bawah untuk
keluar dari mesin virtual ( virtual machine escape ) . Mesin virtual pada server besi tidak menjamin keamanan absolut, meskipun mereka menggunakan teknologi untuk membedakan tingkat besi.
Di sisi lain, jika kita melihat vektor serangan pada hypervisor bare-metal versus kernel Linux, jelas bahwa yang terakhir memiliki permukaan serangan yang lebih besar - karena ukuran [Linux kernel] dan berbagai kemampuan. Permukaan serangan yang lebih besar menyiratkan lebih banyak vektor serangan potensial untuk lingkungan cloud menggunakan isolasi wadah. Ini dimanifestasikan dalam perhatian yang semakin besar terhadap
serangan pelarian kontainer , yang dimungkinkan berkat eksploitasi kernel (misalnya,
CVE-2016–5195 [yaitu, Kotor SAPI - kira-kira. Terjemahan.] ,
CVE-2017–1000405 )
Modul seperti
SELinux atau
AppArmor dapat digunakan untuk meningkatkan insulasi
di dalam wadah. Sayangnya, mekanisme keamanan seperti itu di kernel tidak mencegah serangan melarikan diri pada kernel itu sendiri. Mereka hanya akan membatasi kemungkinan tindakan penyerang jika melampaui batas
tidak mungkin . Jika kita ingin berurusan dengan pintu keluar di luar wadah, diperlukan mekanisme isolasi di
luar wadah atau bahkan inti. Misalnya, kotak pasir
(kotak pasir) !
gVisor adalah kotak pasir untuk
runtime wadah, kode yang dibuka oleh Google dan yang menambahkan kernel tambahan antara wadah dan kernel OS. Jenis kotak pasir ini dapat memperbaiki situasi dengan serangan kontainer yang tidak terbatas yang terjadi
di tingkat kernel . Namun, eksploitasi inti hanyalah salah satu alat penyerang.
Untuk melihat bagaimana serangan lain dapat menyebabkan hasil yang serupa, Anda perlu melihat gambaran yang lebih umum tentang bagaimana wadah digunakan di era cloud asli.
Efek orkestrasi wadah pada isolasi
Untuk mengelola kontainer yang berjalan di lingkungan dengan banyak node, mereka memperkenalkan orkestrasi, di mana Kubernetes memberikan peran utama. Ternyata, bug orkestra juga dapat mempengaruhi isolasi wadah.
Tim Allclair
membuat presentasi yang luar biasa di KubeCon 2018, di mana ia mencatat beberapa permukaan serangan. Dalam laporannya, ia
menyebutkan contoh (
CVE-2017-1002101 ), bagaimana bug orkestrasi dapat mempengaruhi isolasi - dalam hal ini, melalui kemampuan untuk memasang ruang disk di luar pod. Kerentanan jenis ini sangat bermasalah, karena dapat melewati kotak pasir di mana wadah dibungkus.
Dengan memperkenalkan Kubernetes, kami telah memperluas permukaan serangan. Ini mencakup sistem yang di-host pada master Kubernetes. Salah satunya adalah server API Kubernetes, di mana mereka baru-baru ini menemukan kerentanan yang dapat memungkinkan hak istimewa yang
berlebihan (
CVE-2018–1002105 ). Karena permukaan serangan master Kubernetes berada di luar cakupan disertasi saya, kerentanan khusus ini tidak diperhitungkan.
Mengapa serangan melarikan diri begitu penting? Wadah memberikan kemampuan untuk menjalankan banyak aplikasi yang dihosting bersama dalam OS yang sama. Jadi ada risiko yang terkait dengan isolasi aplikasi. Jika aplikasi bisnis-kritis dan aplikasi rentan lainnya berjalan pada host yang sama, penyerang bisa mendapatkan akses ke aplikasi kritis melalui serangan terhadap aplikasi yang rentan.
Bergantung pada jenis data apa organisasi ini bekerja, kebocoran mereka dapat membahayakan tidak hanya organisasi itu sendiri, tetapi juga individu dan seluruh negara. Seperti yang Anda ingat, kita berbicara tentang sektor publik, keuangan, bank ... - kebocoran dapat secara serius mempengaruhi kehidupan masyarakat.
Jadi dapatkah wadah orkestrasi digunakan di lingkungan seperti itu? Sebelum memulai refleksi lebih lanjut, penilaian risiko harus dilakukan.
Risiko apa yang bisa diterima?
Sebelum memperkenalkan langkah-langkah keamanan, penting untuk memikirkan informasi apa yang sebenarnya dilindungi oleh organisasi. Keputusan apakah langkah lebih lanjut diperlukan untuk mencegah kemungkinan serangan melarikan diri pada kontainer tergantung pada data yang organisasi itu kerjakan dan layanan yang diberikannya.
Dalam jangka panjang, ini berarti bahwa untuk mencapai kemungkinan keluar dari wadah pada host yang
dikonfigurasi dengan benar yang dilindungi oleh kotak pasir untuk wadah, penyerang harus:
- mengeksekusi kode dalam wadah, misalnya, melalui injeksi kode atau menggunakan kerentanan dalam kode aplikasi;
- Manfaatkan kerentanan lain, zero-day, atau patch belum diterapkan untuk keluar dari wadah meskipun ada kotak pasir .
Seperti yang Anda duga, organisasi yang tidak mempertimbangkan skenario seperti itu dapat diterima harus bekerja dengan data atau menawarkan layanan yang sangat menuntut
kerahasiaan ,
integritas dan / atau
aksesibilitas .
Karena disertasi dikhususkan untuk klien seperti itu, hilangnya isolasi sistem dengan pergi ke luar wadah tidak diperbolehkan, karena konsekuensinya terlalu signifikan. Langkah apa yang dapat diambil untuk meningkatkan isolasi? Untuk naik satu tingkat di tangga isolasi, Anda juga harus melihat kotak pasir di mana kernel OS dibungkus, yaitu mesin virtual!
Teknologi virtualisasi yang menggunakan hypervisor yang di-host akan meningkatkan situasi, tetapi kami ingin membatasi permukaan serangan
lebih banyak lagi . Karena itu, mari kita periksa hypervisor yang dipasang pada besi dan lihat apa yang akan membawa kita.
Hypervisor pada besi
Sebuah
studi oleh Badan Riset Pertahanan Swedia Swedia meneliti risiko virtualisasi dalam kaitannya dengan Angkatan Bersenjata Swedia. Kesimpulannya berbicara tentang manfaat teknologi ini bagi militer, bahkan dengan persyaratan keamanan yang ketat dan risiko yang dibawa oleh virtualisasi.
Dalam hal ini, kita dapat mengatakan bahwa virtualisasi digunakan (sampai batas tertentu) di industri pertahanan, karena membawa
risiko yang dapat diterima . Karena agensi dan perusahaan dalam industri pertahanan adalah salah satu pelanggan yang paling banyak menuntut keamanan TI, kami juga dapat berargumen bahwa risiko yang dapat diterima bagi mereka berarti dapat diterima oleh klien yang dipertimbangkan dalam disertasi. Dan semua ini - terlepas dari potensi keluar di luar mesin virtual, dibahas di atas.
Jika kami memutuskan untuk menggunakan kotak pasir jenis ini untuk wadah, ada beberapa hal yang perlu dipertimbangkan dalam konteks spesifikasi asli cloud.
Node kotak pasir untuk mesin virtual
Idenya adalah bahwa node dari cluster Kubernetes adalah mesin virtual yang menggunakan virtualisasi perangkat keras. Karena mesin virtual akan memainkan peran kotak pasir untuk wadah yang berjalan di pod, setiap node dapat dianggap sebagai lingkungan yang dilindungi kotak pasir.
Catatan penting tentang kotak pasir ini dalam konteks kotak pasir yang telah disebutkan: pendekatan ini memungkinkan Anda untuk meletakkan banyak kontainer dalam satu kotak pasir. Fleksibilitas ini memungkinkan Anda untuk mengurangi overhead jika dibandingkan dengan case ketika setiap kontainer memiliki kotak pasir sendiri. Karena setiap kotak pasir membawa OS sendiri, kami ingin mengurangi jumlah mereka sambil mempertahankan isolasi.
Mesin virtual yang diinstal pada perangkat keras - node cluster - bertindak sebagai kotak pasir untuk wadah. Kontainer yang berjalan di VM yang berbeda dibatasi dengan tingkat risiko yang dapat diterima. Namun, ini tidak berlaku untuk kontainer yang berjalan di VM yang sama.Namun, karena Kubernetes mampu mengubah penempatan polong karena berbagai alasan, yang dapat
merusak gagasan kotak pasir yang digunakan , maka akan perlu untuk menambahkan pembatasan pada mekanisme penempatan polong bersama. Anda dapat mencapai yang diinginkan dengan banyak cara.
Pada saat penulisan, Kubernetes (
v1.13 ) mendukung tiga metode utama untuk mengendalikan perencanaan dan / atau peluncuran pod:
Metode mana yang digunakan tergantung pada aplikasi organisasi. Namun, penting untuk dicatat bahwa metode berbeda dalam kemampuan mereka untuk membuang polong setelah mereka memasuki tahap eksekusi. Sekarang hanya noda yang mampu melakukan ini - melalui tindakan
NoExecute . Jika Anda tidak memproses momen ini dengan cara apa pun dan beberapa label berubah, maka semuanya dapat mengarah ke lokasi bersama yang tidak diinginkan.
Kepatuhan dengan persyaratan lokasi bersama
Disertasi ini mengusulkan gagasan untuk menggunakan sistem klasifikasi yang menunjukkan bagaimana sensitivitas tercermin di lokasi bersama. Idenya adalah untuk menggunakan hubungan 1: 1 antara wadah dan pod dan menentukan lokasi co-pod berdasarkan klasifikasi aplikasi kontainer.
Untuk kesederhanaan dan penggunaan kembali, sistem klasifikasi 3 langkah berikut digunakan:
- Kelas O : Aplikasi tidak sensitif dan tidak memiliki persyaratan isolasi. Itu dapat ditempatkan pada node yang bukan milik kelas lain.
- Kelas PG (grup pribadi) : Suatu aplikasi, bersama dengan satu set aplikasi lain, membentuk grup pribadi yang memerlukan simpul khusus. Aplikasi hanya dapat di-host pada node kelas PG yang memiliki pengidentifikasi grup pribadi yang sesuai.
- Kelas P (pribadi) : Aplikasi memerlukan simpul pribadi dan terpisah dan hanya dapat ditempatkan pada simpul kosong kelasnya (P).
Untuk memenuhi persyaratan co-location untuk banyak aplikasi rahasia, noda dan toleransi digunakan, dengan mana setiap node diberi kelas, dan PodAffinity untuk menerapkan pembatasan tambahan untuk pod dengan aplikasi kelas P atau PG.
Contoh sederhana ini menunjukkan bagaimana noda dan toleransi dapat digunakan untuk menerapkan kontrol di lokasi bersama:
Pods 2 dan 3 berisi aplikasi dari satu grup pribadi, dan aplikasi di Pod 1 lebih sensitif dan memerlukan node khusus.Namun, kelas P dan PG akan memerlukan aturan Affinity tambahan untuk memastikan bahwa permintaan demarkasi dieksekusi ketika cluster dan aplikasi yang dihosting tumbuh. Mari kita lihat bagaimana Anda dapat menerapkan
aturan-aturan ini untuk kelas yang berbeda:
# Class P affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" namespaces: ["default"] labelSelector: matchExpressions: - key: non-existing-key operator: DoesNotExist
Aturan afinitas untuk aplikasi kelas P membutuhkan node khusus. Dalam hal ini, pod tidak akan dijadwalkan jika pod keluar tanpa kunci yang
non-existing-key . Semuanya akan berfungsi sampai satu pod memiliki kunci ini.
# Class PG affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" labelSelector: matchLabels: class-pg-group-1: foobar podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" labelSelector: matchExpressions: - key: class-pg-group-1 operator: DoesNotExist
Untuk aplikasi kelas PG, aturan Affinity akan meng-host pod yang memiliki pengidentifikasi grup
class-pg-group-1 dan pada node yang memiliki pod tanpa pengidentifikasi.
Pendekatan semacam itu akan memungkinkan kami menggunakan sistem klasifikasi untuk membatasi wadah berdasarkan persyaratan yang relevan dari aplikasi kemas.
Apa yang kita dapatkan?
Kesimpulan
Kami mempertimbangkan cara untuk mengimplementasikan kotak pasir berdasarkan pada hypervisor tipe 1 (mis., Diluncurkan pada bare metal) untuk membuat simpul di kluster Kubernetes dan menyajikan sistem klasifikasi yang mendefinisikan persyaratan untuk membatasi aplikasi kontainer. Jika kami membandingkan pendekatan ini dengan solusi lain yang dipertimbangkan, ia memiliki keunggulan dalam hal memastikan isolasi sistem.
Kesimpulan penting adalah bahwa strategi isolasi
membatasi penyebaran serangan melarikan diri ke wadah.
Dengan kata lain, meninggalkan wadah dengan sendirinya tidak dicegah, tetapi efeknya dikurangi. Jelas, seiring dengan ini muncul kesulitan tambahan yang harus diperhitungkan ketika membuat perbandingan serupa.
Untuk menggunakan metode yang ditentukan dalam lingkungan cloud dan memberikan skalabilitas, persyaratan tambahan akan dikenakan pada otomatisasi. Misalnya, untuk mengotomatisasi pembuatan mesin virtual dan penggunaannya di kluster Kubernetes. Yang paling penting adalah implementasi dan verifikasi klasifikasi aplikasi yang
tersebar luas .
Ini adalah bagian dari disertasi saya tentang
isolasi aplikasi kemas .
Untuk mencegah kemungkinan penyerang yang keluar dari wadah pada satu node untuk menyerang layanan dari node lain, perlu untuk mempertimbangkan
serangan jaringan yang diperbanyak . Untuk memperhitungkan risiko ini, disertasi saya mengusulkan
segmentasi jaringan cluster dan memperkenalkan arsitektur cloud, yang salah satunya memiliki
firewall perangkat keras .
Mereka yang ingin dapat membiasakan diri dengan dokumen lengkap - teks disertasi ada di akses publik: "
Orkestra Kontainer dalam Lingkungan yang Menuntut Keamanan di Otoritas Kepolisian Swedia ".
PS dari penerjemah
Baca juga di blog kami: