Aperçu
Kubernetes (K8s), ou sa distribution d’entreprise OpenShift, est devenu une solution de facto pour les plateformes de conteneurs. Les entreprises qui exécutent Kubernetes/OpenShift à grande échelle et sur plusieurs clusters sont confrontées à des défis pour maintenir la sécurité des clusters, et lorsque plusieurs équipes de différentes expertises travaillent sur la même plateforme, il devient de plus en plus difficile de s’assurer que tous respectent les bonnes pratiques. En fait, il est nécessaire d’avoir un mécanisme en place permettant aux organisations de définir et d’appliquer des politiques afin que les développeurs et les administrateurs conservent un certain standard — et ce mécanisme ne devrait pas entraîner de surcharge supplémentaire pour les opérations et la maintenance.
Kyverno est une telle solution qui permet aux administrateurs de clusters de gérer des configurations propres à l’environnement, d’appliquer les meilleures pratiques de sécurité et d’aider au nettoyage. Dans cet article, nous allons explorer Kyverno, l’associer à nos besoins et cas d’utilisation où il peut être utile.
Qu’est-ce que Kyverno?
En grec, Kyverno signifie « gouverner ». Dans le monde technologique, il s’agit d’un moteur de politiques fonctionnant comme contrôleur d’admission dynamique. Kyverno est open source, soutenu par la communauté, et ses politiques sont écrites en YAML comme ressources Kubernetes, ce qui les rend simples et lisibles. YAML signifie « yet another markup language ». Il s’agit d’un format de sérialisation de données lisible par l'humain, souvent utilisé pour les fichiers de configuration et l'échange de données entre des langages ayant des structures de données différentes.
Ces politiques écrites en YAML ne sont pas seulement pour les pods — elles peuvent s’appliquer à presque tous les objets Kubernetes. La portée peut être définie au niveau du namespace ou de tout le cluster. Voici les principales fonctionnalités et capacités de Kyverno.
- Validation, mutation, génération et nettoyage des ressources
- Synchroniser la configuration entre les espaces de noms
- Bloquer ou signaler les ressources non conformes via les contrôles d’admission.
- Politique comme ressource K8s et fonction d’audit des politiques
- Schéma de validation OpenAPI
- Rapports en libre-service et exception
Comme Kyverno fonctionne comme contrôleur d’admission dynamique, nous pouvons appliquer les politiques de sécurité et les meilleures pratiques à chaque requête push K8s ; en utilisant Kyverno CLI, nous pouvons vérifier le comportement de la politique sur la ressource même avant de l’ajouter dans un cluster, par exemple dans le pipeline CI-CD. Nous pouvons vérifier si la requête suit la sécurité du cluster et les meilleures pratiques du cluster où nous allons déployer la charge de travail.
Politique Kyverno et types
Dans OpenShift ou Kubernetes, il existe deux webhooks : mutation et validation. Kyverno est conçu pour fonctionner comme contrôleur d’admission et dispose d’une capacité supplémentaire : la génération. Une politique Kyverno est un ensemble de règles, où chaque pratique comprend une déclaration de correspondance permettant de contrôler à quel type d’objet cela s’applique et une exclusion optionnelle qui sélectionne tout sauf les ressources correspondant aux critères spécifiés. Chaque règle ne peut contenir qu’une seule déclaration enfant : validate, mutate, generate ou verify images, qui détermine ce qu’il faut faire sur l’objet sélectionné dans la déclaration de correspondance.
Les politiques peuvent s’appliquer uniquement à un espace de noms à l’aide de l’objet K8s « Policy » et à tous les espaces de noms du cluster avec l’objet « ClusterPolicy ».

On peut rédiger trois types de politiques :
- Politique de validation : Règles pour vérifier les propriétés obligatoires de la ressource. Si les propriétés et les règles correspondent, cela permet la requête API.
- Politique de mutation : Modifie les requêtes entrantes pour adapter les ressources au cluster et s’exécute systématiquement avant les politiques de validation. Par exemple, vous pouvez vouloir qu’une étiquette spécifique soit ajoutée avant de créer un déploiement dans Kubernetes. Même si vous oubliez de l’ajouter avant d’appliquer la configuration, le webhook de mutation l’ajoutera avant de créer la ressource.
- Politique de génération : Création d’objets et ressources supplémentaires (nouveaux), par exemple la création d’une politique réseau lors de la création de chaque nouveau namespace.
Installation
Kyverno est un moteur de politiques installé et exploité comme webhook du contrôleur d’admission. Puisqu’il s’agit d’un élément central qui affecte toutes les requêtes au cluster, nous avons besoin de l’accès d’admin du cluster pour l’installer. Nous pouvons installer Kyverno en ajoutant un dépôt helm ou en déployant un YAML.
Pour satisfaire à la validation des contraintes de contexte de sécurité d’OpenShift, il faut ajouter --set securityContext=null.
Kyverno ne prend pas en charge deux réplicas. Pour une installation hautement disponible, le seul nombre pris en charge est 3. Il est nécessaire d’accorder un accès cluster-admin au compte de service Kyverno afin qu’il puisse vérifier et contrôler toutes les requêtes API. La bibliothèque comprend de nombreuses politiques de différentes catégories, accessibles via une page web — https://kyverno.io/policies/ — à explorer et appliquer selon les besoins.
À considérer lors du déploiement de Kyverno
Comme pour toute technologie, le contrôle de son utilisation est la clé de son succès. En travaillant de près avec les clients et en explorant ses vastes fonctionnalités, nous avons identifié certains points à garder à l’esprit lors de l’adoption de Kyverno.
- Analyser nos besoins : De nombreuses politiques sont déjà rédigées dans la bibliothèque et la communauté en ajoute d’autres, mais tout ce qui est disponible n’est pas toujours pertinent. Toute politique non requise pour l’environnement est inutile, et les conserver peut créer des problèmes plus tard. Toutes les bonnes pratiques ne s’appliquent pas à tous les environnements, par exemple en production il y a plus de restrictions qui ne sont pas nécessaires en développement.
- Concevoir pour la collaboration : Les politiques devraient être conçues pour tous, pas seulement pour ceux ayant des privilèges d’admin. Cela permet aux résultats des politiques d’être partagés, consultés et discutés entre tous les groupes. Cette anticipation mène à des améliorations continues. L’utilisation de l’interface utilisateur policy-reporter-UI est une solution bien adaptée à cela.
- Comprendre les risques : Kyverno sera installé et maintenu de façon hautement disponible puisqu’il agit comme contrôleur d’admission, et s’il n’est pas sain ou disponible, aucune nouvelle requête ne sera traitée, ce qui affectera tout le cluster. Un moteur GitOps, par exemple flux CD, argoCD, etc., permet d’être informé des paramètres des ressources mutées/générées par Kyverno ou des exceptions explicites à concevoir.
Kyverno et ses avantages pour les non-initiés
Kyverno est conçu pour Kubernetes et s’applique aux pods et à presque toutes les ressources K8s. Ses principales caractéristiques incluent la validation, la mutation, la génération et le nettoyage des ressources, la synchronisation des configurations entre namespaces, le blocage ou le signalement des ressources non conformes via l’admission, la politique comme ressource K8s, l’audit des politiques, le schéma de validation OpenAPI ainsi que les rapports et exceptions en libre-service. Ses avantages comprennent :
- Kyverno utilise du YAML simple, ce qui réduit les coûts de formation (nouveaux outils/langages) et le maintien des ressources compétentes
- Kyverno est conçu pour Kubernetes et s’applique aux pods et à presque toutes les ressources K8s
- Il offre la possibilité de tester le comportement d’une politique sur des ressources avant de l’appliquer dans un cluster réel
- Il offre aussi le soutien de la communauté et une vaste bibliothèque de politiques, évitant ainsi d’avoir à écrire des politiques à partir de zéro
- Les rapports sur les politiques permettent de clarifier les politiques et les ressources et peuvent être consultés et téléchargés depuis l’outil policy reporter-UI

