Sécurité Kubernetes : guide complet pour protéger vos clusters en production

Kubernetes s'est imposé comme le standard de l'orchestration de conteneurs, avec plus de 84 % des entreprises qui l'utilisent en production selon le rapport CNCF 2025. Mais cette adoption massive s'accompagne de défis de sécurité considérables. Un cluster Kubernetes mal configuré peut exposer l'intégralité de votre infrastructure à des attaques dévastatrices. Ce guide détaille les risques, les bonnes pratiques et les outils indispensables pour sécuriser vos clusters Kubernetes en production.

Pourquoi la sécurité Kubernetes est un enjeu critique

Kubernetes introduit une surface d'attaque étendue et complexe. L'API Server, le plan de contrôle, les nœuds, les pods, les conteneurs, les réseaux overlay, les secrets, les registres d'images — chaque composant est un vecteur d'attaque potentiel. Les incidents de sécurité liés à Kubernetes ont augmenté de 67 % entre 2023 et 2025 selon le rapport Red Hat sur la sécurité Kubernetes.

Les conséquences d'une compromission Kubernetes sont particulièrement graves : accès à toutes les applications du cluster, exfiltration de secrets et de données, déploiement de cryptomineurs, mouvement latéral vers d'autres services cloud, et dans les cas les plus graves, prise de contrôle complète de l'infrastructure cloud sous-jacente via les métadonnées d'instances (IMDS).

Les 10 risques de sécurité Kubernetes les plus critiques

1. Images de conteneurs vulnérables

Les images de conteneurs sont le premier vecteur d'attaque dans un environnement Kubernetes. Une image qui contient des vulnérabilités connues (CVE) est une porte ouverte pour les attaquants. Selon Sysdig (2025), 87 % des images de conteneurs en production contiennent au moins une vulnérabilité critique ou haute. Le problème est aggravé par l'utilisation d'images de base volumineuses (Ubuntu, Debian) qui incluent des centaines de packages inutiles et autant de surfaces d'attaque.

Les bonnes pratiques incluent l'utilisation d'images de base minimales (Alpine, Distroless, scratch), le scanning systématique des images avec Trivy, Grype ou Snyk dans la pipeline CI/CD, la signature des images avec Cosign pour garantir leur intégrité, et l'utilisation d'un registre privé avec des politiques d'admission qui bloquent les images non conformes.

2. RBAC mal configuré

Le Role-Based Access Control (RBAC) est le mécanisme d'autorisation de Kubernetes. Un RBAC mal configuré — trop de ClusterRoleBindings avec le rôle cluster-admin, des ServiceAccounts avec des permissions excessives, des wildcards dans les règles — permet à un attaquant qui compromet un pod d'escalader ses privilèges et de prendre le contrôle du cluster entier.

La règle d'or : appliquez le principe du moindre privilège de manière stricte. Chaque namespace doit avoir ses propres rôles et bindings. Aucun ServiceAccount ne devrait avoir plus de permissions que ce dont l'application a besoin pour fonctionner. Auditez régulièrement les ClusterRoleBindings avec des outils comme kubectl-who-can ou rbac-police.

3. Absence de Network Policies

Par défaut, tous les pods d'un cluster Kubernetes peuvent communiquer entre eux sans restriction. C'est le rêve de tout attaquant : une fois un pod compromis, il peut se déplacer latéralement vers n'importe quel autre service du cluster. Les Network Policies sont l'équivalent des règles de firewall dans le monde Kubernetes, mais elles ne sont pas activées par défaut.

Implémentez des Network Policies qui appliquent le principe du « deny all, allow explicit ». Chaque namespace doit avoir une politique par défaut qui bloque tout le trafic entrant et sortant, puis des règles explicites pour autoriser uniquement les communications nécessaires. Utilisez Calico ou Cilium comme CNI (Container Network Interface) pour des politiques réseau avancées avec filtrage L7.

4. Secrets exposés en clair

Les Secrets Kubernetes sont encodés en base64 par défaut — ce n'est pas du chiffrement. Quiconque a accès à l'API Server ou à etcd peut lire tous les secrets du cluster. Les erreurs courantes incluent le stockage de secrets dans les variables d'environnement des manifestes (visibles dans le code source), l'absence de chiffrement d'etcd au repos, et le manque de rotation des secrets.

Utilisez un gestionnaire de secrets externe comme HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault, intégré à Kubernetes via le CSI Secret Store Driver. Activez le chiffrement d'etcd au repos avec un KMS externe. Implémentez la rotation automatique des secrets et limitez l'accès aux secrets via RBAC au niveau du namespace.

5. Pod Security non configuré

Un conteneur qui tourne en tant que root, qui a accès au filesystem de l'hôte ou qui peut monter des volumes hostPath peut compromettre le nœud entier. Les Pod Security Standards (PSS) — qui remplacent les anciennes PodSecurityPolicies — définissent trois niveaux de sécurité : Privileged (aucune restriction), Baseline (restrictions minimales) et Restricted (restrictions maximales).

Appliquez au minimum le niveau Baseline sur tous vos namespaces de production, et le niveau Restricted pour les workloads sensibles. Configurez les Pod Security Admission (PSA) labels sur chaque namespace. Vérifiez que vos pods ne tournent jamais en root (runAsNonRoot: true), ne demandent pas de capabilities dangereuses et n'utilisent pas de volumes hostPath.

6. API Server exposé publiquement

L'API Server est le cerveau de Kubernetes. S'il est exposé sur Internet sans protection adéquate, c'est l'équivalent de laisser la porte d'entrée de votre datacenter grande ouverte. Les attaques automatisées scannent en permanence Internet à la recherche d'API Servers Kubernetes exposés.

Restreignez l'accès à l'API Server via des listes d'adresses IP autorisées, utilisez un bastion ou un VPN pour l'administration, activez l'audit logging pour tracer toutes les requêtes, et désactivez l'accès anonyme. Sur les services managés (EKS, AKS, GKE), utilisez l'endpoint privé du cluster.

7. Absence de monitoring et d'audit

Sans monitoring de sécurité, vous ne pouvez pas détecter les attaques en cours. Les logs d'audit Kubernetes tracent toutes les actions effectuées via l'API Server, mais ils ne sont pas activés par défaut dans toutes les configurations. Sans eux, vous volez à l'aveugle.

Activez l'audit logging Kubernetes avec une politique qui capture les événements critiques (création/suppression de pods, modifications RBAC, accès aux secrets). Déployez Falco pour la détection des comportements suspects au niveau runtime (exécution de shell dans un conteneur, accès aux métadonnées cloud, modification de fichiers sensibles). Centralisez tous les logs dans un SIEM pour la corrélation et l'alerting.

8. Supply chain des images non sécurisée

La supply chain des conteneurs est un vecteur d'attaque de plus en plus ciblé. Des images publiques compromises sur Docker Hub, des dépendances malveillantes dans les layers d'images, des pipelines CI/CD qui construisent des images sans vérification — autant de risques qui peuvent introduire du code malveillant directement dans votre production.

Signez vos images avec Cosign et vérifiez les signatures à l'admission avec des Policy Engines comme Kyverno ou OPA Gatekeeper. Générez des SBOM (Software Bill of Materials) pour chaque image avec Syft. N'utilisez que des images provenant de registres privés de confiance et maintenez vos images de base à jour.

9. Ressources non limitées

Un pod sans limites de ressources (CPU, mémoire) peut consommer toutes les ressources d'un nœud, impactant les autres workloads. C'est le vecteur principal des attaques de déni de service internes et du cryptomining. Un attaquant qui compromet un pod peut lancer un cryptomineur qui consomme 100 % des ressources disponibles.

Définissez des ResourceQuotas et LimitRanges sur chaque namespace. Chaque pod doit avoir des requests et limits explicites pour le CPU et la mémoire. Surveillez la consommation anormale de ressources avec Prometheus et alertez sur les pics inexpliqués.

10. Manque de segmentation des environnements

Faire tourner dev, staging et production sur le même cluster sans isolation stricte est un risque majeur. Une compromission de l'environnement de développement — souvent moins sécurisé — peut se propager à la production.

Idéalement, utilisez des clusters séparés pour la production. Si vous mutualisez, utilisez des namespaces avec des Network Policies strictes, des ResourceQuotas, et du RBAC granulaire pour isoler les environnements. Envisagez l'utilisation de virtual clusters (vCluster) pour une isolation renforcée sans le surcoût de clusters séparés.

Architecture de sécurité Kubernetes recommandée

Couche 1 : Pipeline CI/CD sécurisée

La sécurité commence bien avant le déploiement. Votre pipeline CI/CD doit intégrer le scanning d'images (Trivy), l'analyse statique des manifestes Kubernetes (Kubesec, Checkov), la signature d'images (Cosign), la génération de SBOM et les tests de conformité aux politiques. Tout artefact qui ne passe pas ces vérifications est bloqué avant d'atteindre le cluster.

Couche 2 : Admission Control

Les Admission Controllers sont le dernier rempart avant le déploiement. OPA Gatekeeper ou Kyverno vérifient que chaque ressource déployée respecte vos politiques de sécurité : images signées, pas de conteneurs root, limites de ressources définies, labels requis présents. C'est votre filet de sécurité automatisé.

Couche 3 : Runtime Security

En production, Falco surveille les comportements suspects au niveau système (syscalls) et alerte en temps réel sur les anomalies : shell exécuté dans un conteneur, accès aux métadonnées cloud, modification de fichiers critiques, communications réseau inhabituelles. Complétez avec un Service Mesh (Istio, Linkerd) pour le chiffrement mTLS entre services et le contrôle fin du trafic.

Couche 4 : Observabilité et réponse

Centralisez les logs d'audit Kubernetes, les alertes Falco, les métriques Prometheus et les traces distribuées dans une plateforme d'observabilité. Configurez des alertes automatisées et des runbooks de réponse aux incidents. La capacité à détecter et à répondre rapidement est aussi importante que la prévention.

Checklist de sécurité Kubernetes pour la production

Voici une checklist actionnable pour évaluer la sécurité de vos clusters :

✅ RBAC configuré avec le principe du moindre privilège, pas de cluster-admin généralisé

✅ Network Policies en deny-all par défaut avec exceptions explicites

✅ Pod Security Standards en mode Baseline ou Restricted sur tous les namespaces

✅ Images scannées automatiquement dans la pipeline CI/CD

✅ Secrets gérés par un gestionnaire externe (Vault, AWS SM, Azure KV)

✅ API Server non exposé publiquement, accès via VPN ou bastion

✅ Audit logging activé et centralisé

✅ Falco ou équivalent déployé pour la détection runtime

✅ ResourceQuotas et LimitRanges sur chaque namespace

✅ Images signées et vérifiées à l'admission

✅ etcd chiffré au repos avec KMS externe

✅ Rotation régulière des certificats et des secrets

Conclusion

La sécurité Kubernetes n'est pas un projet ponctuel — c'est une discipline continue qui s'intègre à chaque étape du cycle de vie des applications. La complexité de Kubernetes rend la sécurité plus difficile, mais les outils et les bonnes pratiques existent pour atteindre un niveau de protection élevé. Commencez par les fondamentaux — RBAC, Network Policies, Pod Security — puis progressez vers la détection runtime et la sécurisation de la supply chain. Chaque couche de sécurité ajoutée réduit considérablement votre exposition aux risques.