SUSE Security Admission Controller vs OPA Gatekeeper

À la fois OPA Gatekeeper et Kubernetes peuvent écrire des stratégies de validation et de mutation.

Ces stratégies peuvent cibler tout type de ressource Kubernetes, y compris les ressources personnalisées.

Vous écrivez des stratégies OPA Gatekeeper en utilisant Rego. Rego est un langage de requête créé par le projet Open Policy Agent.

Vous pouvez écrire des stratégies Admission Controller en utilisant différents paradigmes. Les auteurs de stratégies peuvent utiliser à la fois des langages de programmation traditionnels (comme Go, Rust et d’autres) ou Langages Spécifiques au Domaine comme Rego et CEL. Dans Admission Controller, vous écrivez des stratégies de validation et de mutation de la même manière.

Parfois, une stratégie a besoin de données sur l’état actuel du cluster pour prendre une décision de validation ou de mutation. Par exemple, une stratégie validant les ressources Ingress pourrait avoir besoin de connaître d’autres ressources Ingress déjà définies dans le cluster pour s’assurer qu’aucun conflit ne se produise. Admission Controller appelle ces stratégies « conscientes du contexte ».

Tant OPA Gatekeeper que Admission Controller prennent en charge ces types de stratégies.

Lors du déploiement d’OPA Gatekeeper, un administrateur Kubernetes décide quel type de données de cluster rendre disponible aux stratégies au moment de l’évaluation.

Il est important de souligner comment ces données sont ensuite accessibles par toutes les stratégies déployées.

Par exemple, si une stratégie OPA Gatekeeper nécessite l’accès aux Secrets Kubernetes, toutes les autres stratégies déployées peuvent également lire ces données.

Inversement, Admission Controller fournit un accès granulaire aux ressources du cluster. Chaque stratégie n’a accès qu’aux ressources que l’administrateur Kubernetes spécifie. Tenter de lire des données non autorisées est immédiatement bloqué et signalé aux administrateurs du cluster.

OPA Gatekeeper dispose d’une ressource personnalisée à l’échelle du cluster, permettant la définition de stratégies et leur application.

Admission Controller a deux types différents de ressources personnalisées utilisées pour déclarer des stratégies. L’une fonctionne au niveau du cluster, l’autre est dans un espace de noms. Le nom de la ressource personnalisée dans l’espace de noms est AdmissionPolicy.

Les stratégies déployées via une ressource AdmissionPolicy n’affectent que les ressources créées dans l’espace de noms auquel elles appartiennent. De ce fait, vous pouvez permettre aux utilisateurs Kubernetes non administrateurs d’avoir les privilèges RBAC nécessaires pour gérer les ressources AdmissionPolicy, dans les espaces de noms auxquels ils peuvent accéder.

Cela permet aux administrateurs Kubernetes de déléguer le travail lié aux stratégies.

OPA Gatekeeper et les stratégies Admission Controller ont le code source de la stratégie (Rego pour OPA Gatekeeper, CEL pour Admission Controller) dans la ressource personnalisée définissant une stratégie dans Kubernetes.

De plus, les stratégies Admission Controller peuvent avoir le code source de la stratégie géré comme des images de conteneur (pour Rego, Go, Rust, …​). Une fois construites, elles sont poussées dans des registres de conteneurs en tant qu’artefacts OCI.

Vous pouvez signer et vérifier les stratégies Admission Controller en utilisant des outils d’images de conteneurs comme cosign, du projet Sigstore project.

Vous pouvez distribuer les stratégies Admission Controller entre des registres de conteneurs géographiquement distribués en utilisant les outils et processus traditionnels adoptés pour les images de conteneurs.

Tant OPA Gatekeeper que Admission Controller sont gérés en utilisant des méthodologies GitOps.

Cependant, pour OPA Gatekeeper, il existe un couplage entre le code Rego de la stratégie et la ressource personnalisée utilisée pour le déployer dans Kubernetes. Cela introduit des étapes supplémentaires dans les pipelines CI/CD.

Rego dispose de outils de test permettant la création de suites de tests unitaires. Écrire des tests et les exécuter dans un pipeline CI/CD est essentiel pour garantir que les stratégies se comportent comme prévu.

Pour utiliser ces outils de test, le code source de la stratégie doit être disponible dans des fichiers texte dédiés. Il est impossible de lire le code source à partir des fichiers YAML utilisés pour déclarer la stratégie OPA Gatekeeper. Le pipeline CI/CD doit synchroniser le code source Rego à tester avec le code défini dans la ressource personnalisée OPA Gatekeeper. Vous pouvez le faire en utilisant des outils tiers.

Les stratégies Admission Controller ont des pipelines CI/CD comme des microservices traditionnels. Généralement, leur code source se trouve dans un dépôt Git et ensuite, en utilisant des systèmes CI/CD traditionnels, des tests unitaires sont exécutés contre celui-ci. Vous écrivez des tests unitaires en utilisant les frameworks de test du langage utilisé pour écrire la stratégie. Une fois que tous les tests passent, vous compilez la stratégie en WebAssembly et la poussez vers un registre de conteneurs. Ce type de pipeline est généralement maintenu par l’auteur de la stratégie.

Les administrateurs Kubernetes maintiennent généralement d’autres pipelines d’automatisation qui réagissent aux nouvelles versions de la stratégie (en utilisant des outils d’automatisation comme Dependabot, Renovate bot, updatecli et d’autres), ou aux modifications de la configuration de la stratégie.

Le pipeline teste la stratégie contre différents types de requêtes. Vous pouvez effectuer les tests en utilisant l’outil CLI kwctl, sans nécessiter un cluster Kubernetes en cours d’exécution. L’outil CLI kwctl utilise le même moteur d’évaluation que celui utilisé par la pile Admission Controller déployée dans un cluster Kubernetes.

Tant OPA Gatekeeper que Admission Controller peuvent déployer des stratégies en utilisant deux modes d’opération différents :

Le même serveur évalue toutes les stratégies OPA Gatekeeper. Inversement, Admission Controller permet la définition de plusieurs serveurs d’évaluation. Vous définissez ces serveurs par une ressource personnalisée appelée PolicyServer.

Lors de la déclaration d’une stratégie Admission Controller, l’administrateur Kubernetes décide quel PolicyServer l’héberge.

Cela permet des scénarios intéressants comme les suivants :

À mesure que des stratégies sont ajoutées, supprimées et reconfigurées, les ressources déjà présentes dans le cluster peuvent devenir non conformes.

À la fois OPA Gatekeeper et Admission Controller disposent d’un scanner qui fonctionne en arrière-plan. Ce scanner évalue les ressources déjà définies dans le cluster et signale celles qui ne sont pas conformes.

La seule différence entre OPA Gatekeeper et Admission Controller est la manière dont les résultats du scanner sont enregistrés.

OPA Gatekeeper ajoute les détails de violation au champ status d’une ressource personnalisée Constraint donnée (voir ici).

Admission Controller stocke plutôt les résultats dans un ensemble de ressources personnalisées de rapports définies par openreports.io.