Sécuriser Kubernetes : les 8 erreurs de configuration les plus fréquentes et comment les corriger

Votre équipe DevOps vient de mettre en place le premier cluster de production, les microservices tournent, et le RSSI demande le concept de sécurité. La réponse est généralement insuffisante. Car la plupart des violations Kubernetes ne résultent pas d’exploits zero-day sophistiqués, mais de mauvaises configurations qui peuvent être corrigées en moins d’une heure. Connaître les huit erreurs les plus courantes permet de renforcer votre cluster en cinq jours ouvrés.

L’essentiel en bref

• 90 pour cent des entreprises disposant d’environnements Kubernetes ont subi au moins un incident de sécurité au cours de l’année écoulée (Red Hat State of Kubernetes Security Report 2024).
• 45 pour cent de ces incidents sont causés par des erreurs de configuration, et non par des vulnérabilités dans le code ou des attaques ciblées.
• Les Pod Security Standards remplacent les Pod Security Policies obsolètes depuis Kubernetes 1.25 et définissent trois niveaux de sécurité obligatoires.
• 87 pour cent des images de conteneurs en production contiennent des vulnérabilités critiques ou élevées, car des images de base obsolètes sont réutilisées sans vérification (Sysdig 2025).
• Un programme de renforcement structuré peut être mis en place en cinq jours ouvrés grâce aux huit étapes décrites ici.

Pourquoi les erreurs de configuration constituent le plus grand risque Kubernetes

Kubernetes est complexe. Un seul cluster comporte plusieurs centaines de paramètres de configuration, répartis entre les Pods, les Services, les Network Policies, les rôles RBAC et les Admission Controllers. Le risque réside dans cette complexité : ce n’est pas l’attaquant exploitant une nouvelle vulnérabilité qui ouvre la porte, mais l’administrateur qui néglige un paramètre par défaut.

Les chiffres sont sans appel. Selon le Red Hat State of Kubernetes Security Report 2024, 90 pour cent des entreprises interrogées disposant d’environnements Kubernetes ont subi au moins un incident de sécurité au cours de l’année écoulée. 46 pour cent ont signalé des pertes concrètes de chiffre d’affaires ou de clients comme conséquence directe. Et 67 pour cent ont dû retarder leurs déploiements en raison de préoccupations de sécurité bloquant la mise en production.

Le moteur de ces chiffres est la diffusion rapide des conteneurs dans les environnements de production. Selon l’enquête annuelle CNCF 2025, 56 pour cent des entreprises exploitent désormais des conteneurs en production. En 2023, ce chiffre n’était que de 41 pour cent. Chaque nouveau cluster augmente la surface d’attaque lorsque les configurations de sécurité de base ne sont pas définies dès le départ.

Gartner prévoit que d’ici 2026, 99 pour cent de tous les incidents de sécurité cloud seront imputables aux clients. Les fournisseurs cloud ne sont pas le problème. Ce sont les équipes qui configurent les clusters sans remettre en question les paramètres par défaut. La bonne nouvelle : connaître les erreurs de configuration les plus fréquentes permet de les éliminer systématiquement.

Les 8 erreurs de configuration les plus fréquentes et leurs solutions

Les huit erreurs de configuration suivantes couvrent la majorité de la surface d’attaque réelle. Chacune peut être corrigée de manière ciblée sans perturber les opérations en cours. L’ordre est basé sur le risque : les configurations les plus dangereuses figurent en premier.

Pod Security Standards : le nouveau standard minimum

Depuis Kubernetes 1.25, les Pod Security Policies (PSP) obsolètes ont été supprimées. Elles sont remplacées par les Pod Security Standards (PSS) avec le Pod Security Admission Controller intégré. Celui-ci définit trois niveaux de sécurité appliqués au niveau du namespace.

Le niveau Privileged autorise tout et est réservé aux workloads système. Baseline empêche les chemins d’escalade de privilèges connus et devrait constituer le minimum absolu pour chaque namespace. Restricted applique les bonnes pratiques actuelles de renforcement des pods et constitue l’objectif pour tous les workloads ne nécessitant pas explicitement des privilèges élevés.

La mise en oeuvre se fait via des labels sur le namespace. Un seul label suffit pour activer le niveau de sécurité souhaité. Les équipes qui n’ont pas encore mis en place de mécanismes de sécurité pod devraient commencer par le niveau Baseline en mode audit et passer au mode enforce dans un délai de quatre à six semaines.

L’utilisation complémentaire de moteurs de politiques comme Kyverno ou Open Policy Agent (OPA) avec Gatekeeper est recommandée. Ils permettent un contrôle plus fin que les Pod Security Standards intégrés. Falco, qui compte désormais plus de 22 millions de téléchargements en tant que projet CNCF Graduated, offre une sécurité runtime complémentaire en détectant les comportements suspects dans les conteneurs en temps réel.

Checklist : renforcer votre cluster Kubernetes en cinq jours

Jour 1 : Inventaire et audit RBAC

• Lister tous les ClusterRoleBindings et RoleBindings et vérifier les permissions excessives
• Identifier les service accounts par défaut auxquels des rôles ont été attribués
• Vérifier l’accessibilité du serveur API et la restreindre si nécessaire
• Inventorier tous les namespaces et documenter leurs exigences de sécurité

Jour 2 : Activer les Pod Security Standards

• Définir la politique Baseline en mode audit pour tous les namespaces
• Analyser les violations et adapter les workloads
• Déplacer les conteneurs privilégiés dans des namespaces dédiés
• Configurer le SecurityContext pour tous les pods : runAsNonRoot, readOnlyRootFilesystem

Jour 3 : Réseau et Secrets

• Mettre en place des Network Policies default-deny pour les namespaces sensibles
• Autoriser explicitement les connexions requises et les documenter
• Activer le chiffrement au repos pour etcd
• Passer les secrets des variables d’environnement aux montages de volumes

Jour 4 : Intégration CI/CD et hygiène des images

• Intégrer des scanners d’images comme Trivy dans le pipeline de build
• Définir et appliquer une liste d’images de base autorisées
• Configurer les resource limits et LimitRanges par namespace
• Mettre en place des ResourceQuotas pour les équipes partageant le cluster

Jour 5 : Monitoring, alerting et documentation

• Activer l’audit logging de l’API et le connecter à un SIEM central
• Configurer l’alerting pour les tentatives d’authentification échouées et les violations de politique
• Évaluer un outil de sécurité runtime comme Falco et le déployer en environnement de test
• Documenter toutes les modifications et établir un cycle de revue trimestriel

Conclusion : commencez par l’audit RBAC

La sécurité Kubernetes n’est pas un projet que l’on termine et que l’on oublie. C’est un processus continu qui commence par un inventaire honnête. Les huit erreurs de configuration décrites ici couvrent la majorité de la surface d’attaque réelle. Aucune ne nécessite un nouvel outil ou un projet de conseil externe.

Commencez cette semaine par l’audit RBAC et activez les Pod Security Standards en mode audit. En cinq jours, vous disposerez d’un environnement nettement renforcé. L’investissement se résume à cinq jours ouvrés de travail ciblé. Le retour consiste à ne pas figurer parmi les 46 pour cent qui perdent du chiffre d’affaires et des clients après un incident de sécurité Kubernetes. Et n’oubliez pas : la sécurité dans Kubernetes n’est pas un état statique. Chaque mise à jour de cluster, chaque nouvelle dépendance et chaque namespace supplémentaire mérite un regard neuf sur la configuration.

Questions fréquentes

Chaque question est verrouillée. Un clic déverrouille la réponse.

Quels sont les risques de sécurité Kubernetes les plus courants ?

Les risques les plus courants sont les erreurs de configuration RBAC, les conteneurs privilégiés sans restriction, les Network Policies manquantes, les secrets non chiffrés et les conteneurs exécutés en tant que root. Selon le Red Hat State of Kubernetes Security Report 2024, 45 pour cent des incidents de sécurité Kubernetes sont dus à des erreurs de configuration.

Que sont les Pod Security Standards dans Kubernetes ?

Les Pod Security Standards (PSS) sont un mécanisme de sécurité intégré à Kubernetes depuis la version 1.25, remplaçant les Pod Security Policies obsolètes. Ils définissent trois niveaux : Privileged pour les workloads système, Baseline comme standard minimum contre l’escalade de privilèges, et Restricted comme renforcement selon les bonnes pratiques pour tous les workloads réguliers.

Comment sécuriser le serveur API Kubernetes ?

Le serveur API ne devrait pas être accessible publiquement. Placez-le derrière un VPN ou un bastion host. Restreignez l’accès aux plages IP connues et activez l’audit logging de l’API. Attribuez les permissions RBAC selon le principe du moindre privilège et utilisez des tokens à durée de vie courte.

Quels outils aident à sécuriser Kubernetes ?

Pour le scan d’images : Trivy, Grype ou Snyk Container. Pour la sécurité runtime : Falco et Sysdig détectent les activités suspectes en temps réel. Pour l’application des politiques : Kyverno et Open Policy Agent avec Gatekeeper sont des solutions éprouvées intégrables dans le pipeline CI/CD.

Combien de temps faut-il pour sécuriser un cluster Kubernetes ?

Le renforcement de base d’un cluster Kubernetes peut être réalisé en cinq jours ouvrés : audit RBAC, Pod Security Standards, Network Policies, gestion des secrets et intégration CI/CD. L’ajustement fin et le monitoring continu constituent un processus permanent à intégrer dans les opérations régulières.