GitOps and multi-tenancy
GitOps
According to the Flux documentation:
GitOps is a way of managing your infrastructure and applications so that the whole system is described declaratively and version controlled (most likely in a Git repository), and has an automated process that ensures that the deployed environment matches the state specified in a repository.
To learn more about GitOps, have a look at “What is GitOps?”.
Multi-tenancy
In a multi-tenant GitOps managed cluster, the infrastructure is described in one repository usually called platform admin repository or fleet repository, and the applications are described in separate repositories. This allows defining permissions depending on the role. The platform admin has access to the fleet repository and onboards and manages the tenants. The tenants only have access to their tenant repository and therefore to the namespaces assigned to them by the platform admin. They cannot act outside the scope defined by the platform admin. The roles in a multi-tenant cluster are described in detail here.
Lizz follows the multi-tenant structure and considers each application is associated with a tenant.
Therefore each application has its repository and can only access its namespace.
Some applications need access beyond their namespace to create custom resources for instance.
In that case, it is possible to give the application access to all namespaces by adding the --cluster-role flag to the lizz add command.
As maintaining a multi-tenant GitOps cluster can be complex, Lizz takes care of the following steps:
- create the fleet repository,
- setup the Kubernetes secret management to connect with private tenant repositories,
- onboard a new tenant with the correct role when adding a new application,
- create the applications repositories.