Belajar AppArmor - Fitur Modern & Roadmap

#Pendahuluan

Di episode 20 kalian mengelola AppArmor di banyak host — distribusi profile, perbedaan kernel, dan rollout bertahap. Sekarang saatnya menengok ke depan: fitur-fitur modern yang datang di tengah transisi 5.x dan ke mana proyek ini melangkah. Episode 21 merangkum rilis pemeliharaan di cabang 4.1, fitur baru era 5.x, ekosistem container dan Kubernetes, dukungan kernel LTS, serta peta jalan menuju 5.1.

#Rilis Pemeliharaan di Cabang 4.1

Cabang 4.1 tetap menjadi jalur stabil yang paling banyak dipakai distro, dan dua rilisnya pada 2026 layak dipahami.

AppArmor 4.1.6 membawa tiga perbaikan penting. Pertama, perbaikan regresi aa-notify yang diperkenalkan 4.1.5 — versi 4.1.5 tidak disarankan untuk dipakai. Kedua, perbaikan regresi script init yang terkait dengan penonaktifan pembatasan user namespace tanpa privilege. Ketiga, perbaikan untuk utils dan pustaka Python agar bekerja di Python 3.14 dan yang lebih baru — penting karena tool seperti aa-logprof, aa-mergeprof, dan aa-easyprof berjalan di atas Python. Rilis ini juga memperkenalkan ABI baru untuk mediaksi IP/IPv6 yang lebih halus.

AppArmor 4.1.7 (10 Maret 2026) berfokus pada parser: perbaikan emisi tabel permission berdasarkan versi permstable32 yang didukung kernel. Tabel ini menentukan bagaimana permission dikodekan di policy terkompilasi; jika parser mengasumsikan versi yang lebih tinggi dari yang didukung kernel, pemuatan policy bisa gagal. Fix ini membuat kompilasi policy lebih selaras dengan kemampuan kernel aktual.

#Pembatasan User Namespace yang Tidak Privilege

Salah satu arah keamanan AppArmor modern adalah user namespace restriction: membatasi pembuatan user namespace tanpa privilege untuk memangkas vektor serangan yang selama ini dipakai untuk melarikan diri dari sandbox. AppArmor memungkinkan administrator mengizinkan pembuatan namespace hanya untuk aplikasi yang benar-benar membutuhkannya.

Pengendaliannya berada di dua lapis: sysctl untuk tingkat sistem, dan profile AppArmor untuk aplikasi yang berhak. Karena pengaturan ini sensitif, kesalahan di script init cukup berbahaya — itulah mengapa regresi yang diperbaiki di 4.1.6 dianggap penting. Jika kalian mengelola distribusi dengan fitur ini aktif, pastikan userspace berada di 4.1.6 atau lebih baru.

#Peningkatan aa-notify

aa-notify adalah alat kecil untuk memantau denial tanpa harus membaca log mentah. Ia bisa menampilkan denial sejak waktu tertentu, menyaring per user, dan — di era 5.x — menggabungkan notifikasi agar administrator tidak dibanjiri pemberitahuan duplikat.

aa-notify -s 1d -v

Peningkatan ini menjawab masalah nyata: di host dengan deny noise tinggi, aa-notify versi lama lebih terasa seperti spam daripada alat pemantauan. Penggabungan notifikasi membuatnya kembali berguna sebagai alat first alert — sebelum kalian menggali log lebih dalam dengan alat dari episode 15.

#Fitur Baru dan Transisi Policy 5.x

Di episode 19 kalian sudah mengenal fitur era 5.0: network interface mediation, network port ranges, overriding dan conditional assignment operators, diff-encoded policy, policy compression, serta extended permissions dan permission mapping. Inti transisinya: policy 4.0 tetap dimuat, fitur baru diaktifkan bertahap lewat ABI baru:

Migrasi ABI bertahap ke 5.0

abi <abi/5.0,>
 
profile myapp /opt/myapp/bin/myapp {
    # aturan yang ditulis dengan fitur 5.x
}

Rilis 5.0.1 (10 Juni 2026) menstabilkan jembatan tersebut dengan perbaikan parser — penyortiran dan deduplikasi aturan, regresi parsing mount, dan header cache terkompresi. Karena 5.0 short-lived, adopsi produksi disarankan menunggu 5.1.

#Ekosistem Container & Kubernetes

AppArmor adalah bagian penting dari keamanan container. Docker mengirimkan profile default AppArmor yang diterapkan ke container secara otomatis, dan Kubernetes memungkinkan profile kustom diterapkan per pod:

Pod dengan AppArmor profile kustom

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  annotations:
    container.apparmor.security.beta.kubernetes.io/myapp: localhost/my-app-profile
spec:
  containers:
    - name: myapp
      image: nginx:1.27
      ports:
        - containerPort: 80

Dalam ekosistem ini, fitur era 5.x ikut berperan: network interface mediation dan packet mediation memberikan kontrol yang lebih halus untuk workload yang berjalan di atas CNI, dan profile yang lebih kecil berkat kompresi berarti lebih cepat dimuat saat pod berjalan di banyak node. Prinsip dari episode 10 — profile mengikuti container, bukan host — tetap berlaku, kini dengan tooling yang lebih matang.

#Kernel: Dukungan LTS

Kernel memegang bagian eksekusi AppArmor, dan bagian ini dikelola terpisah dari userspace. Yang perlu kalian ketahui: CONFIG_SECURITY_APPARMOR aktif di kernel LTS utama — Ubuntu, Debian, dan openSUSE mengaktifkannya secara default, dan perbaikan keamanan di-backport ke rilis LTS selama masa dukungan. Verifikasi cepat:

grep -i apparmor /boot/config-$(uname -r)

Status LTS yang aktif berarti keputusan dari episode 19 — tetap di cabang 4.1.x sambil menunggu 5.1 — adalah posisi yang aman: kernel LTS akan mendukung transisi tersebut dengan backport fitur dan perbaikan yang relevan.

#Kinerja Parser 5.x

Era 5.x juga membawa perubahan kinerja yang perlu diketahui sebelum mengadopsinya. Parser berpindah ke dynamic linking secara default, yang membawa regresi waktu kompilasi sekitar empat persen — bagi yang kompilasinya kritis, tersedia opsi build WITH_STATIC_LINKING. Policy terkompresi dengan level default 10 menambah ongkos kompilasi kecil sekitar satu-dua persen, tetapi memangkas ukuran policy 40-60 persen. Diff-encoding (diaktifkan jika kernel mendukung) rata-rata mengecilkan policy runtime sekitar 15 persen.

Kombinasi ini berarti: di CI yang mengompilasi banyak profile setiap commit (episode 18), waktu kompilasi naik sedikit, tetapi kecepatan pemuatan policy di runtime dan ukuran cache membaik signifikan. Jika kompilasi dirasa lambat, parser bisa disetel lewat file konfigurasi:

/etc/apparmor/parser.conf — contoh penyesuaian

optimize=no-expr-tree
optimize=compress-fast

Penyesuaian semacam ini adalah tuning, bukan keharusan — mulai dari default dulu, ukur, baru ubah jika memang ada masalah.

#Roadmap: Menuju 5.1

Peta jalan proyek saat ini jelas: 5.1 adalah rilis fitur reguler yang menggantikan 5.0. Ia diharapkan membawa penyempurnaan parser dan kernel untuk menstabilkan fitur-fitur era 5.x, serta peningkatan untuk ekosistem container dan Kubernetes — area yang sedang menjadi fokus karena jumlah workload terkontainer terus bertambah. Distribusi kemungkinan besar mengadopsi 5.1 sebagai rilis 5.x pertama di rilis LTS mereka.

Bagi kalian, artinya satu hal: siapkan diri di era 5.x dengan belajar dari 5.0 dan 5.0.1, tapi jangan jadikan keduanya fondasi produksi. Saat 5.1 rilis, kalian sudah punya matriks pengujian, alur rollout bertahap, dan proses migrasi ABI yang siap pakai.

#Penutup

Pada episode 21 ini kalian melihat sisi terdepan AppArmor: rilis pemeliharaan 4.1.6 (perbaikan aa-notify, Python 3.14, userns) dan 4.1.7 (perbaikan tabel permission permstable32), peningkatan aa-notify, transisi policy 4.x ke 5.x bersama 5.0.1, ekosistem container dan Kubernetes, dukungan kernel LTS, serta peta jalan menuju 5.1.

Poin kunci:

• Cabang 4.1 tetap stabil dan dipelihara: gunakan 4.1.7 sebagai titik paling matang.
• permstable32 menentukan encoding permission — pastikan parser selaras dengan kernel.
• User namespace restriction dan aa-notify adalah bagian dari arah keamanan modern AppArmor.
• Container dan Kubernetes mendapat manfaat dari fitur era 5.x seperti network mediation dan policy compression.
• Kernel LTS aktif mendukung AppArmor; jadikan 5.1 target adopsi produksi.

Di episode 22 berikutnya — episode pamungkas — kita meletakkan AppArmor pada tempatnya: membandingkannya dengan SELinux, seccomp, capabilities, dan Landlock; merekap perjalanan 23 episode; dan menutup dengan checklist produksi serta peta belajar lanjutan. Sampai jumpa di episode terakhir!