Document using Kyverno as a GitOps alternative for GitLab managed clusters with Auto DevOps
Release notes
Problem to solve
As a Platform Engineer, I want clear guidelines and recommendations on how to get the most value out of GitLab's Kubernetes integrations so that I can easily benefit from GitLab features without wasting my time on figuring out best practices.
Proposal
Document the setup of Kyverno to generate Service Accounts on Auto Deploy deployments. A Flux-specific example can be seen at https://kyverno.io/policies/flux/generate-flux-multi-tenant-resources/generate-flux-multi-tenant-resources/
Expected workflow:
- Platform engineer installs Kyverno
- Platform engineer deploys a Kyverno policy. We provide a fully-functional example policy that fits the Auto Build, and Auto Deploy artifacts.
- Based on the labels/annotations on the resources,
- Kyverno creates the namespace
- and a service account restricted for the new namespace
- and updates the resources to use the created Service account
- Based on the labels/annotations on the resources,
- Software engineer starts a new MR that results in a new deployment
- Software engineer receives a fully-functional environment deployed into a new namespace with a restricted Service account
Open questions
- Could we use Kyverno to create a namespace when the resources target a namespace that does not exist yet and the namespace name follows a pattern? (e.g. Deployment targets namespace
<project_name>-<project_id>-<environment>
, whereenvironment
follows a pattern ofreview/*
.) - Can Kyverno create resources when the Service account of Kyverno has the rights to do it, but the account making the original request does not have the rights to do it? (e.g. Assume that the agent Service account can create deployments in every namespace but can not create namespaces. Kyverno would create the namespace, and in the end, we deploy into that namespace using the agent Service account.)
Intended users
Feature Usage Metrics
TBD: please share your ideas how could we measure usage of this documentation-only integration as a 2nd step
References
- GitLab Managed Clusters
- Documentation on the legacy resources "managed" by GitLab
- Documentation on the variables used to customize GitLab Managed Cluster deployments
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.