Belajar OpenClaw - Multi-tenancy & Namespace Isolation

#Pendahuluan

Di episode 9 kalian sudah mengelola policy lewat GitOps — setiap perubahan terdokumentasi, divalidasi, dan bisa di-rollback. Tapi ada satu pertanyaan yang muncul begitu cluster kalian dipakai lebih dari satu team: bagaimana caranya beberapa tim berbagi satu platform OpenClaw tanpa policy milik tim A merusak service tim B? Ini masalah klasik yang disebut multi-tenancy.

Episode 10 masuk ke topik yang paling sering dijumpai di perusahaan: berbagi platform. Roadmap-nya: pertama kita pahami model multi-tenancy di OpenClaw, kedua kita terapkan namespace segmented policies dan service scoping, dan ketiga kita amankan ingress serta egress untuk tenant yang berbeda. Akhir episode, cluster kalian bisa dipakai banyak team dengan tenang.

#Model Multi-tenancy di OpenClaw

#Kenapa Tenancy Harus Direncanakan

Berbagi cluster itu menggiurkan: efisien, menghemat resource, satu tim platform yang merawat semuanya. Tapi tanpa pemisahan yang jelas, satu team bisa menolak traffic team lain, mengubah label yang dipakai policy bersama, atau bahkan melihat konfigurasi policy yang seharusnya rahasia. Multi-tenancy yang baik bukan soal teknologi saja, tapi soal batas — batas akses, batas policy, dan batas visibilitas.

OpenClaw memakai namespace Kubernetes sebagai unit tenancy utama. Setiap team mendapat namespace (atau kumpulan namespace) sebagai "rumah"-nya, dan OpenClaw memastikan policy hanya berlaku dalam lingkup yang ditentukan. Pendekatan ini disebut multi-tenancy lunak (soft multi-tenancy): namespace terpisah secara logis di atas control plane bersama.

apiVersion: openclaw.io/v1
kind: TenantConfig
metadata:
  name: billing-tenant
  namespace: billing
spec:
  namespaces:
    - billing
    - billing-worker
  serviceScoping:
    enabled: true
    scopeLabels:
      - tenant
      - service-tier
  policyIsolation: HARD
  ingressDomains:
    - billing.example.com

Perhatikan policyIsolation: HARD — ini memberitahu OpenClaw bahwa policy dari tenant lain tidak boleh menyentuh namespace ini, dan sebaliknya policy tenant ini tidak bocor ke luar. ingressDomains membatasi domain yang boleh melayani tenant ini.

#Soft vs Hard Isolation

Terdapat spektrum pemisahan tenant: soft isolation berbagi sebagian besar infrastruktur dan hanya memisahkan policy secara logis, cocok untuk internal service dengan kepercayaan tinggi; hard isolation memisahkan lebih jauh — policy, data, bahkan traffic plane — cocok untuk tenant eksternal atau lingkungan dengan aturan compliance ketat. Pilihan di antara keduanya ditentukan oleh seberapa berbahaya dampak kesalahan satu tenant terhadap tenant lain.

Soft isolation  : policy terpisah, logika bersama, cocok internal team
Hard isolation  : policy + plane terpisah, untuk tenant eksternal/compliance
Satu rule emas  : default deny lintas tenant, izinkan hanya yang eksplisit

Aturan emasnya sederhana dan penting: traffic lintas tenant harus ditolak secara default. Jika team billing butuh mengakses service team reporting, itu ditulis sebagai pengecualian eksplisit — bukan karena semua service di cluster otomatis saling melihat.

#Namespace Segmented Policies dan Service Scoping

#Policy yang Terkunci dalam Namespace

Policy yang baik di lingkungan multi-tenant adalah policy yang paham konteks. Selector policy tidak boleh hanya mencocokkan label app: billing — karena label itu bisa saja dimiliki tenant lain. Selector harus dikombinasikan dengan namespace, sehingga satu policy tidak pernah secara tidak sengaja menimpa service milik orang lain.

apiVersion: openclaw.io/v1
kind: ServicePolicy
metadata:
  name: billing-internal
  namespace: billing
spec:
  selector:
    matchNamespaces:
      - billing
      - billing-worker
    labels:
      app: billing
  rules:
    - from:
        - namespace: billing
          serviceAccount: billing-sa
      action: ALLOW
    - from:
        - any: true
      action: DENY

Perbedaan utama dari policy sebelumnya: bagian matchNamespaces membatasi scope policy hanya pada namespace yang dimiliki tenant, dan rule from mensyaratkan sumber berasal dari namespace yang sama. Policy seperti ini aman diduplikasi antar tenant karena tidak akan saling bersentuhan.

#Service Scoping untuk Isolasi Logika

Service scoping adalah kemampuan membatasi referensi policy pada service-service tertentu di dalam tenant. Ia menjawab pertanyaan "policy ini bicara soal service yang mana?" — dan jawabannya dikunci lewat label scope, bukan nama global yang bisa ambigu. Misalnya semua service di tenant diberi label tenant: billing, lalu semua policy tenant merujuk label itu.

kubectl get pods -n billing -l tenant=billing
openclawctl policy scope billing-internal --namespace billing

Command openclawctl policy scope billing-internal --namespace billing menampilkan daftar service yang benar-benar tercakup oleh policy tersebut. Ini alat debugging yang sangat berguna di cluster yang ramai: kalian bisa memastikan policy tidak lebih luas dari yang diinginkan, dan service baru yang belum diberi label tenant tidak terlibat ke dalam policy secara tidak sengaja.

#Secure Multi-tenant Ingress dan Egress

#Ingress Per Tenant

Ketika banyak team berbagi satu ingress, kalian butuh pemisahan yang jelas di pintu masuk: setiap tenant mendapat domain (atau path prefix) miliknya sendiri, dan traffic ke domain itu hanya boleh menuju service di dalam tenant tersebut. OpenClaw memungkinkan binding antara domain ingress dan namespace tenant, sehingga domain milik billing tidak bisa mengarahkan traffic ke service milik reporting.

apiVersion: openclaw.io/v1
kind: IngressPolicy
metadata:
  name: billing-ingress
  namespace: billing
spec:
  domains:
    - billing.example.com
    - api.billing.example.com
  routes:
    - pathPrefix: /api
      destination:
        service: billing-api
        port: 8080
  tls:
    mode: TERMINATE
    secretRef: billing-tls

Perhatikan tls.secretRef menunjuk ke secret billing-tls yang dimiliki tenant billing. Setiap tenant mengelola sertifikatnya sendiri — tenant A tidak perlu meminjam atau melihat secret tenant B. Pemisahan secret ini adalah bagian penting dari isolasi ingress yang sesungguhnya.

#Egress yang Diatur per Tenant

Arah keluar juga perlu dipisahkan. Tanpa kontrol, service tenant A bisa bebas memanggil endpoint eksternal mana pun, dan tenant B ikut terimbas jika tenant A membuat koneksi yang menyalahi compliance. Egress policy per tenant menetapkan domain mana yang boleh dituju dan melewati proxy egress mana.

apiVersion: openclaw.io/v1
kind: EgressPolicy
metadata:
  name: billing-egress
  namespace: billing
spec:
  enabled: true
  allowedDomains:
    - payment-gateway.example.net
    - billing-db.example.net
  denyDefault: true
  routeVia:
    egressProxy: openclaw-egress

Dengan denyDefault: true, semua koneksi keluar dari tenant billing dibatasi hanya pada dua domain yang terdaftar. Traffic keluar melewati proxy egress bersama yang memberi identitas terpadu ke luar cluster — IP sumber yang stabil untuk whitelisting di sisi penyedia eksternal.

#Penutup

Pada episode 10 ini kalian telah membuat satu cluster melayani banyak team dengan aman: memahami model tenancy berbasis namespace dengan opsi isolasi lunak atau keras, menulis policy yang tersegmentasi per namespace dengan service scoping dan prefiks label yang tidak ambigu, serta mengamankan pintu masuk dan keluar per tenant dengan domain dan egress policy milik masing-masing.

Inti yang harus dibawa pulang:

• Namespace adalah unit tenancy utama; batasi policy dengan matchNamespaces agar tidak bocor antar tenant.
• Default deny lintas tenant adalah aturan emas — izinkan hanya pengecualian eksplisit.
• Service scoping mengunci referensi policy pada service milik tenant via label berprefiks, bukan label generik.
• Ingress per tenant punya domain dan secret TLS sendiri; jangan pernah berbagi secret antar tenant.
• Egress policy dengan denyDefault: true membatasi koneksi keluar dan menstabilkan identitas keluar via egress proxy.

Di episode 11 berikutnya kita urus "aset berharga" terakhir di sisi konfigurasi: config management dan secrets — bagaimana menyimpan konfigurasi OpenClaw dengan aman, mengelola secret untuk TLS dan API keys, serta memvalidasi perubahan konfigurasi di pipeline. Sampai jumpa!