fluxcd / flux2-multi-tenancy

Platform Admin Roles and Responsibilities - fluxcd/flux2-multi-tenancy

Platform Admin Roles and Responsibilities for Flux2 Multi-Tenancy

Flux2 Multi-Tenancy is a project that allows different organizations and/or teams to share the same Kubernetes control plane, referred to as “multi-tenancy”. Platform admins play a crucial role in configuring and managing Flux2 Multi-Tenancy. This document outlines the roles, responsibilities, and options available to platform admins.

Roles and Responsibilities

Platform admins are responsible for:

  1. Bootstrapping Flux onto the cluster(s)
  2. Extending the Kubernetes API with custom resource definitions and validation webhooks
  3. Configuring various controllers for ingress, storage, logging, monitoring, and progressive delivery
  4. Setting up namespaces for tenants and defining their level of access with Kubernetes RBAC
  5. Onboarding tenants by registering their Git repositories with Flux

Options for Platform Admins

Platform admins can configure Flux2 Multi-Tenancy during bootstrap with patches:

apiVersion :   kustomize.config.k8s.io/v1beta1
kind :   Kustomization
resources :

The flux-system Kustomization is set to reconcile under a service account with cluster-admin role, allowing platform admins to configure cluster-wide resources and provision tenant’s namespaces, service accounts, and RBAC.

To onboard tenants and limit their access to cluster resources, platform admins can use the example provided by the Flux team at https://github.com/fluxcd/flux2-multi-tenancy.

Flux RBAC grants Kubernetes built-in view, edit, and admin roles access to Flux custom resources. Platform admins can disable RBAC aggregation by removing the flux-view and flux-edit RBAC rules to Flux API objects.

Flux controllers can impersonate a service account mentioned in the apply specification for both accessing resources and applying configuration. This allows users to constrain the operations performed by the Flux controllers with RBAC.

Security Considerations

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

In a soft multi-tenancy setup, Flux does not reconcile a tenant’s repo under the cluster-admin role. Instead, a different service account is specified in the manifest, and the Flux controllers use the Kubernetes Impersonation API under cluster-admin to impersonate that service account.

References