Amankan kontainer Windows

Berlaku untuk: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Kontainer memiliki ukuran image yang lebih kecil karena mereka mengandalkan host untuk menyediakan akses terbatas ke berbagai sumber daya. Jika kontainer tahu bahwa host akan dapat menyediakan fungsionalitas yang diperlukan untuk melakukan serangkaian tindakan tertentu, maka kontainer tidak perlu menyertakan perangkat lunak yang relevan dalam gambar dasarnya. Namun, sejauh mana berbagi sumber daya yang terjadi dapat berdampak signifikan pada performa dan keamanan kontainer. Jika terlalu banyak sumber daya yang dibagikan, aplikasi mungkin juga hanya berjalan sebagai proses pada host. Jika sumber daya dibagikan terlalu sedikit, maka kontainer menjadi tidak dapat dibedakan dari VM. Kedua konfigurasi berlaku untuk banyak skenario, tetapi kebanyakan orang yang menggunakan kontainer umumnya memilih sesuatu di tengah.

Keamanan kontainer Windows berasal dari tingkat berbagi yang terjadi dengan hostnya. Batas keamanan kontainer dibenci oleh mekanisme isolasi yang memisahkan kontainer dari host. Yang terpenting, mekanisme isolasi ini menentukan proses mana dalam kontainer yang dapat berinteraksi dengan host. Jika desain kontainer memungkinkan proses (admin) yang ditingkatkan untuk berinteraksi dengan host, maka Microsoft tidak menganggap kontainer ini memiliki batas keamanan yang kuat.

Kontainer Windows Server vs. kontainer Linux

Kontainer Windows Server dan kontainer Linux yang terisolasi proses memiliki tingkat isolasi yang sama. Untuk kedua jenis kontainer, pengembang harus mengasumsikan serangan apa pun yang dapat dilakukan melalui proses yang ditingkatkan pada host juga dapat dilakukan melalui proses yang ditingkatkan dalam kontainer. Keduanya beroperasi melalui kemampuan primitif yang ditawarkan oleh kernel host masing-masing. Gambar kontainer dibangun dengan berisi biner mode pengguna yang memanfaatkan API yang disediakan oleh kernel host. Kernel host menyediakan kemampuan isolasi dan manajemen sumber daya yang sama untuk setiap kontainer yang berjalan di ruang pengguna. Jika kernel disusupi, maka setiap kontainer yang menggunakan kernel tersebut juga akan terpengaruh.

Desain mendasar kontainer server Linux dan Windows memperdagangkan keamanan untuk fleksibilitas. Kontainer Windows Server dan Linux dibangun di atas komponen primitif yang disediakan oleh OS. Melakukannya memberikan fleksibilitas untuk berbagi sumber daya dan namespace antar kontainer, tetapi menambahkan kompleksitas tambahan yang membuka pintu untuk eksploitasi. Secara umum, kami tidak menganggap kernel sebagai penghalang keamanan yang cukup untuk beban kerja multi-penyewa yang bersifat bermusuhan.

Isolasi kernel dengan kontainer yang terisolasi oleh hypervisor

Kontainer yang terisolasi hypervisor memberikan tingkat isolasi yang lebih tinggi daripada kontainer Windows Server atau Linux yang terisolasi proses dan dianggap sebagai batas keamanan yang kuat. Kontainer yang terisolasi oleh hypervisor terdiri dari kontainer Windows Server yang dibungkus dalam VM ultralight, dan kemudian dijalankan bersamaan dengan OS host melalui hypervisor Microsoft. Hypervisor menyediakan isolasi tingkat perangkat keras yang mencakup batas keamanan yang sangat kuat antara host dan kontainer lainnya. Bahkan jika eksploitasi berhasil lolos dari kontainer Windows Server, itu akan tertahan dalam VM yang diisolasi oleh hypervisor.

Baik kontainer Windows Server maupun kontainer Linux tidak menyediakan apa yang dianggap Microsoft sebagai batas keamanan yang kokoh dan tidak boleh digunakan dalam skenario multi-penyewa yang berisiko tinggi. Kontainer harus terbatas pada VM khusus untuk mencegah proses kontainer nakal berinteraksi dengan host atau penyewa lainnya. Isolasi hypervisor memungkinkan tingkat pemisahan ini sekaligus menawarkan beberapa perolehan performa atas VM tradisional. Oleh karena itu, sangat disarankan bahwa dalam skenario multi-penyewa yang tidak bersahabat, kontainer yang terisolasi hypervisor harus menjadi kontainer pilihan.

Kriteria layanan keamanan kontainer

Microsoft berkomitmen untuk menambal semua eksploitasi dan pelarian yang melanggar batas isolasi yang ditetapkan dari jenis kontainer Windows apa pun. Namun, hanya eksploitasi yang melanggar batas keamanan yang dilayankan melalui proses Microsoft Security Response Center (MSRC). Hanya kontainer yang terisolasi oleh hypervisor yang menyediakan batas keamanan, sedangkan kontainer yang terisolasi oleh proses tidak. Satu-satunya cara untuk menghasilkan bug untuk escape kontainer yang terisolasi proses adalah jika proses non-admin dapat memperoleh akses ke host. Jika eksploitasi menggunakan proses admin untuk keluar dari kontainer, Maka Microsoft menganggapnya sebagai bug non-keamanan dan akan menambalnya sesuai proses layanan normal. Jika eksploitasi menggunakan proses non-admin untuk melakukan tindakan yang melanggar batas keamanan, Maka Microsoft akan menyelidikinya sesuai kriteria layanan keamanan yang ditetapkan .

Apa yang membuat beban kerja multi-tenant menantang?

Lingkungan multi-penyewa ada ketika banyak beban kerja beroperasi pada infrastruktur dan sumber daya bersama. Jika satu atau beberapa beban kerja yang berjalan pada infrastruktur tidak dapat dipercaya, maka lingkungan multi-penyewa dianggap bermusuhan. Kontainer Windows Server dan Linux berbagi kernel host, sehingga eksploitasi apa pun yang dilakukan pada satu kontainer dapat memengaruhi semua beban kerja lain yang berjalan pada infrastruktur bersama.

Anda dapat mengambil langkah-langkah untuk mengurangi kemungkinan eksploitasi akan terjadi, misalnya, dengan menggunakan kebijakan keamanan pod, AppArmor, dan kontrol akses berbasis peran (RBAC), tetapi mereka tidak memberikan perlindungan terjamin terhadap penyerang. Kami merekomendasikan agar Anda mengikuti praktik terbaik kami untuk isolasi kluster pada skenario multi-penyewa apa pun.

Kapan menggunakan akun pengguna ContainerAdmin dan ContainerUser

Kontainer Windows Server menawarkan dua akun pengguna default, ContainerUser dan ContainerAdministrator, masing-masing dengan tujuan spesifik mereka sendiri. Akun ContainerAdministrator memungkinkan Anda menggunakan kontainer untuk tujuan administratif: menginstal layanan dan perangkat lunak (seperti mengaktifkan IIS dalam kontainer), membuat perubahan konfigurasi, dan membuat akun baru. Tugas-tugas ini penting untuk sejumlah skenario TI yang mungkin berjalan di lingkungan penyebaran kustom lokal.

Akun ContainerUser ada untuk semua skenario lain di mana hak istimewa administrator di Windows tidak diperlukan. Misalnya, di Kubernetes jika pengguna adalah ContainerAdministrator dan hostvolumes diizinkan untuk dipasang ke dalam pod, maka pengguna dapat memasang folder .ssh dan menambahkan kunci publik. Karena ContainerUser, contoh ini tidak akan dimungkinkan. Ini adalah akun pengguna terbatas yang dirancang murni untuk aplikasi yang tidak perlu berinteraksi dengan host. Kami sangat menyarankan bahwa ketika mendeploy kontainer server Windows ke lingkungan dengan banyak penyewa, aplikasi Anda dijalankan melalui akun ContainerUser. Dalam lingkungan multi-penyewa, selalu terbaik untuk mengikuti prinsip hak akses paling minimal karena jika penyerang membahayakan beban kerja Anda, maka sumber daya bersama dan beban kerja tetangga mempunyai kemungkinan lebih kecil untuk terpengaruh. Menjalankan kontainer dengan akun ContainerUser sangat mengurangi kemungkinan lingkungan disusupi secara keseluruhan. Namun, ini masih tidak memberikan batas keamanan yang kuat, jadi ketika keamanan menjadi masalah, Anda harus menggunakan kontainer yang terisolasi hypervisor.

Untuk mengubah akun pengguna, Anda dapat menggunakan pernyataan USER di dockerfile Anda:

USER ContainerUser

Atau, Anda dapat membuat pengguna baru:

RUN net user username ‘<password>’ /ADD
USER username

Layanan Windows

Layanan Microsoft Windows, yang sebelumnya dikenal sebagai layanan NT, memungkinkan Anda membuat aplikasi yang dapat dieksekusi jangka panjang yang berjalan di sesi Windows mereka sendiri. Layanan ini dapat dimulai secara otomatis ketika sistem operasi dimulai, dapat dijeda dan dimulai ulang, dan tidak menampilkan antarmuka pengguna apa pun. Anda juga dapat menjalankan layanan dalam konteks keamanan akun pengguna tertentu yang berbeda dari pengguna yang masuk atau akun komputer default.

Saat melakukan kontainerisasi dan mengamankan beban kerja yang berjalan sebagai layanan Windows, ada beberapa pertimbangan tambahan yang perlu diperhatikan. Pertama, ENTRYPOINT kontainer tidak akan menjadi beban kerja karena layanan berjalan sebagai proses latar belakang, biasanya ENTRYPOINT akan menjadi alat seperti monitor layanan ) atau monitor log ). Kedua, akun keamanan yang digunakan oleh beban kerja akan dikonfigurasi oleh layanan, bukan oleh directive USER pada file docker. Anda dapat memeriksa akun di mana layanan akan dijalankan dengan menjalankan Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName.

Misalnya, ketika meng-host aplikasi web IIS menggunakan citra ASP.NET (Microsoft Artifact Registry), ENTRYPOINT dari kontainer adalah "C:\\ServiceMonitor.exe", "w3svc". Alat ini dapat digunakan untuk mengonfigurasi layanan IIS dan kemudian memantau layanan untuk memastikan bahwa layanan tetap berjalan dan keluar, sehingga menghentikan kontainer, jika layanan berhenti karena alasan apa pun. Secara default, layanan IIS dan dengan demikian aplikasi web berjalan di bawah akun hak istimewa rendah dalam kontainer, tetapi alat pemantauan layanan memerlukan hak istimewa administratif untuk mengonfigurasi dan memantau layanan.