Anda dapat menjalankan Docker dalam produksi selama berbulan-bulan tanpa masalah yang terlihat. Kontainer dimulai, aplikasi merespons, tidak ada yang rusak. Kemudian satu port yang terbuka atau satu izin yang salah dikonfigurasi menciptakan pijakan yang tidak perlu diperoleh oleh penyerang. Sebagian besar kesalahan keamanan Docker tidak terlihat seperti kesalahan sampai terjadi kesalahan.
Artikel ini membahas konfigurasi spesifik yang membahayakan lingkungan kontainer, apa saja yang memungkinkan penyerang, dan diakhiri dengan daftar periksa yang dapat Anda jalankan terhadap pengaturan Anda sendiri sekarang.
Mengapa Keamanan Docker Lebih Sulit Dari Kelihatannya
Kontainer terasa terisolasi. Anda memulainya, ia menjalankan ruang prosesnya sendiri, dan dari dalamnya, penampung berikutnya tidak ada. Anda memang mendapatkan isolasi, tetapi itu hanya sebagian. Kontainer berbagi kernel host, yang berarti proses di dalam kontainer, dalam kondisi tertentu, dapat menjangkau sistem host sepenuhnya.
Kapal Docker dikonfigurasi untuk kenyamanan pengembang, bukan pengerasan produksi. Akses root aktif. Semua port dapat diikat ke semua antarmuka. Tidak ada pemantauan waktu proses. Sebagian besar pengembang menerima pengaturan tersebut, mengirimkan kontainer, dan melanjutkan. Itu adalah pendekatan yang masuk akal untuk memulai; ini bukanlah postur keamanan yang lengkap.
Menurut Laporan Keamanan Status Kubernetes tahun 2024 dari Red Hat, 67% organisasi menunda atau memperlambat penerapan aplikasi karena masalah keamanan container atau Kubernetes. Gesekan itu biasanya bukan disebabkan oleh serangan. Hal ini berasal dari tim yang menyadari bahwa penyiapan container mereka memerlukan pengerasan yang belum mereka buat sebelumnya.
Kita sering melihat container berjalan dalam produksi dengan konfigurasi yang sama dengan yang ada di mesin lokal pengembang. Di sinilah kesalahan keamanan Docker cenderung bertambah secara diam-diam, tanpa gejala yang terlihat hingga ada sesuatu yang diaudit atau gagal.
Kesalahan yang menciptakan kesenjangan tersebut bersifat spesifik, dapat diprediksi, dan sebagian besar dapat dihindari, dimulai dari tingkat konfigurasi.
Kesalahan Umum Konfigurasi Docker
Sebagian besar pelanggaran container tidak dimulai dengan eksploitasi zero-day. Mereka memulai dengan konfigurasi yang ditetapkan pada hari pertama, tanpa banyak memikirkan tentang paparan jaringan atau cakupan hak istimewa.
Pengaturan Docker default dibuat agar berfungsi. Kesenjangan antara fungsional dan aman adalah tempat terjadinya akumulasi risiko keamanan kontainer Docker, terutama dalam pengaturan yang dihosting sendiri yang diterapkan dan tidak pernah ditinjau kembali.
Kita sering melihat pola ini: container di server IP publik dengan pengikatan port, pengaturan pengguna, dan konfigurasi jaringan persis seperti pada penerapan awal.
Menjalankan Kontainer sebagai Root
Saat Anda memulai kontainer Docker tanpa menentukan pengguna, kontainer tersebut berjalan sebagai root. Artinya, setiap proses di dalam container, termasuk aplikasi Anda, memiliki hak istimewa tingkat root di dalam namespace container.
Root di dalam container tidak sama dengan root di host, namun pemisahannya tidak mutlak. Eksploitasi eskalasi hak istimewa yang menargetkan runtime, seperti runc CVE-2019-5736 yang terdokumentasi dengan baik dan kelemahan runtime serupa, sering kali memerlukan proses container root agar berhasil.
Kontainer non-root menghilangkan persyaratan proses root yang menjadi sandaran eksploitasi tersebut, sehingga secara signifikan mempersempit permukaan serangan untuk kelas kerentanan tersebut, meskipun kontainer tersebut tidak sepenuhnya menghilangkan risiko keluarnya kontainer.
Menambahkan arahan USER ke Dockerfile Anda akan mengatasi hal ini. Beberapa gambar resmi dikirimkan dengan pengguna yang tidak memiliki hak istimewa, Anda dapat mengaktifkannya dengan arahan USER, tetapi banyak yang masih default untuk di-root tanpa pengguna aplikasi siap pakai. Dalam kasus tersebut, Anda membuat pengguna di Dockerfile sebelum beralih ke sana. Untuk sebagian besar pengaturan yang dihosting sendiri, perubahan tunggal ini menghilangkan seluruh kategori risiko eskalasi.
Mengekspos Terlalu Banyak Port ke Internet Publik
Saat Anda memublikasikan port dengan Docker, Docker menulis aturan iptablesnya sendiri secara langsung. Aturan tersebut dijalankan sebelum aturan firewall tingkat host. Ini adalah sebuah perilaku terkenal yang dilaporkan oleh masyarakat Dan didokumentasikan dalam panduan pemfilteran paket Docker, bukan kesalahan konfigurasi, dan itu berarti UFW dan alat serupa tidak memblokir apa yang telah dibuka Docker.
Docker menulis langsung ke iptables, melewati default UFW dan firewalld di banyak host Linux. Itu berarti port yang terikat ke 0.0.0.0 dapat dijangkau secara publik bahkan ketika firewall Anda tampak terkonfigurasi. Grup keamanan cloud dan aturan rantai DOCKER-USER masih dapat memblokir lalu lintas tersebut, sehingga paparan sebenarnya bergantung pada pengaturan jaringan spesifik Anda.
Ikat layanan ke 127.0.0.1 jika memungkinkan, rutekan lalu lintas yang dapat dilihat publik melalui proksi terbalik, dan publikasikan hanya apa yang benar-benar memerlukan akses eksternal. Proksi terbalik adalah cara paling andal untuk mengontrol apa yang terekspos dari luar host.
Mengabaikan Isolasi Jaringan Antar Kontainer
Setiap kontainer di jaringan tersebut dapat menjangkau kontainer lain di dalamnya tanpa batasan. Jembatan default tidak menerapkan pemfilteran lalu lintas antar kontainer yang berbagi jembatan tersebut, dan sebagian besar penyiapan tidak pernah mengubah konfigurasi tersebut.
Jika satu wadah dikompromikan, komunikasi terbuka itu menjadi jalur pergerakan lateral. Kontainer frontend dapat menjangkau database, API internal, atau apa pun di jaringan jembatan default yang sama, meskipun akses tersebut tidak pernah dimaksudkan.
Jaringan yang ditentukan pengguna memberi Anda kontrol eksplisit terhadap container mana yang dapat berkomunikasi, namun satu jaringan khusus yang digunakan bersama oleh semua layanan Anda tetap mengizinkan lalu lintas antar container gratis. Isolasi nyata memerlukan penempatan layanan yang tidak boleh berkomunikasi satu sama lain di jaringan terpisah. Mematikan jembatan bawaan adalah titik awal, bukan garis akhir.
Menghadap ke Soket Docker
Soket Docker di /var/run/docker.sock adalah antarmuka kontrol untuk seluruh mesin Docker. Memasangnya ke dalam container memberi container tersebut akses API langsung ke daemon yang berjalan di host.
Dengan akses tersebut, sebuah container dapat memulai container baru, memasang direktori host, memeriksa dan memodifikasi container yang sedang berjalan, dan mengontrol mesin host secara efektif. Permukaan serangan setara dengan root pada host, itulah sebabnya alat apa pun yang memerlukan akses soket perlu dievaluasi secara cermat.
Untuk sebagian besar kasus penggunaan, ada alternatif yang lebih aman: API tercakup atau Alat manajemen Docker yang tidak memerlukan akses soket. Docker-in-Docker memiliki trade-off keamanan dan operasionalnya sendiri dan bukan merupakan pengganti langsung.
Kesalahan konfigurasi menciptakan paparan awal. Pilihan citra dan ketergantungan menentukan bagaimana paparan tersebut bertambah seiring waktu.
Kesalahan Gambar dan Rahasia yang Lebih Lama dari Wadahnya
Saat Anda menghentikan sebuah container, kesalahan konfigurasi di dalamnya juga ikut terhenti. Saat Anda membangun kembali dari gambar yang membawa kerentanan atau kredensial hardcode, masalahnya dimulai ulang dengan kontainer. Kesalahan tingkat gambar tidak diatur ulang di antara penerapan.
Mereka melakukan perjalanan dengan gambar tersebut ke setiap lingkungan yang menariknya, setiap registri yang menyimpannya, dan setiap anggota tim yang menjalankannya. Kegigihan tersebut menjadikan pengelolaan gambar dan rahasia sebagai kategori risiko yang berbeda, sehingga layak untuk diaudit secara terpisah dari konfigurasi.
Kita sering melihat pola ini: sebuah gambar dipilih dengan hati-hati pada awal proyek dan tidak pernah dibuat ulang sejak saat itu, perlahan-lahan menyimpang dari garis dasar keamanan yang diwakilinya pada awalnya.
Menggunakan Gambar Tidak Tepercaya atau Kedaluwarsa
Pendaftaran publik terbuka untuk siapa saja. Gambar berbahaya telah didistribusikan melalui Docker Hub yang membawa penambang kripto dan pintu belakang yang tertanam dalam riwayat lapisan yang tetap ada selama kontainer dimulai ulang. Verifikasi sebelum menarik itu penting, terutama untuk gambar dari penerbit tidak resmi atau tidak dikenal.
Masalah terpisahnya adalah staleness. Gambar resmi yang Anda ambil enam bulan lalu dan tidak pernah dibuat ulang sejak itu telah mengumpulkan kerentanan Docker yang belum ditambal dengan setiap CVE yang diungkapkan pada paketnya. Gambarnya tidak rusak. Itu sudah tidak berlaku lagi.
Laporan Keadaan Rantai Pasokan Perangkat Lunak Sonatype tahun 2024 menemukan bahwa 95% dari waktu penggunaan komponen yang rentan, versi tetap sudah tersedia, dan 80% dependensi aplikasi masih belum ditingkatkan versinya selama lebih dari setahun. Pola tersebut juga relevan dengan image dasar Docker, karena mereka bergantung pada paket sumber terbuka yang sama.
Gunakan gambar resmi dari penerbit terverifikasi dan sematkan tag versi tertentu daripada mengandalkan “terbaru”. Bangun irama pembangunan kembali secara teratur untuk menjaga gambar Anda tetap terkini.
Rahasia Hardcoding di Dockerfiles dan Compose Files
Kredensial yang ditulis ke dalam instruksi Dockerfile ENV atau ARG, di-hardcode ke dalam blok lingkungan Compose, diteruskan sebagai argumen build, atau disimpan dalam file .env yang dikomit ke kontrol versi tidak hilang saat Anda menghentikan container. Mereka tetap berada dalam riwayat lapisan gambar atau kontrol sumber, dapat diakses oleh siapa saja yang dapat mengaksesnya.
Ini adalah salah satu kesalahan keamanan Docker yang paling diabaikan karena tidak menimbulkan masalah yang terlihat selama pengembangan. Kunci API dalam instruksi ENV berfungsi dengan benar. Itu juga ada di repositori Anda, dimasukkan ke dalam gambar Anda, dan didistribusikan ke mana pun gambar itu dibawa.
Docker Compose modern mendukung mekanisme rahasia asli yang memasang kredensial saat runtime tanpa memasukkannya ke dalam image. API rahasia Docker dan pengelola rahasia eksternal mengikuti prinsip yang sama. Ini adalah opsi yang menjaga kredensial sepenuhnya keluar dari artefak build dan file yang dikomit.
Variabel lingkungan runtime merupakan peningkatan dibandingkan kredensial hardcode, namun variabel tersebut masih diekspos melalui output pemeriksaan Docker, log, dan crash dump. Ini adalah langkah maju dari rahasia yang tersimpan, bukan solusi akhir.
Tidak Memperbarui Gambar Kontainer Secara Teratur
Menjalankan gambar yang sama selama berbulan-bulan adalah kebiasaan umum. Setiap hari yang berlalu setelah kerentanan baru terungkap, namun sebelum Anda membangun kembali, kontainer Anda membawa jendela eksposur yang bertambah tanpa perubahan yang terlihat.
Buatlah jadwal pembangunan kembali yang konsisten. Otomatiskan proses tersebut jika memungkinkan, dan jalankan pemindai kerentanan secara berkala terhadap gambar Anda saat ini. Tujuannya bukanlah kesempurnaan. Ini mempersempit waktu antara rilis patch dan penerapannya.
Kontrol akses dan pemantauan dapat menjadi tidak diprioritaskan dalam penerapan yang cepat. Ini juga merupakan kategori di mana insiden paling lama tidak terdeteksi.
Kontrol Akses dan Kesenjangan Visibilitas
Setelah container berjalan dengan konfigurasi solid dan image saat ini, masih ada dua kategori kegagalan. Keduanya pada dasarnya tidak terlihat: Anda tidak akan menyadari adanya masalah kontrol akses yang lemah hingga seseorang menggunakannya, dan Anda tidak akan melihat adanya kesenjangan pemantauan hingga Anda perlu menyelidiki aktivitas yang tidak pernah dicatat.
Hal yang sama Penelitian Red Hat 2024 menemukan bahwa 42% tim tidak memiliki kemampuan yang memadai untuk mengatasi keamanan kontainer dan ancaman terkait.
Kami menemukan bahwa kesenjangan pemantauan biasanya muncul pada saat investigasi insiden, bukan sebelumnya. Ketika visibilitas menjadi prioritas, hal ini sering kali merupakan respons terhadap sesuatu, bukan mencegahnya.
Otentikasi Lemah dan Dasbor Manajemen Terkena
Dasbor manajemen kontainer pada IP publik tanpa autentikasi tidak memerlukan penyerang yang canggih. Itu mengharuskan mereka untuk mengetahui alamatnya. Itu adalah batasan yang lebih rendah dari yang disadari kebanyakan tim.
Alat pemantauan dan manajemen yang dihosting sendiri biasanya dikirimkan dengan antarmuka web yang dapat diakses di semua antarmuka jaringan. Membiarkannya menggunakan IP publik tanpa autentikasi di depannya sama saja dengan membiarkan panel admin tidak terkunci.
Otentikasi, proksi terbalik, dan penempatan jaringan pribadi adalah dasar-dasarnya. Kontrol akses adalah langkah konfigurasi yang Anda tambahkan ke antarmuka manajemen apa pun, bukan sesuatu yang diaktifkan.
Prinsip yang sama berlaku untuk Docker CLI dan manajemen GUI; akses tingkat admin ke daemon membawa risiko yang sama apa pun antarmukanya.
Tidak Memantau Apa yang Dilakukan Kontainer Anda
Jika sebuah container disusupi, aktivitas penyerang akan membuat jejak: perubahan perilaku proses, koneksi jaringan yang tidak biasa, dan modifikasi file yang tidak terduga. Tanpa adanya pengumpulan kayu, jejak tersebut tidak akan ada dalam bentuk yang dapat Anda tindak lanjuti.
Pengumpulan log terpusat, pencatatan audit kontainer, dan alat pemantauan runtime memberi Anda data untuk mendeteksi aktivitas abnormal sebelum aktivitas tersebut bertambah. Tujuannya bukan menganalisis setiap baris. Ini menyediakan data saat Anda perlu menyelidikinya.
Penyiapan kontainer yang berjalan secara diam-diam dalam produksi tanpa alur log dan tanpa peringatan bukanlah hal yang mudah pemeliharaannya. Mereka tidak diperiksa. Itu adalah dua status operasional yang berbeda.
Mengapa Lingkungan Infrastruktur Juga Penting
Keamanan kontainer dimulai dengan konfigurasi, namun konfigurasi berjalan di atas infrastruktur. Host dengan jaringan yang salah dikonfigurasi, sumber daya bersama, atau tanpa pemfilteran tingkat jaringan menciptakan kondisi yang memengaruhi setiap kontainer di atasnya. Melakukan penyiapan container dengan benar dan konfigurasi server dengan benar adalah dua tugas terpisah.
Banyak celah keamanan Docker yang diperparah oleh kondisi yang diwarisi oleh container itu sendiri:
- Server penyewaan bersama tanpa isolasi perangkat keras antar penyewa
- Kernel host berjalan belum ditambal
- Host tanpa pemfilteran tingkat jaringan bawaan
Hal ini tidak menghilangkan kebutuhan akan langkah-langkah konfigurasi di atas, karena pengerasan kontainer yang tepat sangatlah penting, apa pun lapisan infrastrukturnya. Memulai infrastruktur yang terisolasi akan menghilangkan satu lapisan kekhawatiran saja.
Di Cloudzy, kami menawarkan dua jalur bergantung pada kebutuhan pengaturan Anda:
- VPS Linux: lingkungan yang bersih untuk menerapkan Docker sendiri dan menerapkan langkah-langkah pengerasan dalam artikel ini
- VPS Portainer: opsi sekali klik dengan Portainer yang sudah diinstal sebelumnya; server melakukan booting, dan Anda sudah berada di dasbor
Kedua opsi berjalan pada infrastruktur yang sama: virtualisasi KVM, CPU AMD Ryzen 9 dengan boost clock hingga 5,7 GHz, memori DDR5, penyimpanan NVMe SSD, jaringan hingga 40 Gbps, dan perlindungan DDoS gratis melalui pemfilteran BuyVM, di 12 lokasi global dengan SLA waktu aktif 99,95%.
Untuk melihat lebih dalam tentang cara menjalankan Portainer di VPS, kami membahasnya dalam artikel khusus.
Daftar Periksa Keamanan Praktis untuk Penerapan Docker
Kesalahan keamanan Docker di atas sebagian besar berasal dari keputusan konfigurasi tunggal yang dibuat satu kali dan tidak pernah ditinjau kembali. Menjalankan daftar periksa ini terhadap pengaturan yang ada akan mengatasi kesenjangan tersebut. Ini berfungsi sebagai audit, bukan panduan penerapan.
Praktik terbaik keamanan Docker ini mencakup cara mengamankan kontainer Docker dari kegagalan konfigurasi paling umum yang dijelaskan di atas.
Referensi Singkat: Semua 9 Kesalahan
| Kesalahan | Kategori | Perbaikan Satu Baris |
| Berjalan sebagai root | Konfigurasi | Menambahkan PENGGUNA arahan ke Dockerfile Anda |
| Port terikat ke 0.0.0.0 | Konfigurasi | Ikat ke 127.0.0.1 dan rutekan melalui proxy terbalik |
| Tidak ada isolasi jaringan | Konfigurasi | Membagi layanan di jaringan terpisah yang ditentukan pengguna berdasarkan kebutuhan akses. |
| Soket Docker terpasang | Konfigurasi | Lepaskan dudukannya; gunakan API atau alternatif yang dicakup |
| Gambar tidak tepercaya atau ketinggalan jaman | Gambar | Gunakan gambar resmi dengan tag versi yang disematkan |
| Rahasia yang dikodekan secara keras | Gambar | Pindahkan kredensial ke runtime env vars atau manajer rahasia |
| Tidak ada jadwal pembuatan ulang gambar | Gambar | Tetapkan irama pembangunan kembali bulanan; mengotomatiskan jika memungkinkan |
| Dasbor yang tidak diautentikasi | Mengakses | Tambahkan autentikasi dan pindahkan UI manajemen ke jaringan pribadi |
| Tidak ada pengumpulan log kontainer | Mengakses | Siapkan pencatatan log terpusat dan pemantauan runtime |
Kami merekomendasikan untuk menjalankannya pada penyiapan yang sudah ada terlebih dahulu, karena di situlah kemungkinan besar terdapat kesenjangan.
Kontainer berjalan sebagai non-root: Periksa Dockerfiles Anda untuk arahan USER. Jika tidak ada, container dijalankan sebagai root.
Pengikatan port terbatas pada localhost atau proksi: Jalankan docker ps dan tinjau pengikatan port. Entri 0.0.0.0:PORT dapat dijangkau secara publik di host di mana tidak ada grup keamanan upstream, firewall eksternal, atau aturan rantai DOCKER-USER yang memblokirnya.
Jaringan jembatan khusus yang digunakan: Kontainer di jembatan default Docker dapat menjangkau satu sama lain dengan bebas. Kontainer di jembatan yang ditentukan pengguna masih dapat berkomunikasi satu sama lain, jadi pisahkan layanan di jaringan terpisah berdasarkan batas kepercayaan untuk isolasi sebenarnya.
Soket Docker tidak dipasang di container: Centang Tulis file dan jalankan argumen. Jika /var/run/docker.sock muncul sebagai volume, konfirmasikan bahwa itu diperlukan dan disengaja.
Gambar dasar dari penerbit terverifikasi dengan versi yang disematkan: A FROM ubuntu:latest menarik versi yang tidak ditentukan dan berpotensi ketinggalan jaman. Sematkan ke rilis tertentu.
Tidak ada rahasia di Dockerfiles, Tulis file, atau argumen build: Riwayat lapisan gambar tetap mempertahankan kredensialnya setelah penghapusan kontainer. Gunakan Rahasia Tulis, Rahasia Swarm, buat tunggangan rahasia, atau pengelola rahasia eksternal. Variabel lingkungan waktu proses lebih baik daripada nilai hardcode, namun masih muncul dalam keluaran pemeriksaan dan log.
Jadwal pembuatan ulang gambar ditentukan: Gambar-gambar lama mengumpulkan kerentanan. Irama pembangunan kembali bulanan membuat jendela eksposur dapat dikelola untuk sebagian besar pengaturan.
Antarmuka manajemen di balik otentikasi: Dasbor apa pun pada IP publik tanpa autentikasi adalah titik masuk terbuka. Penempatan jaringan pribadi lebih disukai jika memungkinkan.
Log kontainer sedang dikumpulkan: Tanpa alur log, deteksi insiden bergantung pada dampak sistem yang terlihat. Ini adalah sinyal yang terlambat untuk ditindaklanjuti.
Kesimpulan
Konfigurasi default Docker dibuat untuk kenyamanan, bukan keamanan. Sebagian besar kesalahan yang dibahas dalam artikel ini berasal dari pengaturan yang tidak pernah diubah setelah penerapan awal, bukan karena serangan yang canggih.
Perbaikannya sebagian besar merupakan keputusan konfigurasi satu kali: arahan USER, perubahan pengikatan port, jaringan khusus, jadwal pembangunan kembali. Tak satu pun dari mereka memerlukan peralatan baru untuk sebagian besar pengaturan.
Memperbaiki konfigurasi container adalah tugas pertama. Infrastruktur yang dijalankannya adalah yang kedua. Keduanya penting, dan tidak ada yang bisa menggantikan yang lain.
