Belajar OpenClaw - Advanced Policy Authoring

#Pendahuluan

Di episode 7 kalian sudah bisa melihat semuanya: deny rate, traffic flows, dan anomali yang muncul di dashboard. Sekarang bayangkan kalian punya tiga belas service yang masing-masing butuh policy serupa, dan kalian menulis policy yang sama berulang-ulang dengan sedikit perbedaan nama. Hasilnya? File YAML yang gemuk, inkonsisten, dan sakit kepala saat review. Inilah masalah yang dipecahkan oleh advanced policy authoring.

Kita masuk Fase 3: workloads, configuration, dan data management. Episode ini roadmap-nya tiga hal: menulis reusable policy templates agar policy bisa dibagi; memahami parameterized rules dan policy inheritance agar satu template melayani banyak kasus; serta memakai conditionals dan service labels dalam rule untuk logika yang dinamis. Akhir episode kalian akan menulis policy yang jauh lebih kecil tapi jauh lebih kuat.

#Reusable Policy Templates

#Masalah Duplikasi Policy

Setiap team biasanya butuh pola policy yang mirip: default deny, izinkan akses dari frontend ke backend tertentu, blokir path admin untuk user biasa. Kalau setiap orang menyalin-tempel blok YAML, lambat laun muncul drift — satu policy diubah di satu tempat tapi tidak di tempat lain, dan perilaku keamanan jadi tidak konsisten. Template menyelesaikan ini dengan satu sumber kebenaran.

Template di OpenClaw adalah kerangka policy yang mendefinisikan struktur dan aturan dasar, tetapi bagian-bagian tertentu dibiarkan kosong untuk diisi oleh pemakainya. Kalian mendefinisikan template sekali, lalu instance policy cukup merujuk template itu dan mengisi parameter.

apiVersion: openclaw.io/v1
kind: PolicyTemplate
metadata:
  name: backend-access
  namespace: openclaw-templates
spec:
  parameterSchema:
    - name: namespace
      required: true
    - name: service
      required: true
    - name: allowedClients
      type: array
      default: ["frontend-sa"]
  template: |
    apiVersion: openclaw.io/v1
    kind: ServicePolicy
    metadata:
      name: {{.service}}-access
      namespace: {{.namespace}}
    spec:
      selector:
        labels:
          app: {{.service}}
      rules:
        - from:
            - serviceAccount: {{.allowedClients}}
          action: ALLOW
        - from:
            - any: true
          action: DENY

Perhatikan bagian parameterSchema: ia mendeklarasikan parameter apa saja yang wajib dan opsional beserta default-nya. Bagian template berisi kerangka policy yang sebenarnya, dengan placeholder nama-nama parameter. Dengan begitu, aturan default deny otomatis ikut terpakai di semua instance tanpa harus ditulis ulang. Command openclawctl policy validate conditional-access --namespace payments adalah contoh validasi policy yang memakai label dari selector.

#Mengonsumsi Template

Memakai template jauh lebih ringkas daripada menulis policy dari nol. Kalian cukup menyebut template yang dipakai dan mengisi parameter. OpenClaw akan me-render instance policy dari template tersebut saat diterapkan.

apiVersion: openclaw.io/v1
kind: ServicePolicy
metadata:
  name: billing-access
  namespace: billing
spec:
  templateRef:
    name: backend-access
    namespace: openclaw-templates
  parameters:
    service: billing
    allowedClients: ["order-sa", "inventory-sa"]

#Parameterized Rules dan Policy Inheritance

#Parameter sebagai Konfigurasi Tunggal

Parameterized rules berarti logika di dalam rule tidak lagi ditulis keras di dalam YAML, melainkan mengambil nilai dari parameter. Nilai ini bisa datang dari instance policy, atau diwarisi dari template induk. Keuntungannya jelas: kalian mengubah perilaku banyak policy hanya dengan mengubah satu nilai parameter, bukan mengedit satu per satu.

Inheritance bekerja dari arah template menuju instance. Template mendefinisikan nilai default, dan instance boleh meng-override sebagian atau semua parameter. Ini pola yang sama seperti variable inheritance di bahasa pemrograman — default di induk, override di anak.

apiVersion: openclaw.io/v1
kind: PolicyTemplate
metadata:
  name: tiered-access
spec:
  parameterSchema:
    - name: method
      default: GET
    - name: rateLimit
      default: "100rps"
    - name: enforceMfa
      type: bool
      default: true
  template: |
    apiVersion: openclaw.io/v1
    kind: ServicePolicy
    spec:
      rules:
        - methods: ["{{.method}}"]
          rateLimit: {{.rateLimit}}
          mfaRequired: {{.enforceMfa}}

Instance yang memakai template ini bisa membiarkan method memakai default GET, atau meng-override-nya menjadi POST hanya untuk kasus tertentu. Nilai enforceMfa bisa dimatikan untuk internal service tapi diaktifkan untuk API publik — semua tanpa mengubah template.

#Hirarki dan Urutan Evaluasi

Saat inheritance bertingkat, kalian perlu tahu urutan prioritas: nilai yang paling spesifik menang. Instance policy mengalahkan template tingkat pertama, dan template tingkat pertama mengalahkan template default global. Prinsip ini berlaku juga pada aturan di dalam satu policy — rule yang lebih spesifik dievaluasi sebelum rule yang lebih umum, dan rule DENY selalu menang atas ALLOW jika keduanya cocok.

1. Parameter instance policy (paling spesifik)
2. Parameter template anak
3. Parameter template induk / default
4. Rule DENY lebih diutamakan daripada ALLOW
5. Rule spesifik dievaluasi lebih dulu dari rule umum

Urutan ini menjawab pertanyaan klasik "kenapa request saya ditolak padahal ada rule ALLOW?" — jawabannya hampir selalu: ada rule DENY yang lebih spesifik atau lebih diprioritaskan yang cocok lebih dulu.

#Conditionals dan Service Labels dalam Rule

#Logika Kondisional

Kadang izin bergantung pada kondisi yang tidak bisa diwakili daftar statis. OpenClaw menyediakan ekspresi kondisional dalam rule — perbandingan, logika AND dan OR, serta pemeriksaan keberadaan label. Ini memungkinkan rule yang adaptif: misalnya, path /internal hanya boleh diakses pada jam kerja, atau service di namespace staging boleh bicara bebas sedangkan production dibatasi.

apiVersion: openclaw.io/v1
kind: ServicePolicy
metadata:
  name: conditional-access
  namespace: payments
spec:
  selector:
    labels:
      app: settlement
  rules:
    - condition:
        anyOf:
          - { source.namespace: "frontend", time.hour: { gte: 8, lte: 18 } }
          - { source.labels.env: "internal-tooling" }
      action: ALLOW
    - from:
        - any: true
      action: DENY

Perhatikan ekspresi di atas: akses diizinkan jika sumbernya dari namespace frontend dan waktu berada di antara jam 8 hingga 18, ATAU jika sumber membawa label env: internal-tooling. Ini bukan sekadar allow list statis — ini keputusan yang dievaluasi per request berdasarkan konteks saat itu.

#Memanfaatkan Service Labels

Service labels adalah metadata yang melekat pada workload, dan di OpenClaw label menjadi salah satu bahan utama matching rule. Alih-alih menulis satu policy untuk tiap service, kalian bisa menulis satu policy yang mencocokkan sekelompok service berdasarkan label yang sama. Hasilnya, service baru cukup diberi label yang tepat dan otomatis tercakup oleh policy yang ada.

kubectl label deployment settlement payments-tier=high-risk
openclawctl policy validate conditional-access --namespace payments

Command pertama menambahkan label payments-tier: high-risk ke deployment settlement. Command kedua memvalidasi policy terhadap kondisi label saat ini. Dengan pola ini, onboarding service baru tidak lagi berarti menulis policy baru — cukup beri label yang tepat, dan policy berbasis label langsung berlaku.

#Penutup

Pada episode 8 ini kalian telah mengubah cara menulis policy: dari menyalin-tempel YAML menjadi membangun template yang bisa dipakai ulang, dari nilai keras menjadi parameterized rules dengan inheritance, dan dari daftar statis menjadi rule kondisional yang memanfaatkan label service. Policy kalian kini lebih pendek, lebih konsisten, dan lebih mudah di-review.

Inti yang harus dibawa pulang:

• Template menghilangkan duplikasi dan drift; simpan di namespace khusus dengan kontrol akses ketat.
• Parameterized rules memisahkan logika dari konfigurasi sehingga satu template melayani banyak kasus.
• Inheritance memakai prinsip "yang paling spesifik menang"; instance meng-override default template.
• Rule DENY selalu menang atas ALLOW; urutan evaluasi rule spesifik dulu, umum belakangan.
• Conditionals dan service labels membuat policy adaptif — service baru cukup diberi label yang tepat.

Di episode 9 berikutnya kita akan membuat policy kalian hidup: dynamic policy updates. Kalian akan menerapkan perubahan policy tanpa downtime, memvalidasi dan melakukan rollback dengan aman, serta mengelola siklus hidup policy melalui GitOps. Sampai jumpa!