Mengapa Container Tidak Seharusnya Berjalan sebagai Root secara Default?

Menjalankan container sebagai root adalah salah satu miskonfigurasi paling umum — dan paling berbahaya — di lingkungan produksi. Hal ini secara diam-diam memperluas permukaan serangan setiap workload, dan sebagian besar tim tidak menyadarinya sampai insiden memaksa masalah ini keluar.

Apa yang Sebenarnya Dimaksud "Berjalan sebagai Root"

Secara default, banyak citra container (terutama yang minimal atau legacy) menjalankan proses utama mereka sebagai UID 0 di dalam container. Karena container berbagi kernel host dengan container lain dan host itu sendiri, root di dalam container tidak sama dengan root pada mesin virtual yang sepenuhnya terisolasi — tetapi tetap jauh lebih kuat dari seharusnya. Jika penyerang mencapai eksekusi kode di dalam container yang dimiliki root, mereka mewarisi:

• Akses baca/tulis penuh ke file apa pun yang dipasang ke container, terlepas dari izin yang dimaksudkan
• Kemampuan untuk memasang paket, memodifikasi binary, atau mengganggu status aplikasi
• Jalur yang jauh lebih mudah menuju container breakout jika kerentanan kernel atau runtime dapat dieksploitasi
• Leverage yang ditingkatkan jika dikombinasikan dengan volume yang dikonfigurasi salah, seperti soket Docker yang dipasang atau jalur filesystem host

Bahkan tanpa exploit kernel, akses root di dalam container secara dramatis meningkatkan radius ledak dari kerentanan tingkat aplikasi apa pun (SSRF, deserialisasi bugs, arbitrary file write, dll.).

Mengapa Hal Ini Lebih Penting dalam Lingkungan Orkestrasi

Dalam kluster Kubernetes, container root yang dikombinasikan dengan Linux capabilities berlebihan atau security context permisif dapat memungkinkan penyerang:

• Memodifikasi /proc atau /sys dengan cara yang memengaruhi host
• Meningkatkan privilege jika hostPID, hostNetwork, atau hostIPC diaktifkan
• Menyalahgunakan token service account yang dipasang untuk pivot secara lateral di seluruh kluster
• Melarikan diri ke node jika privileged: true diatur atau capabilities berbahaya seperti SYS_ADMIN diberikan

Pengguna root itu sendiri tidak selalu merupakan kerentanan — ini adalah kombinasi root ditambah kernel capabilities yang terlalu murah hati, host mount, atau namespace sharing yang mengubah kompromi contained menjadi kompromi kluster-lebar.

Langkah Pengerasan Praktis

1. Tetapkan Pengguna Non-Root di Citra

Tentukan secara eksplisit pengguna non-root di Dockerfile Anda daripada mengandalkan default:

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. Terapkan pada Tingkat Orchestrator

Jangan hanya percayai citra — terapkan kebijakan saat runtime. Di Kubernetes, gunakan securityContext:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true menyebabkan pod gagal pada admission jika citra mencoba berjalan sebagai UID 0, memberikan Anda jaminan keras daripada konvensi best-effort.

3. Hapus Capabilities yang Tidak Perlu

Sebagian besar aplikasi tidak memerlukan capability Linux default apa pun yang diberikan kepada container. Hapus semuanya dan tambahkan kembali hanya apa yang benar-benar diperlukan (kasus langka seperti binding ke port rendah mungkin memerlukan NET_BIND_SERVICE).

4. Hindari Privileged Mode dan Host Namespace Sharing

privileged: true, hostNetwork: true, dan hostPID: true harus disediakan untuk workload infrastruktur yang sangat spesifik (seperti agent CNI atau monitoring tertentu) — tidak pernah untuk container aplikasi umum.

5. Pindai dan Terapkan dengan Tools Kebijakan

Gunakan admission controller atau policy engine (misalnya, Kyverno, OPA/Gatekeeper) untuk menolak deployment yang melanggar aturan ini secara otomatis, daripada mengandalkan review kode manual. Pasangkan ini dengan image scanning di CI untuk menangkap citra root-user sebelum mencapai kluster.

Pertahanan Berlapis, Bukan Sempurna

Berjalan sebagai non-root tidak menghilangkan risiko sepenuhnya — container escape tingkat kernel ada terlepas dari pengguna dalam-container — tetapi menghilangkan kelas enorm teknik escalasi privilege dan lateral movement yang low-effort. Dikombinasikan dengan filesystem read-only, dropped capability, dan network policy ketat, ini membentuk salah satu lapisan termurah dan paling efektif dalam strategi keamanan container defense-in-depth.

Ingin mempelajari lebih dalam tentang pengerasan cloud-native workload? Jelajahi segmen Korra Studio terkait pada keamanan Cloud dan hardening DevOps pipeline untuk membangun strategi defense-in-depth Anda.