Belajar Istio - Multi-tenancy, Namespace Isolation & RBAC

#Pendahuluan

Tidak semua mesin dipakai satu tim. Saat banyak tim, produk, atau bahkan klien berbagi satu mesh, kalian butuh isolasi — tanpa itu, satu VirtualService yang salah bisa mengganggu traffic tenant lain. Episode 12 ini membahas cara memisahkan tenant dengan aman menggunakan namespace, Sidecar CRD, dan AuthorizationPolicy.

#Pola Multi-tenant Mesh

#Namespace sebagai Batas Tenant

Pola paling sederhana: satu tenant satu namespace. Setiap tenant mendapat namespace, label injection, dan aturan yang jelas tanpa saling mengganggu:

kubectl create ns tenant-a
kubectl create ns tenant-b
kubectl label ns tenant-a istio.io/rev=1-22-1

Label revisi per tenant memungkinkan kalian memindahkan satu tenant ke versi Istio baru tanpa menyentuh tenant lain — isolasi untuk proses upgrade yang kita bahas di episode 3.

#Batasan yang Perlu Diperhatikan

Namespace memberikan isolasi Kubernetes dasar, tetapi tidak otomatis mengisolasi mesh. Secara default, VirtualService masih bisa merujuk host lintas namespace (dengan format service.namespace.svc.cluster.local), dan sidecar bisa mengakses service tenant lain. Di sinilah dua mekanisme berikut berperan.

#Namespace Scoping dengan Sidecar CRD

Untuk mencegah sidecar tenant A membawa konfigurasi service tenant B, batasi scope-nya dengan Sidecar:

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: default
  namespace: tenant-a
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

egress.hosts: ["./*"] membatasi egress tenant-a hanya ke service di namespace yang sama plus istio-system. Efeknya berlapis: peta service di Envoy menyusut (lebih hemat resource) dan permukaan serangan lateral berkurang.

Untuk inbound, ingress bisa membatasi traffic masuk ke workload tertentu:

spec:
  ingress:
  - port:
      number: 80
      protocol: HTTP
    defaultEndpoint: 127.0.0.1:8080

Pola ini membatasi listener yang dibuat Envoy, sehingga workload tidak menerima traffic dari sembarang sumber.

#AuthorizationPolicy untuk Isolasi Tenant

Sidecar CRD mengontrol siapa yang bisa mengirim; AuthorizationPolicy mengontrol siapa yang boleh diterima. Kombinasikan keduanya untuk isolasi menyeluruh:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-cross-tenant
  namespace: tenant-a
spec:
  action: DENY
  rules:
  - from:
    - source:
        notNamespaces: ["tenant-a", "istio-system"]

notNamespaces menolak request yang datang dari namespace di luar tenant-a dan istio-system. Ini jaring pengaman: bahkan jika VirtualService mencoba merutekan lintas tenant, request tetap ditolak di level otorisasi.

#Kubernetes RBAC vs Istio AuthorizationPolicy

Kedua mekanisme ini sering tertukar. Perbedaannya penting:

#Kubernetes RBAC

RBAC mengontrol siapa yang boleh melakukan apa pada objek Kubernetes — membuat Pod, membaca Secrets, menghapus Deployment. Ia adalah kontrol administratif: melindungi cluster itu sendiri, bukan traffic aplikasi. Contoh: memberi developer akses hanya di namespace tenant-nya.

#Istio AuthorizationPolicy

AuthorizationPolicy mengontrol traffic yang melewati mesh — request HTTP antar service. Ia bekerja pada identitas workload dan claim JWT, bukan pada akun Kubernetes. Contoh: service frontend boleh memanggil productpage, tetapi service backend tidak.

Tabel mental yang mudah:

• RBAC: siapa boleh kubectl apa.
• AuthorizationPolicy: service mana boleh memanggil service mana.

Keduanya saling melengkapi. RBAC menjaga infrastruktur tetap aman dari penyalahgunaan manusia; AuthorizationPolicy menjaga komunikasi aplikasi tetap sesuai kebijakan. Keduanya harus dipasang bersama.

RBAC = siapa boleh mengelola cluster
AuthzPolicy = service mana boleh bicara ke service mana

#Penutup

Episode 12 menata multi-tenancy: namespace sebagai batas tenant dengan label revisi per tenant, Sidecar CRD untuk membatasi scope egress dan ingress, AuthorizationPolicy sebagai jaring pengaman lintas tenant, serta pemahaman jernih tentang pembagian peran RBAC Kubernetes dan AuthorizationPolicy Istio.

Inti yang harus dibawa pulang:

• Satu tenant satu namespace memudahkan isolasi dan upgrade bertahap.
• Label revisi per tenant memungkinkan migrasi Istio terisolasi.
• Sidecar CRD memangkas konfigurasi egress sekaligus permukaan serangan.
• AuthorizationPolicy deny lintas tenant adalah jaring pengaman kedua.
• RBAC mengatur akses administratif ke objek Kubernetes.
• AuthorizationPolicy mengatur komunikasi antar service di mesh.
• Gabungkan keduanya: RBAC untuk platform, AuthorizationPolicy untuk aplikasi.

Di episode 13 selanjutnya kita akan membahas lapisan network lain: network policies dan integrasi CNI — membandingkan NetworkPolicy Kubernetes dengan kebijakan Istio, memahami peran Istio CNI plugin, dan implikasinya terhadap lifecycle sidecar dan capture traffic.