Belajar AppArmor - Scale & Multi-host Management

#Pendahuluan

Di episode 19 kalian memahami transisi AppArmor 5.x — versi parser, cache, dan ABI policy yang berubah antar rilis. Sekarang terapkan pemahaman itu pada skala nyata: bukan satu server, tapi puluhan hingga ribuan host. Masalahnya bukan lagi apakah profile-nya benar, melainkan apakah semua host memakai profile yang sama, kernel yang setara, dan proses rollout yang aman.

Episode 20 membahas operasional AppArmor di skala fleet: distribusi profile dengan config management, konsistensi versi, perbedaan perilaku kernel antar host, rollout bertahap dari complain ke enforce, dan pemantauan regresi. Ini adalah episode yang menjembatani antara "profile bagus" dan "profile yang bertahan hidup di produksi nyata".

#Masalah di Skala: Drift dan Ketidakkonsistenan

Musuh terbesar keamanan policy di banyak host bukanlah profil yang buruk, melainkan drift — kondisi di mana tiap host sedikit berbeda: satu host masih memakai profile lama, host lain belum di-update, host ketiga kedapatan kernel baru. Drift terjadi karena ada cara lain untuk mengubah profile selain proses resmi: seseorang mengedit /etc/apparmor.d secara manual, atau menjalankan aa-enforce sendiri.

Prinsip yang harus kalian pegang: file profile di host bukanlah sumber kebenaran — sumber kebenaran ada di repository. Host hanyalah hasil render dari repository tersebut. Selama prinsip ini dipegang, drift bisa dibasmi.

#Distribusi Profile dengan Config Management

Alat standar untuk menerapkan prinsip di atas adalah config management. Baik Ansible maupun SaltStack mampu menyalin profile, lalu memuat ulang yang berubah.

- name: Deploy AppArmor profiles
  hosts: web_servers
  become: true
  tasks:
    - name: Copy profile files
      ansible.builtin.copy:
        src: "profiles/{{ item }}"
        dest: "/etc/apparmor.d/{{ item }}"
        owner: root
        group: root
        mode: "0644"
      loop:
        - usr.sbin.nginx
        - usr.bin.myapp
      register: copied
 
    - name: Reload changed profiles
      ansible.builtin.command:
        cmd: "apparmor_parser -r /etc/apparmor.d/{{ item.item }}"
      loop: "{{ copied.results }}"
      when: item.changed

/etc/apparmor.d/usr.sbin.nginx:
  file.managed:
    - source: salt://apparmor/profiles/usr.sbin.nginx
    - user: root
    - group: root
    - mode: "0644"
 
reload apparmor profiles:
  cmd.run:
    - name: apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx
    - onchanges:
      - file: /etc/apparmor.d/usr.sbin.nginx

Perhatikan pola yang sama di kedua alat: copy file, lalu reload hanya yang berubah dengan apparmor_parser -r (replace). Idempotensi ini penting — menjalankan playbook atau state berkali-kali tidak boleh menghasilkan efek samping. Ini adalah pola yang sama seperti episode 8 soal include dan tunables: perubahan sekecil apa pun harus bisa ditelusuri.

#Versi Profile yang Sama di Seluruh Fleet

Config management baru setengah pekerjaan. Bagian keduanya adalah versioning: semua host harus memakai versi profile yang sama, bukan versi yang kebetulan tersebar. Praktik yang kami rekomendasikan:

• Simpan seluruh profile di satu repository, lengkap dengan abstraksi dan tunables (pola episode 8).
• Gunakan tag atau versi pada artefak deployment — bukan "latest".
• Periksa checksum atau hash profile setelah deploy untuk memastikan isi file benar-benar sama.
• Rollback dilakukan dengan kembali ke versi lama di repository, lalu redeploy — bukan mengembalikan file dari memori seseorang.

Konsistensi versi ini yang membuat episode 18 bisa bekerja: matriks CI menguji versi yang sama persis dengan yang akan dikirim ke host.

#Perbedaan Perilaku Kernel antar Host

Sebuah fleet yang sehat pun hampir selalu punya beberapa versi kernel sekaligus — dan AppArmor memperlakukan kernel sebagai bagian dari kebijakan. Policy dikompilasi terhadap fitur yang didukung kernel tujuan, dan cache di-invalidasi saat fitur berubah. Fitur yang tersedia bisa kalian lihat langsung:

sudo aa-features-abi /etc/apparmor.d/cache/.features

ls /sys/kernel/security/apparmor/features

Implikasinya nyata: profile yang memakai fitur baru (misalnya dari era 5.x, episode 19) gagal dimuat di kernel lama yang tidak mendukungnya. Itu sebabnya matriks pengujian multi-distro bukan sekadar formalitas — apparmor_parser -Q selalu mengompilasi terhadap fitur kernel tempat ia berjalan, sehingga validasi di CI yang kernelnya berbeda bisa menipu.

Strategi pengendaliannya: konsistenkan rentang kernel. Jika fleet harus menjalankan versi kernel berbeda, pastikan setiap versi diuji dalam matriks; jika memungkinkan, kunci image atau kernel minimum di seluruh fleet agar perilaku AppArmor dapat diprediksi.

#Rollout Bertahap: Complain ke Enforce

Setelah profile terdistribusi, pertanyaannya: bagaimana mengaktifkan enforce tanpa membakar seluruh fleet? Jawabannya adalah rollout bertahap dalam empat fase:

1. Canary complain — satu host mewakili tiap jenis beban kerja dipindah ke complain; amati denial selama beberapa hari.
2. Fleet complain — seluruh host di complain; denial dikumpulkan sebagai baseline.
3. Canary enforce — host canary di-enforce; pastikan tidak ada denial kritis yang baru.
4. Fleet enforce — perbaiki semua masalah dari fase 2 dan 3, baru seluruh fleet di-enforce.

Peralihan per fase memakai tool dari episode 18:

for p in /etc/apparmor.d/usr.*; do
    sudo aa-complain "$p"
done

for p in /etc/apparmor.d/usr.*; do
    sudo aa-enforce "$p"
done

#Monitoring Regresi

Fase-fase di atas hanya berguna jika kalian punya cara mengukur apakah rollout berjalan baik. Monitoring regresi bekerja dengan membandingkan jumlah dan jenis denial sebelum vs sesudah rollout per host:

journalctl -k --since today | grep -c 'apparmor="DENIED"'

sudo aa-status | head -20

Praktik yang disarankan: catat baseline denial per profile sebelum rollout, lalu alarm jika muncul kelas denial baru setelah enforce — terutama pada profile yang sama di beberapa host sekaligus (pola yang menandakan masalah sistemik, bukan kebetulan). Ringkasan cepat per host bisa diperoleh dari aa-status. Gabungkan ini dengan pemantauan dari episode 15: deny yang meningkat mendadak di satu host mungkin menandakan aplikasi berubah perilaku, atau lebih buruk — ada yang mencoba melanggar policy.

#Penutup

Pada episode 20 ini kalian membawa AppArmor ke skala fleet: repository sebagai sumber kebenaran yang dirender ke setiap host lewat Ansible atau SaltStack, versioning profile yang seragam agar matriks CI berarti, pengendalian perbedaan kernel lewat fitur ABI, rollout empat fase dari canary complain hingga fleet enforce, dan monitoring regresi berbasis baseline denial.

Poin kunci:

• File di host adalah hasil render repository, bukan sumber kebenaran.
• Reload per profile dengan apparmor_parser -r, jangan restart service apparmor.
• Satu versi profile untuk seluruh fleet, dengan rollback lewat repository.
• Kernel menentukan fitur policy — konsistenkan atau uji semuanya.
• Rollout wajib bertahap: canary complain, fleet complain, canary enforce, fleet enforce.
• Monitor regresi dengan baseline denial per profile.

Di episode 21 berikutnya kita menengok ke depan: Fitur Modern & Roadmap — rilis pemeliharaan 4.1.6 dan 4.1.7, peningkatan aa-notify, dukungan Python 3.14, ekosistem container dan Kubernetes, hingga status dukungan kernel LTS. Sampai jumpa!