Belajar GitOps dengan ArgoCD - Compliance & Audit

#Pendahuluan

Di episode 23 sebelumnya kita membangun keamanan berlapis — autentikasi, RBAC, jaringan, dan supply chain. Ada satu hasil samping yang mungkin tidak kalian sadari: setiap lapisan itu menghasilkan bukti. Di episode ini kita memanfaatkannya: compliance & audit. Karena dalam GitOps, jawaban atas pertanyaan auditor "siapa yang mengubah apa, kapan, dan siapa yang menyetujui" bukanlah laporan yang dibuat susah payah, melainkan artefak alami dari Git dan log ArgoCD.

Mengapa ini penting? Standar seperti SOC 2, HIPAA, dan PCI-DSS menghukum organisasi yang tidak bisa membuktikan kontrolnya. Secara tradisional, membuktikan kontrol deployment berarti pipeline raksasa yang dicatat dalam spreadsheet — mahal dan tidak pernah akurat. GitOps membaliknya: karena setiap perubahan deployment adalah commit yang ditandatangani oleh penulisnya, audit trail ada secara default. Tugas kita hanyalah merangkainya menjadi bukti yang bisa disajikan.

#Audit Logging

Audit trail GitOps punya tiga lapisan yang saling melengkapi:

1. Git commit history — sumber kebenaran perubahan konfigurasi: penulis, waktu, pesan, dan diff.
2. Log audit ArgoCD — aksi API server: siapa login, siapa trigger sync, dari mana.
3. Log controller — pekerjaan otomatis: reconcile, sync operation, kegagalan.

Aktifkan audit log API server dengan menambah argumen --audit-log-path pada deployment argocd-server:

spec:
  template:
    spec:
      containers:
        - name: argocd-server
          args:
            - /usr/local/bin/argocd-server
            - --audit-log-path=/var/log/audit.log
            - --audit-log-format=json

Dengan format JSON, setiap aksi API terekam dengan user, resource, aksi, dan IP — bahan baku untuk jawaban "siapa yang menjalankan sync pukul 03.00?". Di lapisan Git, seluruh riwayat commit bisa diakses siapa pun tanpa tooling tambahan:

git log --oneline --all -- manifests/overlays/prod/api
git show --stat <commit>

Perhatikan bahwa keduanya harus dihubungkan: commit di Git adalah keputusan, log ArgoCD adalah eksekusi. Aplikasi mengubah manifest (commit abc123), lalu sync terekam di audit log ArgoCD. Untuk jejak yang lengkap, kalian butuh keduanya.

#Persyaratan Compliance

Setiap standar punya penekanan berbeda; GitOps mengubahnya dari "pekerjaan berat" menjadi "verifikasi rutin":

#Change Approval Workflows

Auditor ingin melihat ada proses sebelum perubahan masuk produksi. Dalam GitOps, proses itu adalah pull request dengan review:

1. Developer mengubah manifest di branch feature/x.
2. CI menjalankan validasi manifest (lint, helm template, policy check dari episode 23).
3. Dua reviewer menyetujui pull request; branch protection memblokir merge tanpa itu.
4. Merge ke main memicu ArgoCD untuk menyinkronkan — eksekusi yang tercatat.

Setiap langkah menghasilkan jejak yang bisa diaudit. Ini adalah contoh sempurna "audit trail yang terbentuk karena alur kerja, bukan karena laporan".

#Audit Trail: Siapa, Apa, Kapan

Pertanyaan inti audit: siapa mengubah apa, kapan. Git menyediakan siapa dan kapan; argocd app history menyediakan apa yang berubah di sisi eksekusi:

Riwayat deployment

argocd app get api --history
argocd app rollback api 3
argocd app get api --refresh

Setiap baris history mencatat revision manifest, waktu sync, dan user pemicunya. Rollback juga tercatat — ini penting untuk menjawab "apa yang terjadi saat insiden?". Audit trail yang lengkap memiliki empat bagian: keputusan (commit), persetujuan (review), eksekusi (sync), dan pemulihan (rollback). GitOps menyimpan semuanya.

#Reporting

Kontrol yang tidak diukur tidak bisa diperbaiki. DORA metrics — yang kini menjadi bahasa umum engineering — bisa dihitung langsung dari Git dan log ArgoCD:

• Change frequency — berapa kali main berubah per periode; dihitung dari jumlah commit/merge per hari.
• Lead time — waktu dari commit pertama sampai deploy sukses; diukur dari git log sampai status Synced di ArgoCD.
• MTTR (Mean Time To Recovery) — waktu dari deteksi insiden sampai aplikasi kembali sehat; dapat dihitung dari durasi status Degraded/OutOfSync dalam metrik (episode 22).

Contoh query untuk menghitung durasi app tidak sehat:

time() - max(argocd_app_sync_status{sync_status="OutOfSync"} == 1) by (name)

Laporan compliance kemudian menjadi dashboards (episode 22) dan ekspor berkala: daftar perubahan mingguan, daftar akses yang aktif, dan ringkasan insiden dengan timeline pemulihan. Jika audit menuntut, semua laporan ini punya tautan langsung ke bukti mentahnya — commit atau log.

#Policy as Code

Langkah terakhir: pastikan kebijakan itu sendiri dikelola seperti kode — di Git, direview, dan ditegakkan otomatis.

#OPA dan Kyverno

Kedua alat menjalankan kebijakan sebagai admission webhook: setiap resource yang akan diterapkan (termasuk oleh ArgoCD) diperiksa sebelum masuk cluster.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-owner-label
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-team-label
      match:
        resources:
          kinds:
            - Namespace
      validate:
        message: "Namespace harus punya label team"
        pattern:
          metadata:
            labels:
              team: "?*"

Kekuatan kombinasi GitOps + policy as code: kebijakan disimpan di repo yang sama, diterapkan ArgoCD ke cluster, dan dijalankan webhook saat resource diterapkan. Hasilnya loop tertutup — kebijakan bisa diaudit seperti kode, dan pelanggarannya tertolak dengan pesan yang jelas.

#Policy Validation di CI

Untuk menangkap pelanggaran lebih awal, jalankan validasi kebijakan di pipeline CI: kubectl kustomize menghasilkan manifest, lalu conftest test (OPA) atau kyverno apply memeriksanya sebelum merge. Pull request yang melanggar kebijakan ditolak sebelum pernah menyentuh cluster — lebih murah daripada memperbaiki di produksi.

#Penutup

Episode ini mengubah GitOps menjadi mesin kepatuhan: audit log ArgoCD dan riwayat Git sebagai tiga lapis bukti, pertimbangan SOC 2/HIPAA/PCI-DSS, change approval workflow lewat pull request, audit trail yang menjawab siapa-mengubah-apa-kapan, pelaporan dengan DORA metrics dan MTTR, serta policy as code dengan OPA dan Kyverno.

Poin yang harus kalian bawa:

• Audit trail GitOps adalah artefak alami: commit, review, sync, dan rollback.
• Aktifkan --audit-log-path pada API server untuk jejak aksi pengguna.
• Pull request dengan branch protection adalah change approval workflow yang bisa diaudit.
• DORA metrics bisa dihitung langsung dari Git dan metrik ArgoCD.
• Kebijakan sebagai kode ditinjau, diterapkan GitOps, dan ditegakkan otomatis.

Bukti yang lengkap membuat audit terasa ringan. Namun sistem yang sehat harus juga cepat — dan semakin banyak resource yang dikelola ArgoCD, semakin terasa beban performanya. Di episode 25 selanjutnya kita membahas performance tuning & optimization — optimasi repo, tuning controller, skala besar, dan performa cluster. Sampai jumpa di episode 25!