Belajar Podman - Security Model

#Pendahuluan

Di episode 12 kalian menjalankan stack multi-container dengan podman-compose dan membuka socket Docker API. Container-container itu sekarang berjalan — tapi seberapa amankah mereka? Episode 13 membahas security model Podman: bagaimana user namespaces memisahkan privilege, bagaimana SELinux dan AppArmor memberi label, serta bagaimana capabilities dan seccomp mengecilkan permukaan serangan. Ini materi inti sebelum kalian memutuskan workload apa yang pantas dijalankan.

#Trust Minimal sebagai Prinsip Dasar

Keamanan container bukan soal satu mekanisme, melainkan lapisan yang saling melengkapi. Container adalah proses yang berjalan dalam namespaces — kalau satu lapis gagal, lapis berikutnya harus tetap berdiri. Prinsipnya: berikan container hanya privilege yang dibutuhkan, tidak lebih.

#Rootless & User Namespaces

Fitur paling menonjol Podman: container berjalan rootless secara default tanpa daemon. Setiap container rootless dijalankan dalam user namespace yang memetakan user UID kalian ke UID lain di dalam container. Karena kernel melihat namespace terpisah, proses di dalam container tidak punya akses ke sistem host kecuali melalui pemetaan yang eksplisit.

Pemetaan default cukup aman, tetapi untuk kasus tertentu kalian butuh kontrol: misalnya bind-mount folder host yang dimiliki user tertentu agar tetap konsisten di dalam container.

#--userns=keep-id

podman run --userns=keep-id -v $(pwd)/data:/data myapp:1.2

--userns=keep-id membuat UID di dalam container sama dengan UID user host. Berguna saat container menulis ke bind mount milik user kalian tanpa harus bolak-balik mengubah kepemilikan file. Mode lain yang sering dipakai:

#SELinux vs AppArmor

Kedua teknologi ini melakukan hal serupa dengan pendekatan berbeda — dan menentukan distribusi Linux mana yang kalian pakai:

Untuk volume, Podman menawarkan sufiks label. -v $(pwd)/data:/data:Z memberi relabel pada volume, sedangkan :z membagikan label yang sama dengan container lain. Di mesin SELinux, lupa memberikan label ini adalah penyebab paling umum error Permission denied pada bind mount.

#Capabilities: Menjatah Privilege

Container dijalankan oleh user biasa, tetapi root di dalam container adalah root yang diperkecil: sekumpulan capabilities (hak istimewa granular) diberikan oleh runtime. Istilah default-cap-drop merujuk pada daftar capabilities yang TIDAK diberikan secara default oleh Podman dan runtime OCI — seperti CAP_SYS_ADMIN, CAP_SYS_PTRACE, CAP_DAC_READ_SEARCH, dan CAP_NET_ADMIN.

Untuk mengendalikannya:

podman run --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx:alpine
podman run --cap-drop=NET_RAW myapp:1.2

Aturan praktisnya: mulai dari --cap-drop=ALL lalu tambahkan hanya yang dibutuhkan dengan --cap-add. Service yang hanya perlu binding port di atas 1024, misalnya, cukup dengan NET_BIND_SERVICE.

#Seccomp Profiles

Seccomp memfilter syscall yang boleh dipanggil proses di dalam container. Podman menggunakan profile default dari runtime OCI yang menolak syscall berbahaya untuk skenario tertentu. Profile ini berbasis JSON dan bisa diganti:

podman run --security-opt seccomp=./my-profile.json myapp:1.2

Jika aplikasi kalian langka dan perlu syscall tertentu, kalian bisa menulis profile sendiri — tetapi pastikan kalian paham dampaknya sebelum memperlonggar filter.

#no-new-privileges

podman run --security-opt no-new-privileges myapp:1.2

--security-opt no-new-privileges menetapkan flag no_new_privs pada proses. Setelah flag ini aktif, proses dan turunannya tidak akan pernah bisa menaikkan privilege lewat mekanisme seperti setuid binary. Ini pembatas terakhir yang sederhana namun efektif.

#Menyusun Container dengan Default Aman

Setelah semua mekanisme dipelajari, inilah susunan default yang aman untuk sebagian besar workload:

podman run -d --name api \
  --userns=keep-id \
  --cap-drop=ALL --cap-add=NET_BIND_SERVICE \
  --security-opt no-new-privileges \
  --read-only --tmpfs /tmp \
  myapp:1.2

Perhatikan urutan logikanya: namespace dibatasi, capabilities diperkecil, privilege dikunci, dan filesystem dibuat read-only. Empat langkah ini menutup sebagian besar jalur serangan umum sebelum aplikasi kalian berjalan.

#Keseluruhan Lapisan Keamanan

Tidak ada satu pun yang berdiri sendiri; gabungan merekalah yang membentuk defense in depth. Kalian akan mengulang sebagian lapisan ini di episode 16 ketika membahas hardening lengkap.

#Penutup

Pada episode 13 ini kalian memahami security model Podman: prinsip trust minimal, isolasi rootless lewat user namespaces, pemetaan UID dengan --userns=keep-id, perbedaan SELinux dan AppArmor, penjatahan capabilities dengan --cap-add dan --cap-drop, filter syscall seccomp, serta penguncian dengan --security-opt no-new-privileges.

Inti yang harus dibawa pulang:

• Rootless adalah garis pertahanan pertama — user namespace memisahkan privilege sejak awal.
• Capabilities dan seccomp menyusutkan permukaan serangan — mulai dari --cap-drop=ALL dan tambahkan secukupnya.
• SELinux dan AppArmor tidak bisa dianggap sepele — label yang benar mencegah jam kerja penuh error Permission denied.
• Defense in depth — satu mekanisme boleh gagal, tetapi tidak boleh semuanya.

Di episode 14 berikutnya, kalian melindungi hal yang paling berharga: image security & secrets — bagaimana menyimpan credential tanpa bocor ke environment, memverifikasi keaslian image dengan signature, memindai kerentanan dengan Trivy, dan menambal CVE sebelum menjadi insiden.