Testing and Validation for the Flux2 Multi-Tenancy project
This project uses several technologies and dependencies for testing and validation, including Flux, Kustomize, Git, Kubernetes, Helm, Kyverno, sops, gnupg, kubeconform, and Kind. The following sections will cover the possible options for testing and validation and provide examples for each option, quoting the source of information.
Testing
The Flux project encourages community members to help with testing by verifying bugs, making minimal test cases, refining and expanding on existing unit and end-to-end tests, and trying Flux in new environments. (https://fluxcd.io/blog/2022/04/contributing-to-flux)
The scripts/validate.sh
script is used to validate the project’s configuration. However, the contents of this script are not provided in the given code snippet.
Multi-Tenancy Lockdown Configuration
The Flux project is working on documenting the multi-tenancy lockdown configuration, which will include conformance testing, end-to-end testing for bootstrap on AMD64 and ARM64 clusters, end-to-end testing for Flux self-upgrade, and end-to-end testing for multi-tenancy lockdown. (https://fluxcd.io/roadmap)
Security
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. In these cases, the policy is governed by each controller’s --no-cross-namespace-refs
flag. (https://fluxcd.io/flux/security)
The roles and permissions for the multi-tenancy approach are described in detail in the Flux2 Multi-Tenancy repository. (https://github.com/fluxcd/flux2-multi-tenancy)
SealedSecrets documentation provides information on how to best implement each solution. When SealedSecrets are employed, pay special attention to the scopes being used. (https://fluxcd.io/flux/security/best-practices)
End-to-End Testing
The Flux project includes end-to-end testing with Kubernetes Kind to ensure the project works as expected in various environments. (https://fluxcd.io/flux/flux-e2e)
Validation
The flux check
command performs a series of checks to validate that the local environment is configured correctly and if the installed components are healthy. (https://fluxcd.io/flux/cmd/flux_check)
The flux create tenant
command generates namespaces, service accounts, and role bindings to limit the reconcilers’ scope to the tenant namespaces. (https://fluxcd.io/flux/cmd/flux_create_tenant)
References
- https://fluxcd.io/blog/2022/01/january-update
- https://fluxcd.io/blog/2020/12/december-update
- https://fluxcd.io/flux/security
- https://fluxcd.io/roadmap
- https://fluxcd.io/flux/security/best-practices
- https://fluxcd.io/blog/2022/04/contributing-to-flux
- https://fluxcd.io/flux/use-cases/gh-actions-manifest-generation
- https://fluxcd.io/flux/cmd/flux_create_tenant
- https://fluxcd.io/flux/cmd/flux_check
- https://fluxcd.io/flux/flux-e2e
- https://docs.gitlab.com/ee/administration/reference_architectures
- https://github.com/fluxcd/flux2-multi-tenancy