Belajar OpenClaw - Dynamic Policy Updates

#Pendahuluan

Di episode 8 kalian sudah menulis policy yang ringkas dan kuat dengan template, parameter, dan conditionals. Tapi policy itu tidak hidup di ruang hampa — ia dijalankan oleh service produksi yang melayani request nyata. Dan begitu service itu produksi, satu pertanyaan muncul lebih menakutkan daripada penulisan policy itu sendiri: bagaimana cara mengubah policy tanpa mematikan layanan?

Episode 9 menjawabnya. Roadmap-nya: pertama teknik menerapkan perubahan policy tanpa downtime, kedua strategi validasi dan rollback yang membuat perubahan itu reversibel dan aman, dan ketiga mengelola siklus hidup policy dalam GitOps sehingga setiap perubahan tercatat, di-review, dan bisa dilacak. Di akhir episode, perubahan policy akan terasa seperti deploy biasa — tenang dan terkontrol.

#Menerapkan Perubahan Policy Tanpa Downtime

#Kenapa Policy Berubah Itu Berisiko

Mengubah policy adalah tindakan berdampak tinggi: satu kesalahan konfigurasi bisa membuat semua service tidak bisa saling bicara, dan yang menakutkan, efeknya sering baru terasa setelah ribuan request ditolak. Karena itu perubahan policy tidak boleh dilakukan seperti "edit file lalu apply langsung" di cluster produksi. Ia butuh mekanisme yang memungkinkan perubahan disebar tanpa memutus koneksi yang sedang berjalan.

#Penerapan Bertahap dengan Shadow Mode

Kunci menghindari downtime adalah shadow mode: policy baru dievaluasi dalam bayangan, hasilnya dicatat, tapi keputusan nyata tetap diambil policy lama. Dengan cara ini kalian bisa melihat apa yang AKAN dilakukan policy baru tanpa mengeksekusinya. Jika hasilnya wajar — deny rate rendah, tidak ada source yang tiba-tiba diblokir — barulah policy baru dipromosikan aktif.

apiVersion: openclaw.io/v1
kind: ServicePolicy
metadata:
  name: billing-access-v2
  namespace: billing
spec:
  selector:
    labels:
      app: billing
  mode: SHADOW
  rules:
    - from:
        - serviceAccount: order-sa
      action: ALLOW
    - from:
        - serviceAccount: inventory-sa
      action: DENY
    - from:
        - any: true
      action: DENY

Perhatikan mode: SHADOW pada policy di atas. Policy tetap dievaluasi, hasilnya masuk ke metrik openclaw_policy_shadow_deny_total, tapi traffic aktual tidak terpengaruh. Setelah masa observasi, kalian cukup mengganti mode menjadi ENFORCE.

openclawctl policy shadow-report billing-access-v2 --namespace billing
openclawctl policy promote billing-access-v2 --namespace billing

Perintah shadow-report menampilkan berapa banyak request yang AKAN ditolak jika policy dipromosikan. Jika angkanya masuk akal, promote mengubah mode menjadi ENFORCE tanpa perlu mengedit file — dan tanpa downtime.

#Validasi dan Rollback

#Membekukan Konfigurasi dengan Versioning

Setiap perubahan policy di OpenClaw di-versioning otomatis. Ini artinya kalian selalu tahu versi mana yang sedang aktif dan bisa kembali ke versi sebelumnya dengan satu perintah. Versioning adalah jaring pengaman terakhir saat terjadi kesalahan — secepat apa pun shadow mode bekerja, ada kalanya anomali baru terdeteksi setelah policy aktif.

openclawctl policy history billing-access --namespace billing
openclawctl policy rollback billing-access --to-version 12 --namespace billing

Command rollback mengembalikan policy ke versi 12 dan menjadikannya versi aktif baru. Penting untuk dipahami: rollback tidak menghapus versi terbaru — ia membuat versi baru yang isinya salinan versi 12. Riwayat tetap utuh, dan jejak audit tetap lengkap. Kalian bisa maju lagi jika ternyata rollback itu keliru.

#Uji Kering Sebelum Terjun

Selain shadow mode, ada dry-run validation: memvalidasi perubahan policy terhadap snapshot traffic nyata atau daftar scenario uji, tanpa menerapkan apa pun. Ini seperti unit test untuk policy — cepat, murah, dan bisa dijalankan kapan saja, termasuk di pipeline CI.

apiVersion: openclaw.io/v1
kind: PolicyValidation
metadata:
  name: billing-dryrun
  namespace: billing
spec:
  testCases:
    - name: order-to-charge-allowed
      source: order-sa
      target: billing
      path: /api/v1/charge
      expect: ALLOW
    - name: public-denied
      source: anonymous
      target: billing
      path: /api/v1/charge
      expect: DENY

#Mengelola Policy Lifecycle dalam GitOps

#Policy sebagai Kode

Policy di OpenClaw pada dasarnya adalah file YAML — dan file YAML sebaiknya hidup di git, bukan di clipboard dan terminal. GitOps mengubah alur kerja: kalian tidak lagi mengetik kubectl apply -f policy.yaml sembarangan, melainkan membuat pull request, menjalankan pipeline validasi, dan membiarkan controller di cluster menarik perubahan dari repo. Setiap perubahan terekam, siapa pun bisa review, dan semuanya bisa dilacak balik ke commit.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: openclaw-policies
  namespace: argocd
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: openclaw-policies
  source:
    repoURL: https://github.com/org/cloud-policies
    path: policies/billing
    targetRevision: main
  syncPolicy:
    automated:
      selfHeal: true

Dengan Argo CD (atau Flux) yang mengawasi folder policies/billing, setiap perubahan yang masuk ke branch main otomatis disinkronkan ke cluster. Policy yang didefinisikan sebagai ServicePolicy di repo akan diciptakan, diperbarui, atau dihapus oleh controller — tanpa manusia menyentuh cluster.

#Pipeline Review dan Promotion

Siklus hidup policy yang sehat melewati beberapa tahap sebelum sampai ke produksi. Mulai dari developer membuat branch, pipeline menjalankan dry-run dan validation test, review oleh rekan, merge ke main, lalu di-sync ke staging dulu untuk observasi shadow, dan baru dipromosikan ke produksi. Setiap tahap meninggalkan jejak di git.

# Di pipeline CI: validasi sebelum merge
openclawctl policy validate --path policies/billing
 
# Di Argo CD: sync otomatis setelah merge
kubectl get policy openclaw-policies -n argocd
 
# Monitoring deny rate setelah sync
openclawctl telemetry policy-deny --namespace billing --since 10m

#Penutup

Pada episode 9 ini kalian telah membuat perubahan policy menjadi aktivitas yang tenang dan terkontrol: menyebar perubahan dengan shadow mode agar tidak ada request yang patah, mengamankan diri dengan validasi dry-run dan rollback ber-versioning, serta menempatkan seluruh siklus hidup policy di bawah GitOps dengan review, promotion, dan self-healing dari Argo CD.

Inti yang harus dibawa pulang:

• Shadow mode memungkinkan evaluasi policy baru tanpa memengaruhi traffic nyata — gunakan sebelum enforce.
• Versioning menjamin setiap perubahan bisa di-rollback; rollback menciptakan versi baru, bukan menghapus sejarah.
• Validasi tiga lapis: dry-run di CI, shadow di staging, rollback di produksi.
• Policy adalah kode — hidupkan di git dan biarkan controller (Argo CD/Flux) yang menerapkannya.
• Jangan pernah mengubah policy manual di cluster; drift dengan repo adalah musuh GitOps.

Di episode 10 selanjutnya kita bahas multi-tenancy dan namespace isolation — bagaimana berbagi platform OpenClaw dengan banyak team tanpa membuat policy mereka saling mengganggu. Sampai jumpa!