fluxcd / flux2-multi-tenancy

Tenant Roles and Responsibilities - fluxcd/flux2-multi-tenancy

Tenant Roles and Responsibilities in Flux2 Multi-Tenancy

Flux2 Multi-Tenancy is a project that showcases how platform admins can onboard tenants and limit their access to cluster resources with various policies. The Flux multi-tenancy model assumes two types of users: platform admins and tenants. This document outlines the roles and responsibilities of each.

Platform Admins

Platform admins are responsible for:

  1. Installing Flux on the cluster.
  2. Configuring Flux multi-tenancy lockdown during bootstrap.
  3. Onboarding tenants and assigning them namespaces.
  4. Provisioning tenant’s service accounts and RBAC.
  5. Configuring cluster-wide resources.
  6. Managing Flux custom resources using built-in RBAC roles (view, edit, admin).
  7. Implementing further best practices for Flux deployment security.

Tenants

Tenants are responsible for:

  1. Registering their sources with Flux (GitRepositories, HelmRepositories, and Buckets).
  2. Deploying workloads into their namespace(s) using Flux custom resources (Kustomizations and HelmReleases).
  3. Automating application updates using Flux custom resources (ImageRepositories, ImagePolicies, and ImageUpdateAutomations).
  4. Configuring the release pipeline(s) using Flux custom resources (Canaries and MetricsTemplates).
  5. Setting up webhooks and alerting for their release pipeline(s) using Flux custom resources (Receivers and Alerts).

Flux Multi-Tenancy Configuration

To configure Flux multi-tenancy, platform admins can follow these steps:

  1. Lock down Flux on multi-tenant clusters during bootstrap.
  2. Use the Flux team’s dedicated repository (github.com/fluxcd/flux2-multi-tenancy) as a reference for onboarding tenants and limiting their access to cluster resources.
  3. Apply RBAC policies to grant or restrict access to Flux custom resources.
  4. Use the flux create tenant command to generate namespaces, service accounts, and role bindings to limit the reconcilers’ scope to the tenant namespaces.

Example:

flux create tenant dev-team \
  --with-namespace=frontend \
  --with-namespace=backend \
--export > dev-team.yaml

Security

Flux follows Kubernetes best RBAC practices, which forbid cross-namespace references to potential sensitive data. For sources and events, Flux allows referencing resources from other namespaces, governed by each controller’s --no-cross-namespace-refs flag.

Further securing Flux deployments can be achieved by implementing purpose-built policy enforcement tools like OPA, Kyverno, or admission controllers.

GitHub Actions Manifest Generation

For manifest generation, Flux provides an example of how to create a tenant installation with a ServiceAccount and Namespace. The ClusterRoleBinding or a more restrictive RoleBinding is important for a functioning Flux tenant installation.

References: