Multi-tenant GitOps with FluxCD across shared clusters

Problem

Multiple product teams sharing EKS clusters wanted GitOps autonomy — deploy their own apps, manage their own configs — without escalated permissions to cluster-scope resources.

Solution

Tenant isolation using Flux's built-in tenancy model:

• Platform team owns the root Flux bootstrap and all cluster-scope resources (CRDs, ClusterRoles, storage classes).
• Each tenant gets a namespace-scoped GitRepository and Kustomization pointing to their own repo path.
• serviceAccountName in each tenant's Kustomization maps to a namespace-scoped SA — Flux impersonates it when applying, so tenants can't escape their namespace.

Bootstrapping

A single platform-owned Kustomization deploys all tenant configs from a central repo. Adding a tenant = one PR to the platform repo defining their GitRepository, Kustomization, and RBAC.

Lessons

Flux's spec.serviceAccountName impersonation is the key primitive here. Without it, Flux runs as its own controller SA which has broad permissions — not what you want when tenants control their own manifests.

Also: make spec.prune: true default. Otherwise deleted manifests linger and you debug phantom resources for an hour.