Belajar OpenClaw - Network Policy & Traffic Rules

#Pendahuluan

Selamat datang di episode 4 series Belajar OpenClaw! Di episode 3, OpenClaw sudah terinstall di cluster dan sample application berjalan. Sekarang kita masuk ke inti pekerjaan sehari-hari seorang engineer networking: menulis network policy dan traffic rules. Inilah tempat di mana kekuatan OpenClaw terasa: satu bahasa untuk mengatur siapa boleh bicara dengan siapa, request apa yang boleh lewat, dan bagaimana prioritas antar aturan diputuskan. Kita akan mulai dari anatomi policy, lalu membangun inbound, outbound, routing layer 7, dan terakhir prioritas serta matching rules. Siapkan cluster episode 3 — semua contoh di episode ini dijalankan terhadapnya.

#Anatomi Policy OpenClaw

Sebuah policy OpenClaw memiliki tiga bagian utama: selector (siapa yang diatur), match (kapan policy berlaku), dan rules (apa yang diizinkan atau dilarang). Ini contoh kerangka minimalnya:

apiVersion: openclaw.io/v1
kind: Policy
metadata:
  name: api-access
  namespace: sample
spec:
  selectors:
    - matchLabels:
        app: api
  match:
    from:
      - app: web
  rules:
    - allow:
        methods: [GET]

Selector memilih workload yang dilindungi. Match menentukan kondisi request yang dievaluasi — di sini, request yang berasal dari app: web. Rules mendeskripsikan apa yang terjadi saat kondisi terpenuhi.

#Mendefinisikan Policy Inbound

Policy inbound mengatur traffic yang masuk ke sebuah service. Contoh nyata: service api hanya boleh menerima request dari web, tidak dari service lain:

apiVersion: openclaw.io/v1
kind: Policy
metadata:
  name: api-allow-web
  namespace: sample
spec:
  selectors:
    - matchLabels:
        app: api
  match:
    from:
      - app: web
  rules:
    - allow: {}

Terapkan dan cek statusnya:

kubectl apply -f api-allow-web.yaml{:bash}
kubectl get policy api-allow-web -n sample -o yaml

Perhatikan kolom status: OpenClaw mencatat apakah policy berhasil disinkronkan ke data plane. Ini adalah loop verifikasi pertama kalian — pastikan statusnya sukses sebelum lanjut.

#Mendefinisikan Policy Outbound

Policy outbound mengatur traffic yang keluar dari sebuah service. Contoh: web hanya boleh menghubungi api dan layanan DNS, tidak boleh akses internet bebas:

apiVersion: openclaw.io/v1
kind: Policy
metadata:
  name: web-egress-controlled
  namespace: sample
spec:
  selectors:
    - matchLabels:
        app: web
  match:
    to:
      - app: api
      - dns: true
  rules:
    - allow: {}

Policy ini mempersempit "radius pergerakan" web. Konsep outbound akan kita perdalam menjadi egress management di episode 5, termasuk bagaimana mengatur akses ke layanan eksternal di luar cluster.

#Layer 7 Routing dan Request Filtering

Di layer 7, policy bisa melihat lebih dalam daripada sekadar IP dan port — metode HTTP, path, dan header semuanya tersedia untuk filtering. Contohnya, api versi lama (/v1) hanya boleh diakses dengan GET, sedangkan versi baru boleh POST:

apiVersion: openclaw.io/v1
kind: Policy
metadata:
  name: api-version-routing
  namespace: sample
spec:
  selectors:
    - matchLabels:
        app: api
  match:
    path: "/v1/**"
  rules:
    - allow:
        methods: [GET]
    - deny: {}

Perhatikan pola di atas: request /v1/** dibatasi hanya GET, sisanya ditolak. Untuk versi baru, buat policy serupa dengan match.path mengarah ke /v2/** dan methods: [GET, POST, PUT]. Header juga bisa dipakai sebagai kondisi match, misalnya memeriksa keberadaan token tertentu sebelum request diteruskan.

#Prioritas, Scope, dan Matching Rules

Saat beberapa policy cocok dengan request yang sama, urutan evaluasi ditentukan oleh prioritas. Nilai lebih kecil menang lebih dulu:

apiVersion: openclaw.io/v1
kind: Policy
metadata:
  name: deny-any-debug
  namespace: sample
spec:
  priority: 5
  match:
    path: "/debug/**"
  rules:
    - deny: {}
---
apiVersion: openclaw.io/v1
kind: Policy
metadata:
  name: allow-api-default
  namespace: sample
spec:
  priority: 100
  match:
    from:
      - app: web
  rules:
    - allow: {}

Policy deny-any-debug dengan prioritas 5 dievaluasi lebih dulu dari allow-api-default (prioritas 100). Jadi walau web secara default diizinkan, request ke /debug/** tetap ditolak. Inilah pola deny yang kuat tapi spesifik di atas allow yang luas.

Scope membatasi jangkauan policy: per namespace, per cluster, atau global. Policy yang discope ke namespace hanya berlaku di namespace tersebut, sementara policy global mengatur semua workload:

apiVersion: openclaw.io/v1
kind: ClusterPolicy
metadata:
  name: require-mtls-global
spec:
  scope: cluster
  match: {}
  rules:
    - require:
        mTLS: true

Matching rules menggabungkan selector, from, to, path, metode, dan header menjadi satu ekspresi. Aturan emasnya: gunakan match yang paling spesifik untuk policy deny, dan match yang paling umum untuk policy allow. Pola ini menjaga deny tidak bocor ke workload lain dan allow tidak menciptakan lubang keamanan.

#Penutup

Di episode 4 ini kalian sudah menulis network policy inbound dan outbound, memanfaatkan routing layer 7 dan request filtering berbasis path dan metode, serta memahami bagaimana prioritas, scope, dan matching rules bekerja sama menentukan keputusan.

Inti yang harus dibawa pulang:

• Anatomi policy: selector memilih workload, match menentukan kondisi, rules menentukan keputusan.
• Policy inbound melindungi service yang dilalui traffic; outbound mempersempit jangkauan service.
• Layer 7 memungkinkan filtering berbasis path, metode, dan header — bukan sekadar IP dan port.
• Prioritas kecil dievaluasi lebih dulu: pakai deny spesifik berprioritas tinggi di atas allow luas.
• Scope menentukan jangkauan: namespace, cluster, atau global.

Di episode 5 selanjutnya kita akan membahas ingress dan egress management: konfigurasi ingress traffic dan TLS termination, kontrol egress ke service eksternal, serta gateway dan route policy untuk mesh entry dan exit points. Persimpangan north-south dan east-west akan kalian kuasai di sana.