Belajar Podman - Isolation & Hardening

#Pendahuluan

Di episode 15 kalian mengendalikan Podman dari jauh lewat REST API dan podman-remote. Sekarang perhatian kembali ke dalam mesin: bagaimana satu container nakal bisa menghabiskan seluruh RAM, membanjiri CPU, atau menguras sumber daya host. Episode 16 membahas isolation & hardening — membatasi resource dengan cgroups, membuat filesystem tahan banting, memutuskan jaringan, dan meninggalkan jejak audit.

#cgroups v2: Fondasi Pembatas Resource

Kontrol group (cgroups) adalah mekanisme kernel untuk membatasi dan memprioritaskan sumber daya sekelompok proses. Podman modern memakai cgroups v2, hierarki terpadu yang menyatukan controller CPU, memory, dan I/O di satu pohon. Ketika kalian menjalankan container dengan pembatas tertentu, Podman menempatkan container dalam cgroup sendiri — sehingga batasnya tegas dan tidak bisa ditembus proses lain.

#Resource Limits

Flag pembatas yang paling sering dipakai:

Pembatas	Flag	Contoh
CPU (jumlah inti)	`--cpus`	`--cpus=0.5`
CPU (share relatif)	`--cpu-shares`	`--cpu-shares=512`
Memory	`--memory`	`--memory=512m`
Swap memory	`--memory-swap`	`--memory-swap=1g`
Jumlah proses	`--pids-limit`	`--pids-limit=128`
Bobot I/O blok	`--blkio-weight`	`--blkio-weight=500`

Gabungannya dalam satu perintah:

Container dengan batasan lengkap

podman run --cpus=0.5 --memory=512m --pids-limit=128 \
  --blkio-weight=500 --name api myapp:1.2

--cpus=0.5 membatasi ke setengah inti; --pids-limit=128 menghentikan proses sebelum fork-bomb mengambil alih host; --blkio-weight memberi bobot relatif akses disk dibanding container lain.

#Memeriksa Cgroup Sebuah Container

Untuk memverifikasi batasan benar-benar aktif, podman inspect menampilkan pengaturan cgroup dan batas resource yang diterapkan:

Melihat batasan resource container

podman inspect api --format '{{.HostConfig.CpuShares}} {{.HostConfig.Memory}}'
cat /sys/fs/cgroup/podman.slice/api.scope/cpu.max

--format memungkinkan kalian mengekstrak field tertentu dari output inspect. Di sisi kernel, cgroups v2 mengekspos batas CPU sebagai pasangan nilai quota dan period di cpu.max — nilai yang dibaca controller saat runtime.

Tip

Batasi selalu memory dan PIDs, minimal untuk workload yang tidak dipercaya. Memory tanpa batas berarti OOM killer sibuk; PIDs tanpa batas berarti satu container bisa membanjiri host dengan proses. Mulai dari angka wajar lalu kalibrasi dengan podman stats.

#Read-only Rootfs

Container yang sehat tidak perlu menulis ke filesystem sendiri — data harus ke volume atau tmpfs. Dengan rootfs read-only, satu kelas serangan (menulis binary, mengubah konfigurasi, menanamkan backdoor) langsung buntu:

Rootfs read-only dengan tmpfs

podman run --read-only --tmpfs /tmp --tmpfs /run myapp:1.2

--read-only mem-mount rootfs sebagai read-only; --tmpfs menyediakan area tulis yang volatil untuk direktori yang memang butuh ditulis. Data penting tetap mengalir ke volume atau secret — bukan ke layer container.

#Memilih Mode User Namespace

Isolasi di episode 13 diperdalam di sini. Untuk workload publik, mode yang disarankan:

--userns=auto — pemetaan UID otomatis, container tidak tahu identitas host.
--userns=keep-id — ketika interaksi dengan bind mount host diperlukan.
--userns=host — hindari kecuali benar-benar dibutuhkan, misalnya untuk driver tertentu.

Warning

Kombinasi --read-only dengan bind mount yang ditulis container sering membuat bingung: penulisan melalui bind mount tetap bekerja karena mount itu tidak termasuk rootfs. Jika muncul error read-only, cek apakah aplikasi menulis ke direktori seperti /var/lib — arahkan ke tmpfs atau volume.

#Network Isolation

Jaringan adalah pintu lain yang perlu dirapikan:

Mode	Perilaku	Kapan dipakai
Bridge (default)	Container punya IP sendiri di network netavark	Umumnya
`--network=none`	Tanpa interface jaringan sama sekali	Workload sensitif, batch job
`--network=host`	Berbagi network namespace host	Optimasi latensi, perlu hati-hati
`--network=container:x`	Berbagi namespace dengan container lain	Sidecar pattern

--network=none adalah pilihan teraman untuk job yang tidak butuh akses keluar. Jika harus terhubung ke layanan lain, batasi port publish dan jangan asal expose semua.

#Seccomp & Capabilities sebagai Benteng Kedua

Episode 13 memberi fondasinya; di sini keduanya menjadi bagian dari checklist hardening yang wajib:

Mulai dari --cap-drop=ALL lalu tambahkan hanya yang dibutuhkan.
Pertahankan profile seccomp default kecuali ada alasan kuat.
Selalu pasang --security-opt no-new-privileges.
Kombinasikan dengan --read-only untuk mempersempit permukaan serangan secara drastis.

#Audit & Observability Keamanan

Hardening tanpa jejak audit sulit dipertanggungjawabkan. Podman menyediakan alur event dan statistik:

Mengaudit aktivitas container

podman events --since 1h
podman stats --no-stream
podman top <container> user,pid,comm

podman events mencatat kejadian seperti start, stop, kill, dan mount; podman stats menunjukkan pemakaian resource secara live; podman top memperlihatkan proses di dalam container. Integrasikan ketiganya ke sistem logging untuk menyimpan jejak yang bisa ditelusuri.

#Penutup

Pada episode 16 ini kalian mengisolasi dan mengeraskan container: membatasi CPU, memory, PIDs, dan I/O blok dengan cgroups v2, memasang rootfs read-only dengan tmpfs, memilih mode user namespace yang tepat, memutuskan isolasi jaringan, menutup kembali seccomp dan capabilities, serta meninggalkan jejak audit lewat events dan stats.

Inti yang harus dibawa pulang:

Batasi selalu resource — memory, PIDs, dan CPU mencegah satu container menghancurkan host.
Read-only rootfs menghentikan kelas serangan — data pergi ke volume, bukan layer.
Network dan namespace adalah gerbang — --network=none dan --userns=auto untuk workload tidak dipercaya.
Apa yang tidak diaudit tidak terjadi — pasang podman events ke sistem logging.

Di episode 17 berikutnya kalian membawa container ke level service production: systemd & service lifecycle lanjutan — socket activation on-demand, podman auto-update, dan Quadlet sebagai cara modern mendefinisikan container.