Belajar GitOps - FluxCD - Multi-Tenancy dengan Flux

#Pendahuluan

Di episode 11 kalian sudah belajar variable substitution, postBuild, dan strategi konfigurasi per environment, termasuk memisahkan konfigurasi antar tenant. Sekarang kita naik satu tingkat: bagaimana kalau dalam satu cluster ada lebih dari satu tim, dan masing-masing mengelola aplikasinya sendiri melalui Git?

Skenario ini disebut multi-tenancy. Di episode 12 kita membahas bagaimana FluxCD menghadapinya: model tenancy, perintah flux create tenant, struktur tenant di Git dan cluster, access control, sampai lockdown mode.

#Apa Itu Multi-Tenancy?

Multi-tenancy adalah praktik berbagi satu infrastruktur, biasanya satu cluster Kubernetes, dengan banyak tim atau tenant, tanpa membiarkan satu tenant mengganggu atau mengakses milik tenant lain. Dalam konteks GitOps, setiap tenant biasanya memiliki:

• Repository Git sendiri sebagai source of truth
• Namespace atau kumpulan namespace sendiri di cluster
• Service account dan RBAC sendiri
• Resource quota sendiri

FluxCD dirancang mendukung multi-tenancy secara native. Kustomization bisa dijalankan dengan service account milik tenant, sehingga perubahan yang disinkronkan dari Git hanya berkuasa di wilayah tenant tersebut.

#Model Tenancy

#Setup Tenant dengan flux create tenant

Cara tercepat membuat tenant yang benar adalah perintah flux create tenant, yang menghasilkan objek RBAC yang konsisten dengan rekomendasi resmi FluxCD.

flux create tenant dev-team \
  --with-namespace=dev-team \
  --labels=team=dev \
  --export > dev-team-rbac.yaml

Perintah di atas menghasilkan namespace dev-team, ServiceAccount flux, Role dev-team:flux yang terbatas pada namespace tersebut, dan RoleBinding yang mengikatnya. Perhatikan hasilnya adalah Role dan RoleBinding, bukan ClusterRole dan ClusterRoleBinding — isolasi dasar tenant dibatasi hanya untuk namespace miliknya.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team:flux
  namespace: dev-team
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-team:flux
subjects:
  - kind: ServiceAccount
    name: flux
    namespace: dev-team

Terapkan ke cluster, lalu tinjau hasilnya sebelum dipakai di produksi:

kubectl apply -f dev-team-rbac.yaml

#Struktur Tenant

Tenant yang sehat memiliki struktur yang jelas, baik di Git maupun di cluster.

#Tenant Namespaces

Namespace adalah batas isolasi paling dasar di Kubernetes. Setiap tenant mendapat namespace sendiri, dan semua resource aplikasinya berada di sana. Dengan RBAC dari flux create tenant, service account tenant tidak bisa menyentuh namespace lain.

#Tenant Git Sources

Setiap tenant mereferensikan repository miliknya lewat GitRepository, dengan kredensial terpisah dalam Secret sendiri.

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: dev-team-apps
  namespace: dev-team
spec:
  interval: 5m
  url: https://github.com/acme/dev-team-apps
  ref:
    branch: main

#Tenant Kustomizations

Field serviceAccountName adalah kunci isolasi ini — tanpa field tersebut, Kustomization dijalankan dengan service account default yang dipakai flux-system.

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: dev-team-apps
  namespace: dev-team
spec:
  serviceAccountName: flux
  sourceRef:
    kind: GitRepository
    name: dev-team-apps
  path: ./apps
  prune: true
  interval: 5m

#Resource Quotas

Namespace-based tenancy tanpa ResourceQuota bisa membuat satu tenant memonopoli resource cluster. Selalu pasang quota agar penggunaan resource setiap tenant bisa diukur dan dibatasi:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-team-quota
  namespace: dev-team
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "20"
    services: "10"

#Access Control

Untuk akses Git, kredensial tiap tenant harus terpisah. Jangan berbagi Personal Access Token antar tenant — gunakan deploy key atau bot account per repository. Di sisi cluster, pastikan service account tenant tidak punya permission impersonate, escalate, atau akses ke ClusterRole.

#Lockdown Mode

Lockdown mode adalah kumpulan praktik untuk memperketat lingkungan multi-tenant. Saat bootstrap, FluxCD menyediakan dua flag penting:

flux bootstrap github \
  --owner=acme \
  --repository=fleet \
  --branch=main \
  --path=./clusters/prod \
  --network-policy=true \
  --no-cross-namespace-refs=true

#Mencegah Privilege Escalation

Service account tenant tidak boleh memiliki permission untuk mengubah Role, RoleBinding, atau ClusterRole. Permission escalate dan bind harus dihapus dari aturan tenant, karena tanpa ini tenant bisa memberikan permission tambahan kepada dirinya sendiri.

#Mencegah Impersonation

Permission impersonate memungkinkan sebuah identity meniru identity lain. Tenant tidak boleh memilikinya, karena bisa dipakai melewati batas RBAC yang sudah dipasang.

#Network Policies

Selain deny-all di flux-system, pasang NetworkPolicy per tenant untuk memutus komunikasi antar tenant:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: dev-team
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

#Admission Controllers

Admission controllers seperti OPA Gatekeeper atau Kyverno menegakkan kebijakan di level cluster: menolak Pod yang menaikkan privilege, melarang hostPath, memaksa setiap namespace tenant memiliki quota, dan lain-lain. Ini adalah lapisan terakhir yang menutup celah yang lolos dari RBAC dan NetworkPolicy.

#Penutup

Di episode 12 ini kalian sudah mempelajari cara mengisolasi banyak tim dalam satu cluster menggunakan FluxCD.

Inti yang harus dibawa pulang:

• Model tenancy: namespace-based paling umum, cluster-based paling kuat, hybrid untuk kebutuhan kompleks.
• flux create tenant menghasilkan ServiceAccount, Role, dan RoleBinding yang konsisten dan terbatas pada satu namespace.
• serviceAccountName pada Kustomization adalah kunci agar setiap tenant hanya berkuasa di wilayahnya sendiri.
• ResourceQuota dan NetworkPolicy mencegah satu tenant memonopoli resource atau berkomunikasi dengan tenant lain.
• Lockdown mode diperkuat dengan flag bootstrap, larangan impersonation dan escalation, serta admission controllers.

Di episode 13 berikutnya kita akan membahas Image Automation — bagaimana FluxCD memantau container registry, mengevaluasi versi image baru, dan otomatis memperbarui Git. Sampai jumpa di episode berikutnya!