Moteurs de politique Kubernetes : OPA contre Kyverno contre jsPolicy

Un moteur de politiques Kubernetes est essentiel pour assurer la sécurité de votre cluster et garantir que les politiques sont définies correctement dès le départ. Par exemple, vous avez probablement besoin d’une stratégie pour contrôler qui a le pouvoir de définir un pod privilégié. Ces moteurs définissent ce que les utilisateurs finaux peuvent faire sur le cluster et garantissent que les clusters peuvent communiquer. Chaque fois qu’un objet Kubernetes est créé, une stratégie évalue et valide ou modifie la requête. Les stratégies peuvent s’appliquer à un espace de noms ou à différents pods avec une étiquette spécifique dans le cluster.

Les moteurs de politique Kubernetes bloquent les objets qui pourraient endommager ou affecter le cluster s’ils ne répondent pas aux exigences de la politique. L’utilisation de stratégies permet aux utilisateurs de créer des configurations complexes que d’autres outils, tels que Terraform ou Ansible, ne peuvent pas réaliser.

Le paysage politique a évolué ces dernières années et le nombre de moteurs de politique disponibles ne cesse d’augmenter. Les nouveaux produits sont en concurrence avec des outils bien établis.

Cet article met en évidence certaines fonctionnalités que vous devez rechercher dans un moteur de stratégie et où ces trois exemples excellent et sous-performent. Il compare trois moteurs de politique open source populaires, Open Policy Agent (OPA), Kyverno et jsPolicy.

Fonctionnalités du moteur de politique

Je commencerai par énumérer diverses fonctionnalités afin que vous puissiez comparer les moteurs de politique :

• Langue prise en charge: Un moteur de stratégie doit utiliser un langage pris en charge par Kubernetes pour faciliter la gestion des ressources de stratégie.
• Validation: Les règles de validation déterminent les propriétés avec lesquelles une ressource peut être créée. Les ressources sont validées lorsqu’elles sont comparées aux règles et acceptées.
• Mutation: Les règles de mutation peuvent modifier des ressources spécifiques dans le cluster. Ces règles modifient un objet particulier d’une manière donnée.
• Outillage pour le développement et les tests: Ces outils testent un ensemble de ressources par rapport à une ou plusieurs politiques pour comparer les ressources aux résultats souhaités (déclarés dans un fichier séparé).
• Gestion des colis: la gestion des packages gère l’emplacement de stockage de vos règles et la manière dont elles sont gérées dans le cluster.
• Verification de l’image: L’utilisation de politiques pour vérifier et signer les images de conteneurs.
• Rallonges: Fonctions et plugins personnalisés qui étendent et implémentent des fonctionnalités, comme la prise en charge de nouveaux protocoles.
• Métrique: Surveiller tous les changements appliqués aux politiques, les activités liées aux demandes entrantes et les résultats produits en conséquence.

Agent de politique ouvert (OPA)

Agent de politique ouvert (OPA) est un moteur de politique facile à utiliser qui peut être colocalisé avec votre service et incorporé en tant que side-car, démon au niveau de l’hôte ou bibliothèque. OPA est un moteur à usage général qui gère les politiques sur plusieurs piles, et vous pouvez l’utiliser pour d’autres tâches telles que le filtrage des données et les pipelines CI/CD.

OPA vous permet de dissocier vos politiques de votre infrastructure, service ou application afin que les personnes responsables de la gestion des politiques puissent contrôler la politique séparément du service. Vous pouvez également dissocier les politiques de n’importe quel service logiciel que vous aimez et rédiger des politiques sensibles au contenu en utilisant le contexte de votre choix. Les politiques de découplage vous aideront à créer des services à grande échelle, à améliorer la capacité à localiser les violations et les conflits et à réduire le risque d’erreurs humaines.

Les politiques OPA utilisent un langage appelé Régo. Rego est un langage de requête qui étend Datalog pour prendre en charge les modèles de données structurés tels que JSON. OPA fournit un cadre pour écrire des tests pour vos politiques. Ce cadre accélère le développement de nouvelles règles et réduit le temps nécessaire pour modifier celles qui existent déjà. OPA peut également rapporter des mesures de performance lors de l’exécution. Ces métriques peuvent être demandées lors d’appels d’API individuels et sont renvoyées conformément à la réponse de l’API.

OPA fonctionne en prenant des décisions sur les politiques, pas nécessairement en les appliquant. Lorsqu’une requête est envoyée dans le système, elle est transmise à OPA, qui valide ensuite la requête par rapport aux politiques en place et prend une décision. OPA prend des décisions politiques en comparant l’entrée de la requête aux politiques et aux données. OPA et Rego sont indépendants du domaine, ce qui signifie que vous pouvez décrire n’importe quel invariant dans les politiques. En outre, les décisions politiques ne sont pas limitées aux réponses oui/non ou autoriser/refuser. Comme les entrées de requête, vos politiques peuvent créer des données structurées en sortie.

Kyverno

Kyverno est un moteur de politique Kubernetes qui utilise un paradigme de gestion déclarative pour construire des politiques de modification, de validation ou de génération de ressources ou de configurations. Contrairement à OPA, qui utilise la stratégie comme code, vous spécifiez le code plutôt que de l’écrire, et Kyverno détermine ensuite comment l’exécuter. Kyverno utilise YAML, de sorte que ces politiques sont considérées comme des ressources Kubernetes et peuvent être écrites sans apprendre une nouvelle langue. Cela facilite l’affichage et le traitement des résultats de la stratégie. Kyverno surpasse OPA ici, car développer du code dans le langage Rego peut être difficile, surtout sans connaissances approfondies.

Kyverno fonctionne bien avec d’autres outils de développement comme Git et kubectl. Les règles de validation sont le principal cas d’utilisation des contrôleurs d’admission comme Kyverno, ce qui facilite la validation des ressources qui respectent les règles de politique lors de leur création. Kyverno utilise Cosigner pour vérifier et signer des images. Si l’image ne se trouve pas dans le Registre OCI ou n’a pas été signé à l’aide de la clé spécifiée, la règle de stratégie ne le validera pas. En outre, Kyverno utilise Grafana pour exposer et collecter des métriques à partir du cluster. Il simplifie et consolide la distribution des politiques à l’aide d’un registre de conteneurs (registre OCI).

Kyverno fonctionne comme un contrôleur d’admission dynamique, recevant des rappels HTTP du serveur d’API Kubernetes et appliquant des politiques de correspondance à ces rappels. Les stratégies correspondent aux ressources à l’aide de sélecteurs tels que le nom, le type et l’étiquette. Kyverno utilise un webhook comme contrôleur car il gère les demandes d’examen d’admission du serveur. Dans le webhook, un moniteur crée et gère toutes les configurations requises. Il existe un contrôleur de générateur qui génère des requêtes et gère l’étendue des ressources générées, et un contrôleur de politique qui crée, met à jour, supprime et surveille les ressources de politique, exécutant des analyses en arrière-plan à intervalles réguliers pour décider de la marche à suivre.

jsPolicy

jsPolicy est un moteur de politique open source pour Kubernetes qui permet aux utilisateurs de créer des politiques à l’aide de JavaScript ou de TypeScript. La gestion des politiques avec JavaScript est moins complexe et plus simple. En raison de l’utilisation généralisée du langage de programmation JavaScript, des frameworks et de nombreuses bibliothèques et modules, jsPolicy est un choix naturel en tant qu’outil de moteur de politique. Kyverno et OPA sont plus difficiles à modifier et à valider que jsPolicy. Sa distribution utilise des packages npm et dispose d’un SDK JavaScript intégré pour créer et empaqueter des politiques.

jsPolicy est le premier moteur de politiques à disposer de politiques de contrôleur (politiques qui répondent aux événements Kubernetes). Cette fonctionnalité vous permet de faire quelque chose sur les événements Kubernetes et de les valider ou de les faire muter à l’aide de jsPolicy. Comme OPA, jsPolicy est une plate-forme de stratégie en tant que code. Cependant, il a été créé pour résoudre le problème du langage Rego et fournir certaines fonctionnalités pour certaines fonctionnalités non disponibles sur Kyverno.

Vous pouvez utiliser kubectl et l’API Kubernetes avec jsPolicy, et chaque demande qui arrive persiste dans etcd. Avant que les requêtes ne soient persistantes, un gestionnaire de webhook exécutera la politique dans votre cluster. Il utilise des bacs à sable JavaScript prédéfinis dans votre cluster pour faciliter l’exécution des politiques, en augmentant l’efficacité et la vitesse. Un compilateur de stratégie lit le code jsPolicy et le compile dans un ensemble de stratégies, qui est placé et exécuté dans le bac à sable pour fournir des violations de stratégie. La violation de stratégie est interrogée pour alerter et auditer les objets qui violent le code de stratégie. Étant donné que jsPolicy vous permet de travailler avec JavaScript, vous pouvez utiliser l’ensemble de l’écosystème JavaScript avec ses excellents outils de développement et ses frameworks de test pour écrire, tester et maintenir des politiques.

Comparer les moteurs de politiques Kubernetes

Les fonctionnalités de chaque moteur de stratégie diffèrent. Bien qu’ils puissent tous valider et faire muter des ressources, ils diffèrent par d’autres fonctions spécifiques. Par exemple, OPA et Kyverno prennent en charge les extensions, mais pas jsPolicy. Le résumé ci-dessous compare les caractéristiques de ces trois politiques :

• OPA
  • Langue : Régo
  • Validation : Oui
  • Mutation : Alpha
  • Développement/test : Limité
  • Gestion des colis : NA
  • Validation des images : Oui
  • Rallonges : Oui
  • Métrique : Prometheus
• Kyverno
  • Langage : YAML
  • Validation : Oui
  • Mutation : Oui
  • Développement/test : Limité
  • Gestion des colis : NA
  • Validation des images : Oui
  • Rallonges : Oui
  • Métrique : Grafana
• jsPolicy
  • Langage : Javascript
  • Validation : Oui
  • Mutation : Oui
  • Développement/test : étendu
  • Gestion des paquets : npm
  • Validation des images : Non
  • Rallonges : Non
  • Métrique : Prometheus

Conclure

Cet article traite des concepts entourant les moteurs de politiques Kubernetes et compare trois moteurs de politiques Kubernetes différents : OPA, Kyverno et jsPolicy.

Le choix du moteur à utiliser dépend de vos préférences personnelles. Si vous souhaitez une approche plus directe et simple, ou si vous connaissez bien JavaScript et TypeScript, vous devez utiliser jsPolicy. Mais, si vous préférez YAML et que vous souhaitez continuer à travailler directement avec les ressources Kubernetes, Kyverno est également une bonne option.