Logo Ippon Technologies
Image représentant la sécurité dans Kubernetes
KubeConKubernetesSécuritéDevOps

KubeCon 2025 : Renforcer la Sécurité de vos clusters Kubernetes

Arthur Planche 10 avr. 2025

La récente KubeCon 2025 a une fois de plus mis en lumière les enjeux cruciaux de la sécurité au sein des environnements Kubernetes. Parmi les nombreuses sessions et présentations, plusieurs thématiques fortes se sont dégagées, offrant des pistes concrètes pour renforcer la posture de sécurité de vos clusters. Cet article vous propose un tour d'horizon des points saillants concernant le Policy as Code, les avancées en matière de sécurité réseau et les dernières évolutions de l'outil Kyverno.

Policy as Code : L'Automatisation au Service de la Conformité

L'approche Policy as Code (PaC) continue de gagner en popularité, s'imposant comme une méthode efficace pour gérer et appliquer les politiques de sécurité au sein de Kubernetes. Le principe est simple : traduire les exigences de sécurité en code déclaratif, à l'instar de l'Infrastructure as Code (IaC). Cette approche offre de nombreux avantages, notamment une gestion centralisée, une application cohérente des règles et une intégration facilitée dans les pipelines CI/CD.

Schéma du cycle vie d’une Policy as Code
Schéma du cycle vie d’une Policy as Code

Différents types de politiques peuvent être gérées via le PaC dans Kubernetes :

  • RBAC (Role-Based Access Control) : pour la gestion des accès aux ressources.
  • Validating Webhooks et Admission Webhooks : pour intercepter et valider (ou bloquer) les requêtes API lors de la création ou modification de ressources. Pour rappel, un webhook est une technique permettant à un système d'envoyer automatiquement des données à un autre système via une requête HTTP, chaque fois qu'un événement spécifique se produit.
  • Network Policies : pour contrôler le trafic réseau entre les pods.
  • Quotas : pour la gestion des ressources consommées.

Si les Admission Webhooks offrent une grande flexibilité, leur complexité de mise en œuvre pour des vérifications simples a été soulignée. La tendance actuelle s'oriente vers des solutions plus légères et intégrées, à l'image des Validating Admission Policies (VAP) introduites par Kubernetes.

Les VAP, combinées aux VAP Bindings basés sur le Common Expression Language (CEL), offrent une alternative plus simple et moins verbeuse pour la validation. Le CEL est une nouveauté importante dans l'écosystème Kubernetes. Ce langage d'expression puissant et sûr, conçu pour l'évaluation de politiques, permet de définir des règles de validation de manière concise et sans effets de bord. Il facilite l'écriture de politiques complexes tout en restant relativement simple à comprendre.

Plusieurs outils facilitent l'adoption du Policy as Code dans Kubernetes. Parmi eux, on retrouve Gatekeeper, basé sur Open Policy Agent (OPA) et le langage Rego, et Kyverno, un moteur de politiques natif Kubernetes.

Gatekeeper permet une gestion centralisée des politiques pour les VAP et les webhooks d'admission traditionnels, offrant une séparation claire entre la logique des contraintes et leur application. Kyverno, quant à lui, se positionne comme une solution complète pour la gestion du cycle de vie des ressources Kubernetes, intégrant des fonctionnalités de validation, de mutation, de génération et d'audit.

Sécurité Réseau : Vers une Protection Renforcée et Simplifiée

La sécurité du réseau au sein des clusters Kubernetes est un autre pilier essentiel. La KubeCon 2025 a mis en avant les avancées significatives autour de solutions comme Cilium, Hubble et Tetragon.

Diagramme représentant l'architecture de Cilium, Hubble et Tetragon, montrant leur interaction au sein d'un cluster Kubernetes
Diagramme représentant l'architecture de Cilium, Hubble et Tetragon, montrant leur interaction au sein d'un cluster Kubernetes

Cilium, en tant que CNI (Container Network Interface) basé sur eBPF, offre des capacités de mise en réseau et de sécurité très performantes. Ses Cilium Network Policies vont au-delà des Network Policies Kubernetes classiques en opérant jusqu'à la couche 7 du modèle OSI, permettant un contrôle plus précis du trafic. L'utilisation du chiffrement WireGuard intégré à Cilium peut même remplacer des solutions de service mesh plus complexes pour la sécurisation des communications.

L'outil Hubble vient compléter Cilium en fournissant une observabilité riche du réseau Kubernetes, tandis que Tetragon, également basé sur eBPF et développé par l'équipe de Cilium, se concentre sur la sécurité en temps réel, avec des modes de monitoring et d'application de politiques, ainsi que des filtres basés sur CEL.

Une présentation a notamment souligné la capacité de Cilium à gérer des clusters de très grande échelle, avec l'expérience de Google sur un cluster de 63 000 nœuds. Les fonctionnalités clés de Cilium ayant permis cette scalabilité sont l'IPAM, la connectivité pod-to-pod, la gestion des services Kubernetes et l'observabilité via Hubble.

Concernant les Network Policies Kubernetes traditionnelles (v1), bien que stables depuis plusieurs années, elles présentent certaines limitations, notamment l'absence de règle de "deny" explicite, un scope limité au namespace et une gestion basée sur les adresses IP plutôt que sur les identités. Les Admin Network Policies, encore expérimentales, tentent de répondre à ces limitations en offrant un scope cluster-wide, le support du "deny" et une gestion basée sur l'isolation des tenants. Cependant, des défis subsistent en termes de scalabilité et de complexité.

Pour pallier ces problèmes, l'accent est mis sur l'utilisation d'identités immuables pour les pods, réduisant la surface d'attaque et assurant une prédictibilité des politiques. Si les Service Accounts Kubernetes sont une forme d'identité, leur lien avec le RBAC complexifie leur utilisation directe pour les politiques réseau.

Des solutions comme les Cilium Network Policies (avec leurs capacités layer 3, 4 et 7 et la gestion des règles "deny" au niveau cluster via les Admin CNP) et les Istio Authorization Policies (opérant aux couches 4 TLS et 7, basées sur l'identité des pods via le format SPIFFE et offrant des règles "deny" cluster-wide) apparaissent comme des pistes prometteuses pour construire des réseaux Kubernetes plus sécurisés. Actuellement, l'absence de standard unique souligne la complexité du sujet. En attendant, l'utilisation de labels sur les entités de politiques combinée à des admission controllers (comme Kyverno ou Gatekeeper) pour prévenir les modifications non autorisées, ainsi que l'adoption du mTLS pour l'identité, sont des pratiques courantes.

Kyverno : L'Évolution Continue du Policy Engine Natif Kubernetes

Kyverno s'est imposé comme un outil de choix pour l'implémentation du Policy as Code dans Kubernetes, grâce à son approche native et ses nombreuses fonctionnalités (contrôleur d'admission, scanner, capacités d'audit et de reporting). La KubeCon 2025 a été l'occasion de découvrir les dernières évolutions de cet outil.

L'adoption du CEL par Kubernetes pour les Validating et Mutating Admission Policies a naturellement conduit à des évolutions au sein de Kyverno. L'objectif est de simplifier l'expérience utilisateur et d'éviter les chevauchements entre les règles de validation/mutation traditionnelles de Kyverno et les nouvelles capacités offertes par les VAP et MAP basées sur CEL.

Le CEL est apparu comme un langage d'expression particulièrement pertinent, offrant plus de fonctionnalités que JMESPath, une riche librairie communautaire, l'absence d'effets de bord et une combinaison de simplicité et de puissance. La comparaison entre CEL et JMESPath est pertinente dans ce contexte, les deux langages sont utilisés pour manipuler des données JSON, mais CEL offre une flexibilité bien supérieure. Tandis que JMESPath est conçu principalement pour extraire et interroger des données JSON, CEL va plus loin en permettant des expressions logiques complexes, une gestion fine des effets de bord, ainsi que la possibilité de définir des fonctions personnalisées. Cela en fait un choix idéal pour Kubernetes, où les politiques de validation et de mutation nécessitent non seulement de l'extraction de données, mais aussi des calculs et transformations plus sophistiqués.

Parmi les nouveautés de Kyverno, on retrouve l'introduction de cinq nouveaux types de policies, dont les deux validating attendues dès la prochaine release :

  • Validating Policies : Elles reprennent les fonctionnalités des VAP Kubernetes tout en y ajoutant les avantages de Kyverno, comme la gestion de variables, les fonctions CEL personnalisées, les annotations d'audit et la gestion des payloads JSON.
  • Image Validating Policies : Basées sur les VAP, elles permettent de vérifier les signatures, les attestations et les payloads d'attestation des images. Elles supportent différents types d'attestateurs (Cosign Key, KMS, Notary Ancestors) et offrent un accès aux payloads JSON et à des expressions CEL complexes dans les blocs de validation.
  • Mutating Policies : Pour modifier les ressources lors de leur création ou mise à jour.
  • Generating Policies : Pour créer de nouvelles ressources en réponse à d'autres événements.
  • Clean Up Policies : Pour automatiser la suppression de ressources en fonction de critères définis.

Ces évolutions témoignent de l'engagement continu de la communauté Kyverno à fournir un outil puissant et adapté aux besoins changeants de la sécurité des clusters Kubernetes.

Conclusion

La KubeCon 2025 a confirmé l'importance cruciale de la sécurité dans l'écosystème Kubernetes. Les avancées autour du Policy as Code, les solutions innovantes pour la sécurité réseau comme Cilium et les évolutions constantes d'outils comme Kyverno offrent aux équipes les moyens de construire et d'opérer des clusters Kubernetes plus sécurisés et conformes. L'adoption de ces pratiques et technologies est essentielle pour tirer pleinement parti des avantages de Kubernetes tout en minimisant les risques.

Sources

Author image
Arthur Planche
Consultant Cloud & DevOps
Lyon LinkedIn