Documentation: Routes Defined in fluxcd/flux2-multi-tenancy Codebase

This document provides an in-depth overview of the routes defined within the fluxcd/flux2-multi-tenancy codebase. It focuses on the directory structure and key configuration files that dictate how Flux operates within a multi-tenant Kubernetes environment.

Overview of Directory Structure

The codebase contains several top-level directories that play a critical role in defining the routes of the application:

├── clusters
│   ├── production
│   └── staging
├── infrastructure
│   ├── kyverno
│   └── kyverno-policies
└── tenants
├── base
├── production
└── staging

1. Clusters Directory

The clusters directory contains configurations for each cluster environment. Within each environment (production and staging), specific YAML files are defined to handle the reconciliation of components and tenant workloads.

• Production Directory: Holds infrastructure.yaml and tenants.yaml files that define the necessary resources and configurations.

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: tenants
namespace: flux-system
spec:
dependsOn:
- name: kyverno-policies
interval: 5m
serviceAccountName: kustomize-controller
sourceRef:
kind: GitRepository
name: flux-system
path: ./tenants/production
prune: true

• Staging Directory: Similar to production, it contains configurations but is tailored for pre-release environments.

2. Infrastructure Directory

The infrastructure directory contains common infrastructure tools that assist in managing the control plane, including:

• Kyverno Directory: Houses configurations for Kyverno, a policy engine used to enforce security and compliance by managing admission controllers and various cluster policies.

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: kyverno-policies
namespace: flux-system
spec:
dependsOn:
- name: kyverno
interval: 5m
sourceRef:
kind: GitRepository
name: flux-system
path: ./infrastructure/kyverno-policies
prune: true

3. Tenants Directory

The tenants directory delineates namespaces, service accounts, RBAC rules, and Flux custom resources for managing tenant repositories. Each tenant has its configuration for application management:

• Base Directory: Contains foundational configurations including HelmRepository and HelmRelease manifests.

• Staging and Production Directories: Host patch configurations for HelmRelease that cater to staging or production environments.

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: dev-team
namespace: apps
spec:
path: ./staging

Impersonation and Access Control

To ensure appropriate access control, Flux uses service accounts to impersonate during reconciliation actions across namespaces. Specifically, kustomize-controller and helm-controller will operate under a designated service account:

- patch: |
- op: add
path: /spec/serviceAccountName
value: kustomize-controller
target:
kind: Kustomization
name: "flux-system"

Isolation Features

Flux incorporates built-in multi-tenancy lockdown features to enhance tenant isolation. Configuration patches ensure that resources do not reference sources from other namespaces, which is crucial for maintaining security.

Example of Multi-Tenant Setup

A sample command to create a tenant configuration might look like this:

flux create kustomization dev-team \
--namespace=apps \
--service-account=dev-team \
--source=GitRepository/dev-team \
--path="./" \
--export >> ./tenants/base/dev-team/sync.yaml

Upon creation, a corresponding Kustomization file will be established in the tenants/base/dev-team directory, configuring the proper directory structure and ensuring that the appropriate resources are referenced.

Conclusion

The fluxcd/flux2-multi-tenancy codebase exhibits a robust directory structure and pattern of configuration that supports multi-tenant environments. Through precise configurations and rigorous access controls, it enforces isolation and management specific to tenant requirements. This document serves as a guide for navigating the defined routes within the codebase, ensuring expert developers can utilize and extend the capabilities of Flux effectively.

Sources: Documentation sections within README.md from the fluxcd/flux2-multi-tenancy repository.