How Flux Handles Security and Multi-Tenancy

Flux addresses security through a pull-based reconciliation model, least-privilege access, and adherence to Kubernetes security policies, while multi-tenancy is implemented with true Kubernetes RBAC via impersonation and support for multiple Git repositories. This makes it a reasonable fit for platform teams that need to run shared GitOps infrastructure across teams or clusters — provided they already use Kubernetes RBAC and are comfortable granting Flux cluster-level read access to reconcile resources.

The security model: pull, not push

The core architectural choice is that Flux pulls from sources rather than having an external system push into the cluster. In practice this means:

• The cluster initiates connections to Git providers, container registries, and OCI sources. No inbound access to the cluster is required for deployment.
• Credentials for sources live inside the cluster as Kubernetes Secrets, so they are subject to the same RBAC and namespace isolation as any other cluster resource.
• Flux is designed around least amount of privileges — you grant only the permissions needed for the resources it reconciles, rather than a broad deploy credential held outside the cluster.

This is the opposite trade-off from push-based CI pipelines, where an external runner holds cluster credentials. If your threat model treats outbound-only connections and in-cluster secrets as safer than externally stored deploy tokens, Flux's model is the stronger option.

Security integration and policy adherence

Flux is built to adhere to Kubernetes security policies and to integrate tightly with security tooling and best practices. The project maintains a dedicated security considerations document covering its posture. Because everything is declared in Git and applied through pull requests, the change path is auditable: your Git history is a sequence of transactions, and you can recover state from any snapshot.

Multi-tenancy: real Kubernetes RBAC via impersonation

Flux does not invent its own permission system. It uses true Kubernetes RBAC via impersonation, which means:

• Reconciliation can act as a specific ServiceAccount, so a tenant's workloads are only ever applied with that tenant's permissions.
• A tenant cannot escalate beyond what its own RBAC allows, because the API server enforces the boundary — not Flux.
• Multiple Git repositories are supported, so different teams can own separate repositories and separate reconciliation scopes.

This is the key distinction from tools that use a single privileged controller identity for all tenants. With impersonation, the Kubernetes API server remains the enforcement point, which is what makes the model auditable and consistent with existing cluster policy.

Multi-cluster and "multi-everything"

Multi-cluster infrastructure and apps work out of the box with Cluster API:

• One Kubernetes cluster can manage apps in the same cluster or in other clusters.
• Flux can spin up additional clusters itself.
• It can manage cluster lifecycle and fleets.

Combined with multi-repository support and RBAC impersonation, this covers the common platform-team pattern: a management cluster running Flux, tenant repositories scoped by RBAC, and workload clusters provisioned and reconciled through Cluster API.

What to check before adopting it for a shared platform

If your teams already operate under namespace-scoped RBAC and you want Git to be the single auditable source of truth, Flux's security and tenancy model aligns with that setup. If your organization instead relies on a central external deploy system holding cluster credentials, the pull model is a meaningful architectural change you should evaluate first.