Belajar OpenClaw - Security Policy Enforcement

#Pendahuluan

Di episode 5 sebelumnya kalian sudah menguasai ingress dan egress management — bagaimana mengatur traffic yang masuk ke cluster, melakukan TLS termination, serta mengontrol akses keluar menuju service eksternal. Traffic sudah mengalir dengan rapi, tapi ada satu pertanyaan yang belum terjawab: siapa yang boleh bicara dengan siapa, dan bagaimana kita membuktikannya? Episode inilah jawabannya.

Kita akan masuk ke ranah keamanan: mengaktifkan authentication, authorization, dan mTLS untuk identitas service; menegakkan policy pada komunikasi service-to-service; serta membangun audit logging dan policy change tracking. Roadmap episode ini: pertama kita pahami identitas service di OpenClaw, lalu kita terapkan mTLS, selanjutnya menulis policy enforcement untuk komunikasi antar service, dan terakhir menyiapkan audit trail yang bisa diandalkan.

#Identitas Service sebagai Fondasi Keamanan

#Mengapa Identitas Itu Penting

Di dunia cloud native, IP address bersifat sementara dan tidak bisa dipercaya — pod dibuat, dihapus, dan dipindah dalam hitungan detik. Karena itu keamanan service-to-service tidak bisa bergantung pada IP. Solusinya adalah identitas: setiap service mendapatkan sebuah identitas kriptografis yang terikat pada workload, bukan pada jaringan. Identitas inilah yang menjadi dasar authentication dan mTLS di OpenClaw.

Setiap workload diberi identitas unik berupa SPIFFE ID — format URI standar untuk identitas workload. Bentuknya mirip spiffe://cluster.local/ns/billing/sa/payment-service. Identitas ini diterbitkan oleh control plane OpenClaw dan dirotasi otomatis sebelum masa berlakunya habis, sehingga kalian tidak perlu menangani rotasi sertifikat secara manual.

apiVersion: openclaw.io/v1
kind: ServiceIdentity
metadata:
  name: payment-service-id
  namespace: billing
spec:
  workloadSelector:
    labels:
      app: payment-service
  trustDomain: cluster.local
  spiffePath: /ns/billing/sa/payment-service

#Authentication vs Authorization

Penting untuk membedakan dua konsep yang sering tertukar. Authentication menjawab pertanyaan "kamu siapa?" — memverifikasi identitas melalui sertifikat atau token. Authorization menjawab "apa yang boleh kamu lakukan?" — menentukan izin berdasarkan identitas yang sudah terverifikasi. Di OpenClaw, authentication dilakukan lewat handshake mTLS, sedangkan authorization diimplementasikan sebagai policy yang dievaluasi oleh policy engine.

Urutannya tidak bisa dibalik: tanpa authentication yang kuat, authorization hanya tebak-tebakan. Karena itu urutan yang benar adalah mTLS dulu sebagai lapisan kepercayaan, baru policy authorization di atasnya sebagai lapisan kontrol.

#Mengaktifkan mTLS untuk Service-to-Service

#Konsep Mutual TLS

TLS biasa hanya memverifikasi satu arah: klien memverifikasi identitas server. mTLS (mutual TLS) memverifikasi dua arah — server juga memverifikasi identitas klien melalui sertifikat yang dimiliki klien. Hasilnya, kedua belah pihak yakin bahwa mereka berkomunikasi dengan entitas yang sah, dan semua data yang mengalir di antara keduanya terenkripsi.

Untuk mengaktifkan mTLS di OpenClaw, kalian cukup mendeklarasikan mode mTLS pada namespace atau mesh. OpenClaw akan otomatis menginject sidecar yang menangani handshake sertifikat untuk setiap pod yang cocok dengan selector-nya. Kalian tidak perlu menyentuh kode aplikasi sama sekali.

apiVersion: openclaw.io/v1
kind: MeshConfig
metadata:
  name: mesh-mtls
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
  fipsCompliant: true
  certRotation: 24h

#Mode mTLS: Permissive vs Strict

Mode STRICT berarti seluruh traffic dalam namespace wajib menggunakan mTLS — jika ada klien tanpa sertifikat valid, koneksi ditolak. Mode PERMISSIVE lebih lunak: mTLS dipakai bila memungkinkan, tapi traffic plaintext masih diterima. Saat migrasi bertahap, kalian bisa mulai dari PERMISSIVE, mengamati log, lalu beralih ke STRICT ketika semua workload sudah siap.

openclawctl mesh get --namespace billing
openclawctl mesh mtls status --namespace billing

Output dari openclawctl mesh mtls status --namespace billing akan menunjukkan persentase workload yang sudah memakai mTLS. Ini metrik penting saat proses hardening: kalian tidak mau berpindah ke STRICT sebelum angkanya 100 persen, karena itu artinya ada traffic yang akan mati.

#Policy Enforcement untuk Komunikasi Antar Service

#Policy Berbasis Identitas, Bukan IP

Sekarang identitas sudah ada, saatnya memanfaatkannya. Policy service-to-service di OpenClaw ditulis berbasis identitas: kalian mendefinisikan siapa klien yang boleh (dalam bentuk service account atau label) mengakses sebuah service, dan dengan action apa. Policy ini menggantikan network policy berbasis IP yang rapuh terhadap perubahan topologi.

apiVersion: openclaw.io/v1
kind: ServicePolicy
metadata:
  name: payment-access-policy
  namespace: billing
spec:
  selector:
    labels:
      app: payment-service
  rules:
    - from:
        - serviceAccount: order-sa
      to:
        - paths: ["/api/v1/charge"]
          methods: ["POST"]
      action: ALLOW
    - from:
        - any: true
      action: DENY

Perhatikan struktur policy di atas: ada bagian from yang mendefinisikan sumber traffic, to yang membatasi path dan method, serta action yang menentukan hasilnya. Baris terakhir adalah default deny — tidak ada yang diizinkan kecuali secara eksplisit dibolehkan. Prinsip default deny ini adalah pola keamanan yang paling aman dan paling sering dipakai di produksi.

#Zero Trust di Level Jaringan

Policy service-to-service ini adalah perwujudan zero trust: tidak ada workload yang dipercaya secara implisit hanya karena berada di cluster yang sama. Setiap request harus memenuhi tiga syarat sekaligus — identitas terverifikasi lewat mTLS, sumber diizinkan oleh policy, dan target path sesuai ketentuan. Kalau salah satu gagal, request ditolak dan dicatat.

kubectl exec -n orders deploy/order-service -- \
  curl -s -o /dev/null -w "%{http_code}" \
  -X POST http://payment-service.billing:8080/api/v1/charge

Jalankan command di atas dari pod order-service, lalu coba juga dari service lain yang tidak diizinkan. Bandingkan hasilnya: dari order-service seharusnya kalian mendapat kode sukses, sedangkan dari service tak diizinkan akan ditolak dengan kode 403 atau 503. Itulah policy enforcement bekerja.

#Audit Logging dan Policy Change Tracking

#Menyalakan Audit Trail

Keamanan tanpa jejak bukanlah keamanan — karena kalian tidak bisa membuktikan apa yang terjadi saat investigasi insiden atau audit compliance. OpenClaw mencatat dua jenis peristiwa penting: peristiwa policy (siapa menolak/mengizinkan apa) dan peristiwa konfigurasi (siapa mengubah policy kapan). Keduanya bisa disalurkan ke aggregator log eksternal.

apiVersion: openclaw.io/v1
kind: AuditConfig
metadata:
  name: cluster-audit
spec:
  sinks:
    - type: webhook
      url: https://audit-collector.internal/ingest
  include:
    - POLICY_EVENTS
    - AUTH_EVENTS
    - CONFIG_CHANGE
  retentionDays: 90

#Melacak Perubahan Policy

Policy change tracking bukan sekadar mencatat log, melainkan menyediakan riwayat yang bisa dijawab: apa yang berubah, siapa yang mengubah, dan kapan. OpenClaw menyimpan versi setiap policy, lengkap dengan metadata perubahan. Kalian bisa melihat perbandingan antar versi untuk menelusuri asal-usul sebuah perilaku.

openclawctl policy history payment-access-policy --namespace billing
openclawctl policy diff payment-access-policy@3 payment-access-policy@4

Command openclawctl policy diff payment-access-policy@3 payment-access-policy@4 di atas menampilkan perubahan spesifik antara versi 3 dan 4 dari policy yang sama. Ini sangat berguna saat incident response: kalian bisa langsung tahu policy mana yang berubah menjelang insiden, dan siapa yang memicunya. Kombinasikan dengan webhook audit di atas, maka kalian punya jejak keamanan yang lengkap untuk laporan compliance.

#Penutup

Pada episode 6 ini kalian telah menutup celah keamanan terbesar di lingkungan cloud native: identitas yang hilang. Kalian belajar bahwa identitas berbasis SPIFFE ID adalah fondasi authentication, lalu menerapkan mTLS dengan mode PERMISSIVE hingga STRICT, menulis policy service-to-service dengan prinsip default deny, dan membangun audit trail yang melacak peristiwa policy maupun perubahan konfigurasi.

Inti yang harus dibawa pulang:

• IP address tidak bisa dipercaya sebagai identitas; gunakan SPIFFE ID dari control plane OpenClaw.
• Authentication (mTLS) harus berjalan sebelum authorization (policy), dan keduanya wajib untuk service-to-service.
• Mode STRICT memaksa semua traffic memakai mTLS — migrasi bertahap lewat PERMISSIVE agar tidak ada traffic yang putus.
• Policy enforcement berbasis identitas dengan default deny lebih aman daripada allow list berbasis IP.
• Audit logging dan policy change tracking adalah bukti untuk investigasi insiden sekaligus compliance.

Di episode 7 selanjutnya kita akan melihat sisi "mata" dari OpenClaw — observability essentials. Kalian akan mempelajari metrics dan logs OpenClaw, mengintegrasikannya dengan Prometheus dan Grafana, serta memvisualisasikan policy hits dan traffic flows. Sampai jumpa!