Belajar OpenClaw - Config Management & Secrets

#Pendahuluan

Di episode 10 kalian sudah berhasil memisahkan tenant dengan namespace, scoping, dan ingress/egress per tenant. Tapi semua pemisahan itu bergantung pada satu aset yang paling mahal: konfigurasi — termasuk secret di dalamnya. Sertifikat TLS, API keys, dan konfigurasi policy tersimpan di dalam cluster, dan kalau pengelolaannya sembrono, seluruh pagar keamanan yang kalian bangun tinggal hiasan.

Episode 11 menutup Fase 3. Roadmap-nya tiga hal: menyimpan konfigurasi OpenClaw secara aman, mengelola secret untuk TLS dan API keys dengan siklus hidup yang benar, dan memvalidasi perubahan konfigurasi di pipeline sebelum menyentuh produksi. Ini episode yang paling "administratif", tapi justru di sinilah insiden keamanan paling sering terjadi.

#Menyimpan Konfigurasi OpenClaw dengan Aman

#Jenis-jenis Konfigurasi

Konfigurasi OpenClaw bisa dikelompokkan menjadi tiga berdasarkan tingkat kerahasiaannya. Konfigurasi publik seperti MeshConfig dan ServicePolicy aman di git — malah harus di git agar bisa di-review. Konfigurasi semi-rahasia seperti credential database sebaiknya masuk secret store. Dan konfigurasi yang sangat rahasia — CA keys, token admin, kunci signing — hanya boleh ada di sistem rahasia khusus.

apiVersion: openclaw.io/v1
kind: CARotationConfig
metadata:
  name: mesh-ca
  namespace: openclaw
spec:
  signingKeys:
    keyRef:
      secretName: openclaw-ca-key
      secretKey: ca.key
  rotation: 90d
  intermediateLifetime: 24h
  rootLifetime: 1y

Perhatikan pola di atas: bagian paling rahasia (kunci signing) tidak ditulis langsung di konfigurasi — ia dirujuk lewat keyRef menuju sebuah Secret. Inilah prinsip pertama pengelolaan konfigurasi yang aman: pisahkan secret dari konfigurasi, dan konfigurasi cukup menyimpan referensi.

#Menghindari Secret dalam Git

Kesalahan yang paling sering dan paling mahal adalah commit secret ke repository — entah karena terburu-buru, file env terlanjur ter-add, atau contoh konfigurasi yang tidak dibersihkan. Setelah secret masuk git history, ia dianggap bocor selamanya, dan satu-satunya perbaikan yang benar adalah rotasi, bukan penghapusan commit.

git log --all --oneline -S "BEGIN PRIVATE KEY"
git log --all --oneline -S "api_key="

Dua perintah di atas memindai seluruh riwayat commit untuk baris yang mengandung materi kunci privat atau kata kunci credential. Jalankan secara berkala di repo konfigurasi kalian. Jika ada hasil, itu alarm — segera rotasi nilai yang bocor dan pasang tool scanning seperti gitleaks atau trufflehog di pipeline.

#Mengelola Secrets untuk TLS dan API Keys

#Secret Store dan Referensi Eksternal

Di lingkungan produksi, Secret Kubernetes biasa tidak cukup: isinya tersimpan base64 (bukan terenkripsi), dan siapa pun yang bisa membaca namespace bisa membacanya. Solusi yang dianjurkan adalah secret store eksternal seperti Vault atau cloud secret manager, dengan controller seperti External Secrets Operator yang menarik nilai secret ke dalam Secret Kubernetes hanya saat dibutuhkan.

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: billing-tls
  namespace: billing
spec:
  secretStoreRef:
    name: vault-secret-store
    kind: SecretStore
  target:
    name: billing-tls
  data:
    - secretKey: tls.crt
      remoteRef:
        key: billing/tls
        property: cert
    - secretKey: tls.key
      remoteRef:
        key: billing/tls
        property: key

Policy ingress di episode 10 mereferensikan secret bernama billing-tls. Secret itu sekarang tidak lagi dibuat manual oleh manusia — ia disediakan External Secrets Operator dari Vault. Kalau admin menghapus entry di Vault, controller menyinkronkan penghapusan itu ke cluster. Secret punya satu sumber kebenaran.

#Rotasi Terjadwal

Secret bukan benda statis — ia punya masa hidup. Sertifikat TLS kedaluwarsa, API keys bisa bocor, dan best practice memaksa rotasi berkala. Kunci rotasi yang sukses adalah otomatisasi: jangan pernah menunggu manusia mengingat jadwal rotasi. Atur peringatan sebelum kedaluwarsa dan otomatisasi penerbitan ulang.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: billing-cert
  namespace: billing
spec:
  secretName: billing-tls
  issuerRef:
    name: openclaw-ca-issuer
    kind: ClusterIssuer
  dnsNames:
    - billing.example.com
  renewBefore: 30d

Dengan cert-manager dan issuer dari OpenClaw CA, sertifikat diterbitkan otomatis, diperbarui 30 hari sebelum kedaluwarsa, dan ditulis ke secret yang sama yang dipakai ingress policy. Tidak ada manusia yang perlu menyentuh secret. Untuk API keys, pasang peringatan kedaluwarsa di monitoring dan rotasi otomatis lewat script yang menjalankan pipeline penerbitan ulang.

#Memvalidasi Perubahan Konfigurasi di Pipeline

#Validasi Statis dan Kepatuhan Skema

Perubahan konfigurasi paling murah diperbaiki sebelum masuk cluster. Pipeline CI bisa menangkap dua kelas masalah: masalah sintaks (skema salah, field tidak dikenal) dan masalah logika (policy menunjuk service yang tidak ada, referensi secret yang tidak terdefinisi). Keduanya dicek tanpa perlu cluster berjalan.

openclawctl config validate --path config/openclaw
openclawctl policy validate --all --strict

Perintah openclawctl config validate --path config/openclaw memeriksa skema dan referensi di seluruh folder konfigurasi, sedangkan openclawctl policy validate --all --strict menandakan kegagalan validasi sebagai error keras, bukan sekadar peringatan. Dalam pipeline, gagalkan build jika ada output error — jangan biarkan konfigurasi cacat mengalir ke Argo CD.

#Secret Scanning di Pipeline

Validasi tidak lengkap tanpa scanning secret. Tool seperti gitleaks berjalan di tiap commit dan pull request, mencari pola credential sebelum kode masuk branch utama. Jika ditemukan, pipeline dihentikan — dan lebih baik lagi, dihubungkan ke sistem rotasi otomatis untuk kasus di mana materi bocor.

name: secret-scan
on:
  pull_request:
  push:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scan secrets
        run: |
          curl -sSfL https://raw.githubusercontent.com/gitleaks/gitleaks/master/gitleaks.sh | bash
          gitleaks detect --redact --verbose

YAML pipeline di atas menjalankan gitleaks pada setiap pull request dan setiap push ke main. Hasil detect yang menemukan kecocokan akan mengembalikan exit code non-nol sehingga workflow gagal dan mencegah merge. Ini lapisan terakhir sebelum konfigurasi yang mengandung secret melesat ke produksi.

#Penutup

Pada episode 11 ini kalian telah menyelesaikan Fase 3: menyimpan konfigurasi dengan memisahkan secret dari file konfigurasi, mengelola secret TLS dan API keys lewat secret store eksternal dengan rotasi terjadwal, serta menutup gerbang pipeline dengan validasi konfigurasi, strict policy validation, dan secret scanning otomatis.

Inti yang harus dibawa pulang:

• Pisahkan secret dari konfigurasi — konfigurasi hanya menyimpan referensi, bukan nilai.
• Secret yang pernah masuk git dianggap bocor selamanya; perbaikan satu-satunya adalah rotasi.
• Gunakan secret store eksternal (Vault) dengan External Secrets Operator sebagai satu sumber kebenaran.
• Rotasi harus otomatis dan terjadwal; buat yang baru, verifikasi, baru matikan yang lama.
• Pipeline wajib memvalidasi skema, menjalankan strict policy validation, dan memindai secret di tiap pull request.

Dengan Fase 3 selesai, di episode 12 berikutnya kita masuk Fase 4 — networking and security: secure service mesh integration. Kalian akan mengintegrasikan OpenClaw dengan Istio, Linkerd, dan Cilium, serta menegakkan policy melintasi batas mesh. Sampai jumpa!