OPA Gatekeeper : une cinquantaine de politiques, de l'audit à l'enforcement

Contexte

De bonnes pratiques dans un wiki n’empêchent pas un déploiement risqué. Les objectifs étaient explicites : bloquer les mauvaises pratiques, standardiser les déploiements et réduire la surface d’attaque, sur trois clusters (production, pré-production, outils internes).

Comment c’est construit

• Un chart maison portant une cinquantaine de ConstraintTemplates issues de la bibliothèque officielle Gatekeeper : sécurité des conteneurs (root, élévation de privilèges, filesystem en lecture seule, capabilities, seccomp), registries de confiance et pas de :latest, ressources, labels et sondes, isolation de l’hôte, services exposés.
• Déployé par un ApplicationSet ArgoCD (clusters × values par cluster), les templates avant les constraints via les sync waves. Le piège du bootstrap des CRD sur un cluster neuf est documenté.
• Enforcement par environnement : warn en pré-production, deny en production pour les politiques critiques, une politique à la fois.

L’audit s’est remboursé tout seul

En pré-production, le mode audit a fait remonter environ 2 700 violations. Les lire a révélé deux erreurs de configuration qui auraient bloqué tout le cluster en mode deny : une liste de storage classes autorisées vide parce que Gatekeeper ne synchronisait pas cette ressource, et une liste d’images autorisées laissée vide. Les deux ont été corrigées avant l’enforcement.

Exceptions et limites, écrites noir sur blanc

• Les exemptions sont par namespace et justifiées en ligne (sécurité runtime, node exporter, driver CSI des secrets, client VPN). Pas de contournement par annotation, volontairement : aucune porte de sortie non tracée.
• Les limites connues sont documentées plutôt que cachées : les CRD IngressRoute de Traefik ne sont pas couvertes par les templates d’ingress natifs, et les valeurs secrètes en variables d’environnement sont hors de portée de Gatekeeper. Ce risque est traité par Vault et par le scan de secrets en CI.

Observable

Métriques et cinq règles d’alerte Prometheus (violations, refus, audit périmé, erreurs et latence du webhook) routées vers Slack, plus une interface de consultation des politiques en lecture seule avec SSO sur les trois clusters.

Résultat

La plateforme est passée de « recommandé » à « imposé » sans panne surprise. Prochaines étapes : contrôles en CI avant merge (shift-left) et une politique imposant une NetworkPolicy dans chaque namespace.