OPA Gatekeeper

devsecops

Définition

OPA Gatekeeper est un contrôleur d'admission Kubernetes open source (CNCF graduated project) qui permet d'appliquer des politiques de sécurité et de conformité sur les ressources Kubernetes en utilisant l'Open Policy Agent (OPA) et le langage de politiques Rego. Gatekeeper s'intègre avec le mécanisme d'admission control de Kubernetes : chaque ressource créée ou modifiée dans le cluster passe par Gatekeeper avant d'être acceptée, permettant l'application de politiques de sécurité au niveau de l'API Kubernetes. Gatekeeper introduit deux Custom Resource Definitions (CRD) Kubernetes : les ConstraintTemplates (définissent les politiques en Rego — modèles réutilisables) et les Constraints (instances des ConstraintTemplates appliquées à des ressources spécifiques — configurent l'enforcement). Cette séparation permet de définir une politique générique (par exemple "les containers doivent avoir des resource limits") via un ConstraintTemplate, puis de l'appliquer à différents namespaces ou avec différentes configurations via des Constraints. Les cas d'usage de sécurité de Gatekeeper dans Kubernetes incluent : l'interdiction des conteneurs privilégiés (privileged: true), l'obligation des resource limits (CPU et mémoire), l'obligation du runAsNonRoot (interdiction des containers s'exécutant en root), la validation des registres d'images autorisés (seules les images depuis ghcr.io/myorg/ sont autorisées), l'obligation des labels de sécurité (chaque déploiement doit avoir des labels owner et security-review-date), et l'obligation des PodDisruptionBudgets pour les workloads critiques. OPA Gatekeeper fonctionne en mode synchrone (Validating Webhook) ou asynchrone (Audit mode) : le mode Validating Webhook rejette les ressources non conformes lors de leur création/modification, le mode Audit identifie les ressources existantes non conformes à une politique nouvellement déployée. La combinaison des deux modes permet une application stricte pour les nouveaux déploiements et une remédiation progressive pour les ressources existantes.

Écrire une ConstraintTemplate Gatekeeper en Rego

Structure d'une ConstraintTemplate Gatekeeper : apiVersion: templates.gatekeeper.sh/v1, kind: ConstraintTemplate, metadata.name: k8srequiredlabels, spec.crd.spec.names.kind: K8sRequiredLabels, spec.crd.spec.validation.openAPIV3Schema définissant les paramètres (liste de labels requis), spec.targets.target: admission.k8s.gatekeeper.sh avec la politique Rego : package k8srequiredlabels; violation[{"msg": msg}] { provided := {label | input.review.object.metadata.labels[label]}; required := {label | label := input.parameters.labels[_]}; missing := required - provided; count(missing) > 0; msg := sprintf("Labels manquants: %v", [missing])}. Une Constraint K8sRequiredLabels applique cette politique en définissant les labels requis spécifiques.

Bibliothèques de politiques Gatekeeper

La Gatekeeper Policy Library (github.com/open-policy-agent/gatekeeper-library) fournit une collection de ConstraintTemplates préconfigurées pour les cas d'usage les plus courants : PSP (Pod Security Policy) migration (runAsNonRoot, allowPrivilegeEscalation, volumes autorisés), network security (egress et ingress autorisés), et best practices générales (replica counts, resource limits). Ces templates prêts à l'emploi réduisent l'effort de démarrage avec Gatekeeper. La migration des PodSecurityPolicies (dépréciées dans Kubernetes 1.21, supprimées en 1.25) vers Gatekeeper est un cas d'usage courant d'adoption.

Gatekeeper vs Kyverno : choisir son admission controller

Gatekeeper et Kyverno couvrent les mêmes besoins avec des approches différentes : Gatekeeper (OPA/Rego, plus expressif pour les politiques complexes, courbe d'apprentissage Rego, meilleure intégration avec les workflows OPA existants), Kyverno (YAML natif Kubernetes, plus simple à prendre en main, capacités de génération et de mutation en plus de la validation, meilleur pour les équipes sans expérience OPA). Pour les équipes utilisant déjà OPA, Gatekeeper est naturel. Pour les équipes Kubernetes-centric cherchant une solution native, Kyverno est souvent plus accessible. Les deux peuvent coexister dans un cluster pour des cas d'usage complémentaires.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis