Op dit kanaal hebben we in het verleden al eens gekeken naar Kyverno, een handige manier om beleid af te dwingen op Kubernetes objecten, en externe certificaten voor OpenShift Routes.

Met de release van Kyverno 1.15 een aantal maanden geleden is er een aantal nieuwe policy types beschikbaar gekomen voor Kyverno die gebruiken maken van Common Expression Lanaguage (CEL), dezelfde taal die ook door Kubernetes zelf gebruikt wordt op objecten als validatingadmissionpolicies, maar ook door dingen als Tekton Webhook Triggers.

CEL regels evalueren meestal sneller, en met minder resource gebruik dan traditionele Kyverno regels.

Als je een applicatie die via Hem charts wordt gedistribueerd in je OpenShift GitOps (ArgoCD) wilt opnemen heb je twee opties:

1. Een ArgoCD applicatie van het type “Helm” maken
2. De Helm chart via kustomize laten renderen, en de kustomization.yaml in je ArgoCD opnemen.

De eerste oplossing is het makkelijkst, en heeft weinig extra configuratie nodig. Het nadeel is wel dat je wat betreft aanpassingen gelimiteerd bent op wat de schrijver van de chart via de values.yaml heeft aangeboden.

Wanneer je extra aanpassingen nodig hebt kom je dus al snel uit op de tweede methode: De helm chart via kustomize laten renderen (inclusief aanpassingen via values.yaml), en daar extra aanpassingen op doen via de bekende kustomize transformers zoals images:, patches:, replicas:, etc.

In een Multi-Tenant OpenShift (of standaard Kubernetes) omgeving wil je als beheerder je eindgebruikers soms de vrijheid geven om zelf Project(Requests)s of Namespaces aan te maken, maar wwel binnen vastomlijnde naamgevings protocollen. In het verleden hebben we al eens gekeken hoe je dit met OPA Gatekeeper kunt doen, en hoe je zelf een Validating of Mutating Admission Webhook kunt maken. Dit keer kijken we hoe je dit met Kyverno kunt doen.