Bonnes pratiques de sécurité Kubernetes : durcissement du build au runtime

Kubernetes est livré avec des paramètres par défaut permissifs, la sécurité du cluster vous incombe donc. Découvrez les bonnes pratiques de sécurité Kubernetes pour les phases de build, de déploiement et de runtime.

Qu’est-ce que la sécurité Kubernetes ?

La sécurité Kubernetes est l’ensemble des contrôles que vous appliquez à la compilation, au déploiement et à l’exécution afin de protéger un cluster, les charges de travail qu’il exécute et le pipeline qui l’alimente. Sans eux, une seule requête non authentifiée peut prendre le contrôle de l’ensemble de votre cluster. C’était le cas d’IngressNightmare, la faille de gravité 9,8 divulguée en mars 2025 dans ingress-nginx, le contrôleur exécuté dans plus de 40 % des clusters Kubernetes.

Son webhook d’admission se trouvait sur le réseau des pods sans authentification, et ingress-nginx lit par défaut chaque Secret du cluster. Atteignez le réseau, prenez le contrôle du cluster. Il n’a fallu ni chaîne d’exploitation ni mot de passe volé : seulement des paramètres par défaut permissifs faisant ce pour quoi ils avaient été configurés.

Cet écart, entre ce que Kubernetes fournit et ce dont un cluster de production a besoin, est précisément ce que le durcissement permet de combler. Les bonnes pratiques de sécurité Kubernetes sont la manière de le combler, phase par phase, de l’image que vous créez à la charge de travail que vous exécutez. Parce que l’orchestration centralise vos charges de travail, vos secrets et votre trafic est-ouest dans un seul plan de contrôle, une seule mauvaise configuration peut exposer chaque service que vous exécutez, c’est pourquoi cette responsabilité vous incombe plutôt qu’à la plateforme.

Pourquoi la sécurité Kubernetes est-elle importante ?

Kubernetes ne se durcit pas lui-même. Le guide de durcissement Kubernetes CISA/NSA documente trois paramètres par défaut révélateurs sur chaque nouveau cluster : la connexion anonyme au serveur API est activée, les Secrets sont stockés sans chiffrement dans etcd et la journalisation d’audit est désactivée. Le modèle de responsabilité partagée place quatre contrôles entre vos mains : le contrôle d’accès basé sur les rôles (RBAC), la politique réseau, le chiffrement des secrets et les contrôles d’exécution. Le fournisseur cloud ne les configurera pas pour vous, pas plus que la distribution. Parce que ces contrôles résident dans votre configuration et dérivent au fil du temps, les équipes les vérifient de plus en plus en continu avec la gestion de la posture de sécurité Kubernetes au lieu de les auditer manuellement.

Un attaquant qui atteint un serveur API non authentifié peut lire chaque Secret dans etcd, planifier un pod sur n’importe quel nœud et se déplacer entre les espaces de noms tandis que la journalisation d’audit reste silencieuse ; ainsi, le premier signal que vous recevez peut être la violation elle-même. Un seul point de terminaison exposé devient un accès à l’échelle du cluster en quelques minutes, selon le même schéma qu’IngressNightmare.

Les enjeux augmentent avec l’adoption. L’enquête annuelle Cloud Native de la Cloud Native Computing Foundation (CNCF) indique que 82 % des utilisateurs de conteneurs exécutent désormais Kubernetes en production, contre 66 % en 2023. À mesure que les clusters se trouvent sur le chemin des services orientés client, des données réglementées et des obligations d’audit, un seul contrôle manqué se transforme en exposition à une violation, en audits échoués et en incidents à déclarer auxquels votre équipe devra répondre. Savoir ce qui est en jeu n’a d’importance qu’une fois que vous savez quelles parties du cluster portent ce risque.

Composants principaux d’un cluster Kubernetes

Vous ne pouvez pas durcir ce que vous n’avez pas inventorié. Chaque composant présente une exposition de sécurité spécifique, et comprendre cette exposition vous indique où vos contrôles doivent s’appliquer.

Composants du plan de contrôle :

• Serveur API : Chaque commande kubectl que vous exécutez, chaque webhook d’admission et chaque demande de jeton de compte de service passe par le serveur API. Un accès non autorisé ici signifie un contrôle total du cluster.
• etcd : Stocke tout l’état du cluster, la configuration et les Secrets dont vous dépendez. Un accès en lecture à etcd équivaut fonctionnellement à un accès root sur l’ensemble de votre cluster.
• Planificateur et gestionnaire de contrôleurs : Un planificateur compromis peut placer des charges de travail sur des nœuds spécifiques afin d’exploiter des ressources locales. La manipulation des contrôleurs peut modifier silencieusement les déploiements, le nombre de réplicas et les affectations de ressources.

Composants des nœuds de travail :

• kubelet: L’agent sur chaque nœud qui exécute les spécifications de pod. Si vous laissez l’API kubelet exposée, un attaquant peut créer des conteneurs ou exécuter des commandes directement sur le nœud.
• kube-proxy: Gère les règles réseau pour le routage des services. Des règles de proxy mal configurées peuvent exposer vos services internes à du trafic externe.
• Runtime de conteneur : Exécute les conteneurs sur l’hôte. Un runtime vulnérable expose chaque conteneur qu’il prend en charge ainsi que l’hôte lui-même, comme le note NIST SP 800-190.

Pods, conteneurs et réseau :

• Les pods partagent des espaces de noms réseau ; ainsi, un conteneur compromis dans un pod peut accéder à d’autres conteneurs du même pod sans contrôles réseau. Sans objets NetworkPolicy, vos pods dans différents espaces de noms communiquent librement par défaut. 
• Les images de conteneur et les modèles infrastructure-as-code (IaC) entrent dans votre cluster depuis des registres externes, et une image empoisonnée extraite en production se propage à chaque nœud qui la planifie. Associer chaque composant à son exposition vous indique exactement où s’appliquent les contrôles de durcissement de ce guide.

Comment la sécurité Kubernetes fonctionne sur l’ensemble du cycle de vie de la compilation à l’exécution

Vous sécurisez Kubernetes au moyen d’un workflow continu, et non d’une vérification ponctuelle. Chaque phase applique une catégorie de contrôle différente, et la sortie d’une phase devient l’entrée de la suivante. Voici ce qui se passe à chaque étape.

1. Moment de la compilation : Vous analysez les images de conteneur à la recherche de vulnérabilités connues, validez les modèles IaC par rapport à la politique, signez les images de manière cryptographique et générez une nomenclature logicielle (SBOM). Ces contrôles préventifs arrêtent les problèmes à la source, avant qu’un artefact puisse être planifié.
2. Déployer et configurer : Lorsque vous soumettez une charge de travail, les contrôleurs d’admission l’évaluent par rapport à la politique avant la planification. Le RBAC détermine qui peut créer, modifier ou lire des ressources, et les politiques réseau définissent quels pods peuvent communiquer. L’image que vous avez signée lors de la compilation n’est protégée ici que si le contrôle d’admission vérifie réellement la signature.
3. Configuration du plan de contrôle et des nœuds : Vous configurez le serveur API, etcd, kubelet et le système d’exploitation du nœud afin de réduire ce qui est exposé. L’authentification, l’autorisation et le chiffrement définissent la limite de confiance sur laquelle s’appuie chaque autre phase ; ainsi, un plan de contrôle faible affaiblit tout ce qui suit.
4. Exécution : Les outils de surveillance recherchent des anomalies comportementales, la dérive de configuration et des schémas d’attaque connus dans vos charges de travail en cours d’exécution, tandis que les profils seccomp et AppArmor limitent les appels système que vos conteneurs peuvent effectuer. L’exécution est également l’endroit où vous détectez les lacunes que la compilation et le déploiement ont manquées.

Vous bouclez la boucle lorsque les résultats d’exécution réinjectent dans votre phase de compilation des images mises à jour, une IaC mise à jour et une politique d’admission mise à jour. Le cycle de vie ne fonctionne que lorsque chaque transfert tient. Voici le coût d’un seul transfert défaillant.

Impact d’un cluster Kubernetes compromis

Lorsque votre cluster est compromis, les conséquences vont bien au-delà d’une seule charge de travail.

• Mouvement latéral et rayon d’impact : Vos clusters exécutent de dizaines à des milliers de pods partageant une connectivité réseau. Un attaquant qui obtient l’accès à l’un de vos pods peut se déplacer latéralement entre les espaces de noms et les nœuds lorsque le RBAC est trop permissif et que les politiques réseau sont absentes.
• Exposition des secrets : etcd contient vos clés API, identifiants de base de données, certificats TLS et jetons de service. Parce que les Secrets ne sont pas chiffrés par défaut, un attaquant disposant d’un accès en lecture à etcd peut extraire chaque identifiant de votre cluster.
• Propagation de la chaîne d’approvisionnement : Une image de conteneur empoisonnée déployée via votre pipeline d’intégration continue et de livraison continue (CI/CD) atteint chaque nœud qui la planifie. Dans les clusters exécutant des centaines de réplicas, une seule image compromise peut exécuter du code malveillant sur l’ensemble de votre infrastructure en quelques minutes.
• Compromission des charges de travail et des données : Vos bases de données de production, applications orientées client et services internes s’exécutent côte à côte. Une violation dans une charge de travail peut exposer des données sensibles, perturber la disponibilité du service ou établir une persistance pour de futures attaques.
• Exposition à la conformité et à la réglementation : Si vos clusters traitent des données de paiement, des dossiers de santé ou des charges de travail gouvernementales, ils relèvent des exigences PCI DSS, HIPAA, FedRAMP et SOC 2. Un cluster mal configuré qui échoue à un audit peut entraîner des arrêts opérationnels et des pénalités financières.

Le durcissement réduit le rayon d’impact de toute compromission unique, raccourcit les délais de réponse aux incidents et produit les preuves d’audit exigées par votre programme de conformité. Y parvenir en pratique est plus difficile qu’il n’y paraît, pour des raisons propres au fonctionnement de Kubernetes.

Défis de la sécurisation de Kubernetes

La sécurité Kubernetes est difficile sur le plan opérationnel, même pour les membres les plus expérimentés de votre équipe. L’éphémérité de la plateforme, son modèle de configuration déclaratif et son architecture distribuée créent des frictions que les outils de sécurité statiques n’ont pas été conçus pour gérer.

• Charges de travail éphémères et en constante évolution : Les pods sont créés, détruits et replanifiés en continu. Un instantané de posture de votre cluster à 9 h peut ne pas refléter son état à 9 h 05.
• Lacunes de visibilité dans les conteneurs en cours d’exécution : Les conteneurs partagent le noyau de l’hôte mais isolent leurs processus, systèmes de fichiers et piles réseau. Les outils de surveillance standard basés sur l’hôte manquent souvent du contexte nécessaire pour distinguer un comportement normal de conteneur d’une activité malveillante.
• Complexité de configuration et dérive : Un cluster de production implique des centaines de manifestes YAML, de liaisons RBAC et de règles d’admission. La dérive entre ce que vous déclarez dans Git et ce qui s’exécute dans votre cluster introduit une exposition non suivie.
• Prolifération multi-cluster et multi-cloud : Si vous exécutez des clusters sur Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP) et des environnements sur site, vous devez appliquer une politique cohérente sur différents services managés, chacun avec sa propre limite de responsabilité partagée.
• Outillage fragmenté : L’analyse d’images, la gestion RBAC, l’application des politiques réseau, la surveillance de l’exécution et le reporting de conformité nécessitent souvent des outils distincts sans modèle de données partagé. La corrélation des alertes vous incombe.
• Compétences et frictions organisationnelles : Les compétences spécialisées sont rares, et l’enquête CNCF 2025 a constaté que, pour la première fois, le principal frein à l’adoption du cloud native est organisationnel plutôt que technique : communication interne, dynamique d’équipe et alignement de la direction. Les contrôles ne sont pas appliqués parce que personne n’en est responsable.

Ces contraintes façonnent à la fois vos choix d’outils et vos priorités de recrutement, et elles expliquent pourquoi les mêmes erreurs se répètent d’un cluster à l’autre.

Erreurs courantes de sécurité Kubernetes

Des anti-modèles d’exploitation spécifiques créent les expositions que les attaquants exploitent. Identifiez et éliminez chacune d’elles dans vos clusters :

• Exécuter des conteneurs privilégiés ou root. Les conteneurs privilégiés contournent toute l’isolation du noyau Linux. Un conteneur exécuté en tant que root avec allowPrivilegeEscalation: true peut s’échapper vers l’hôte.
• Accorder cluster-admin ou un RBAC générique. Les autorisations génériques (resources: ["*"], verbs: ["*"]) s’étendent automatiquement aux ressources API qui n’existent pas encore. La documentation Kubernetes qualifie ce modèle de « DO NOT USE ».
• Laisser en place une mise en réseau par défaut autorisante. Sans objets NetworkPolicy, vos pods dans différents espaces de noms communiquent librement.
• Stocker des Secrets dans des manifestes en clair. Valider des identifiants dans Git ou les transmettre comme variables d’environnement les expose dans les vidages sur incident, les journaux et l’historique du shell.
• Ignorer l’analyse des images et de l’IaC. Déployer des images non analysées permet aux vulnérabilités d’atteindre la production sans contrôle.
• Traiter le durcissement comme un contrôle ponctuel. Un cluster durci au bootstrap dérive à mesure que vos équipes ajoutent des charges de travail et modifient les configurations. Sans application continue, la posture se dégrade.
• Ignorer la configuration des nœuds et du plan de contrôle. Laisser activée la connexion anonyme au serveur API, ignorer le chiffrement d’etcd et omettre la journalisation d’audit sont des états par défaut qui exigent votre remédiation explicite.

Chacune de ces erreurs peut être corrigée avec les pratiques ci-dessous. Considérez-les comme une liste de contrôle des expositions à éliminer avant de faire évoluer des charges de travail supplémentaires sur le cluster.

Bonnes pratiques de sécurité Kubernetes

Ces bonnes pratiques de sécurité Kubernetes constituent le cœur opérationnel du durcissement des clusters Kubernetes, organisées selon les quatre mêmes phases du cycle de vie présentées ci-dessus. Suivez-les dans l’ordre, car chaque phase suppose que la précédente tient.

Sécuriser la phase de compilation

1. Analysez les images à la recherche de vulnérabilités avant qu’elles n’atteignent un registre. Intégrez l’ analyse des images de conteneur à vos pipelines CI afin que les images vulnérables ne deviennent jamais des artefacts déployables.
2. Utilisez des images de base minimales ou distroless. Les images distroless ne contiennent que votre application et ses dépendances d’exécution, sans shell, gestionnaire de paquets ni binaires inutiles. Épinglez les images à des suffixes de version explicites (e.g., gcr.io/distroless/static-debian13) et n’utilisez jamais le latest tag.
3. Signez et vérifiez les images. Utilisez Cosign ou Notary pour signer les images dans CI. Configurez les contrôleurs d’admission pour rejeter les images non signées ou non vérifiées au moment du déploiement.
4. Analysez l’IaC et les manifestes Kubernetes. Validez Terraform, les charts Helm et le YAML brut par rapport à la politique de sécurité avant qu’ils n’atteignent votre cluster.
5. Générez un SBOM pour chaque image afin d’établir la provenance et de prendre en charge le suivi des vulnérabilités après le déploiement.
6. Gardez les secrets hors des images. N’intégrez jamais d’identifiants, de clés API ou de certificats dans les images de conteneur ou les Dockerfiles.

Ces contrôles de phase de compilation empêchent les artefacts vulnérables et non signés d’entrer dans le pipeline avant que quoi que ce soit puisse s’exécuter. Une image qui les franchit n’est encore sûre que si le cluster l’admet correctement, ce qui est le rôle de la configuration au moment du déploiement.

Durcir la configuration et le déploiement du cluster

Ces bonnes pratiques Kubernetes RBAC et ces contrôles réseau transforment la politique au moment du déploiement en garde-fous appliqués.

1. Appliquez le RBAC du moindre privilège. Créez des Roles à portée d’espace de noms avec des verbes explicites et des noms de ressources explicites. Éliminez les autorisations génériques. Réservez cluster-admin aux usages de secours. Définissez automountServiceAccountToken: false sur les comptes de service qui n’ont pas besoin d’accès à l’API.

2. Appliquez des politiques réseau par défaut de refus. Appliquez une Netwenforce mode avec le restrictedorkPolicy default-deny-all, à la fois en entrée et en sortie, à chaque espace de noms au bootstrap. Ajoutez des règles d’autorisation explicites par charge de travail, y compris une exception de sortie DNS sur le port UDP 53.

3. Appliquez le Pod Security Standard Restricted. Utilisez Pod Security Admission en mode enforce avec le restricted level pour les espaces de noms de production. Cela bloque les conteneurs privilégiés, exige runAsNonRoot, impose des profils seccomp et restreint les types de volumes.

4. Ajoutez un contrôle d’admission avec OPA Gatekeeper ou Kyverno. Appliquez readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, des listes d’autorisation de registres d’images et des politiques de suppression de toutes les capacités. Utilisez d’abord le mode dryrun pour auditer les charges de travail existantes avant de passer à deny.

5. Gérez les Secrets dans un magasin externe avec chiffrement d’etcd au repos. Utilisez le fournisseur key management service (KMS) v2 pour le chiffrement par enveloppe, et montez les Secrets comme volumes via le Secrets Store CSI Driver, qui utilise tmpfs afin que les données secrètes n’atteignent jamais le disque du nœud. Évitez de transmettre les Secrets comme variables d’environnement.

6. Définissez des limites de ressources. Définissez des demandes et des limites de CPU et de mémoire sur chaque conteneur afin d’éviter l’épuisement des ressources.

Avec une politique appliquée au moment du déploiement, vos charges de travail s’exécutent avec le moindre privilège et une mise en réseau par défaut de refus. La confiance sur laquelle reposent ces garde-fous réside toujours dans le plan de contrôle et les nœuds sous-jacents ; durcissez-les ensuite.

Protéger le plan de contrôle et les nœuds de travail

Le plan de contrôle est l’unique endroit où un seul paramètre faible affecte tout le reste. Configurez chacun des éléments suivants, puis vérifiez-les selon un calendrier plutôt qu’une seule fois au bootstrap.

Étape de durcissement	Ce qu’il faut configurer	Source
Accès au serveur API	Exigez une authentification forte et le TLS mutuel ; gardez le serveur API hors de l’internet public.	CIS Benchmark
Authentification anonyme	Définissez --anonymous-auth=false	Guide CISA/NSA
Journalisation d’audit	Activez les journaux d’audit API, de métriques, d’application et seccomp ; agrégerez-les hors du cluster et déclenchez des alertes à partir de ceux-ci	Guide CISA/NSA
etcd	Chiffrez au repos, exigez le TLS mutuel et isolez derrière un pare-feu que seuls les serveurs API peuvent atteindre	CIS Benchmark
kubelet	Restreignez l’accès à l’API, désactivez les ports en lecture seule, appliquez des configurations au niveau du nœud	CIS Benchmark
Référence des nœuds	Alignez le plan de contrôle, etcd et les nœuds sur le CIS Kubernetes Benchmark correspondant à votre version ; analysez selon une cadence continue	CIS Benchmark
Versions	Appliquez des correctifs à Kubernetes, au système d’exploitation du nœud et au runtime de conteneur selon une cadence régulière	—

Avec un plan de contrôle verrouillé et des nœuds corrigés, la base tient. Une charge de travail active peut encore dériver de son état déclaré ou être attaquée de l’intérieur, et ce sont les contrôles d’exécution qui détectent cela.

Sécurité de l’exécution et détection des menaces

Une sécurité d’exécution Kubernetes robuste détecte ce que les contrôles statiques ne peuvent pas détecter.

1. Surveillez le comportement à l’exécution. Déployez un outil de sécurité d’exécution natif pour conteneurs qui surveille les appels système anormaux, l’exécution inattendue de processus, les connexions réseau et les modifications de fichiers. NIST SP 800-190 indique que les outils traditionnels de système de prévention des intrusions (IPS) et de pare-feu applicatif web (WAF) ne fournissent pas une protection adaptée aux conteneurs.
2. Détectez la dérive de configuration. Comparez les charges de travail en cours d’exécution à leur état déclaré dans Git. Signalez les conteneurs qui ont divergé de leur image ou configuration d’origine.
3. Appliquez des profils seccomp et AppArmor ou SELinux. Utilisez au minimum des profils seccomp RuntimeDefault. Déployez d’abord des profils personnalisés sur un sous-ensemble de nœuds, puis étendez-les à l’échelle du cluster après validation.
4. Exécutez des systèmes de fichiers racine en lecture seule et supprimez les capacités inutiles. Définissez readOnlyRootFilesystem: true et capabilities: drop: [ALL] sur chaque conteneur de production.
5. Appliquez runAsNonRoot. Exigez runAsNonRoot: true dans les contextes de sécurité des pods. Créez les images pour qu’elles s’exécutent en tant qu’utilisateur non root au moment de la compilation plutôt que de vous appuyer uniquement sur des substitutions au moment du déploiement.
6. Activez la réponse autonome et la journalisation d’audit continue. Corrélez les alertes d’exécution avec les journaux d’audit pour reconstituer les chronologies d’attaque. Réinjectez les résultats dans la politique de compilation afin de boucler la boucle.

Ensemble, ces quatre phases produisent un cluster continuellement durci. Les référentiels du secteur décrivent ce à quoi ressemble une configuration correcte à chaque phase, et vous devez mesurer votre cluster par rapport à eux.

Normes et conformité de sécurité Kubernetes

Les référentiels reconnus par le secteur opérationnalisent les pratiques décrites ci-dessus et fournissent les preuves d’audit exigées par votre programme de conformité Kubernetes.

Norme	Périmètre	Pertinence
CIS Kubernetes Benchmark	Plan de contrôle, etcd, nœuds de travail, politiques	Reconnu par PCI DSS, FedRAMP, SOC 2, FISMA et le NIST National Checklist Program
Guide de durcissement Kubernetes CISA/NSA	Compilation, déploiement, réseau, RBAC, journalisation, exécution	Référence gouvernementale faisant autorité pour les clusters fédéraux et d’infrastructure critique
Pod Security Standards	Restrictions de privilèges au niveau du pod sur trois niveaux	Mécanisme d’application intégré à Kubernetes ; correspond directement au tableau I du guide CISA/NSA
NIST SP 800-190	Sécurité du cycle de vie des conteneurs	Associe les contrôles de conteneur à NIST SP 800-53 Rev 5 (AU-2, CM-2, SC-7, IR-4, entre autres)

Maintenant que Kubernetes est la plateforme de production par défaut, les cadres de conformité traitent de plus en plus les contrôles spécifiques à Kubernetes comme un domaine d’audit distinct plutôt que comme un sous-ensemble de la sécurité générale de l’infrastructure. 

Les référentiels spécifiques à une plateforme, tels que le CIS GKE Benchmark et le CIS OpenShift Benchmark, étendent le référentiel général avec des contrôles spécifiques aux services managés. Connaître les normes est la base. La question la plus difficile est de savoir où la sécurité Kubernetes se dirige ensuite.

Tendances futures de la sécurité Kubernetes

Les contrôles que vous déployez aujourd’hui reposent sur un terrain mouvant, et trois tendances remodèlent la manière dont les équipes abordent les bonnes pratiques de sécurité Kubernetes.

1. Les charges de travail d’IA déplacent la surface d’attaque. À mesure que les clusters deviennent l’environnement par défaut des charges de travail d’IA et de machine learning, la planification GPU, les artefacts de modèles et les grands ensembles de données d’entraînement deviennent de nouvelles cibles. La sécurisation de la chaîne d’approvisionnement des données et des modèles devient une partie du durcissement du cluster, et non une préoccupation distincte.
2. L’intégrité de la chaîne d’approvisionnement logicielle devient obligatoire. La génération de SBOM, les artefacts signés et l’attestation de provenance passent du statut d’indicateurs de maturité facultatifs à celui d’attentes de base dans les secteurs réglementés et les achats publics.
3. La défense autonome à l’exécution remplace le tri manuel. Le volume et la vitesse de l’activité des clusters dépassent les capacités de revue humaine. L’IA comportementale qui distingue l’activité normale de l’activité anormale des charges de travail, et qui répond sans attendre un analyste, passe du statut de différenciateur à celui de valeur par défaut.

Chaque tendance pointe dans la même direction : davantage d’automatisation plus tôt dans le cycle de vie et davantage d’autonomie à l’exécution, là où l’outillage de plateforme justifie sa place.

Renforcez la sécurité Kubernetes avec SentinelOne

Les contrôles Kubernetes natifs couverts par ce guide, RBAC, NetworkPolicy, Pod Security Standards, chiffrement d’etcd et journalisation d’audit, constituent la base du durcissement des clusters. SentinelOne ajoute la gestion de posture, l’analyse de la chaîne d’approvisionnement, le contrôle d’admission K8s et la détection des menaces à l’exécution par-dessus, chacun correspondant à une faiblesse nommée dans ce guide.

Singularity Cloud Security analyse les clusters Kubernetes avant même qu’ils ne s’exécutent. L’analyse au moment de la compilation s’intègre directement aux pipelines CI/CD, aux systèmes de contrôle de version et aux registres de conteneurs. Elle vérifie les vulnérabilités connues et plus de 750 types de secrets exposés. La même analyse couvre les modèles infrastructure-ascode, notamment Terraform, Helm, CloudFormation et Kubernetes YAML, afin de détecter tôt les violations de politique. Un Kubernetes Admission Controller agit comme gardien final au niveau du serveur API, bloquant les images non autorisées ou connues comme malveillantes avant leur déploiement.

Kubernetes Security Posture Management (KSPM) comble les lacunes de visibilité à l’échelle du cluster. Il construit un inventaire unifié entre clusters, nœuds, espaces de noms et déploiements, puis met en évidence les accès trop permissifs et les configurations risquées. L’Offensive Security Engine™ simule ensuite des attaques réelles, confirmant via Verified Exploit Paths™ quelles mauvaises configurations sont réellement accessibles aux attaquants. Les équipes de sécurité priorisent ce qui est exploitable au lieu de trier chaque constat. Le même moteur de règles alimente l’Admission Controller, de sorte que la politique reste cohérente de la posture jusqu’au déploiement.

À l’exécution, Singularity Cloud Workload Security, basé sur extended Berkeley Packet Filter (eBPF), détecte les comportements anormaux à la vitesse machine. Les réponses automatisées tuent les processus malveillants et mettent en quarantaine les fichiers infectés sans attendre un analyste. Graph Explorer visualise les relations sur l’ensemble de la surface d’attaque Kubernetes, afin que les équipes voient exactement ce qui est exposé. Lorsque la détection à l’exécution signale une image malveillante, ce constat est automatiquement réinjecté dans l’Admission Controller. L’image est alors bloquée pour tout déploiement futur, transformant une détection unique en politique durable. Purple AI apporte la chasse aux menaces en langage naturel et des résumés d’événements à votre télémétrie de charges de travail cloud sur un seul lac de données, afin que les analystes interrogent en langage clair au lieu de naviguer entre les outils.

Voyez où vos clusters sont exposés en production. Demandez une démo SentinelOne pour découvrir la gestion de posture Kubernetes et la détection des menaces à l’exécution dans votre propre environnement.

Faire une visite

Protection des charges de travail cloud (CWPP) alimentée par l’IA pour les serveurs, machines virtuelles et conteneurs, qui détecte et bloque les menaces à l’exécution en temps réel.

Points clés à retenir

Kubernetes est livré avec des paramètres par défaut permissifs qui laissent la sécurité du cluster entre vos mains. Les bonnes pratiques de sécurité Kubernetes de ce guide couvrent quatre phases : analyse et signature des images à la compilation, RBAC et NetworkPolicy au déploiement, chiffrement d’etcd et journalisation d’audit au niveau du plan de contrôle, et surveillance comportementale à l’exécution. 

Alignez votre configuration sur le CIS Benchmark et le guide CISA/NSA, éliminez les erreurs courantes identifiées ci-dessus et bouclez la boucle en réinjectant les résultats d’exécution dans la politique de compilation. Une fois ce niveau atteint, vous cessez de deviner. Vous pouvez désigner n’importe quel espace de noms, n’importe quel jour, et montrer ce qui est appliqué, ce qui a dérivé et ce que vous avez fait à ce sujet.

FAQ

Quels paramètres Kubernetes sont non sécurisés par défaut ?

Trois paramètres sont livrés non sécurisés sur chaque nouveau cluster Kubernetes. Le guide CISA/NSA Kubernetes Hardening Guidance v1.2 les documente : la connexion anonyme au serveur API est activée, les Secrets sont stockés sans chiffrement dans etcd, et la journalisation d’audit est désactivée. 

La communication de pod à pod n’est pas restreinte sans objets NetworkPolicy. Vous devez les durcir vous-même. Ni le fournisseur cloud ni la distribution Kubernetes n’appliquent ces contrôles pour vous dans le cadre du modèle de responsabilité partagée.

Quelle est la différence entre la sécurité Kubernetes et la sécurité des conteneurs ?

La sécurité des conteneurs et la sécurité Kubernetes opèrent à différentes couches de la même pile. La sécurité des conteneurs se concentre sur l’image et l’instance de conteneur : analyse des vulnérabilités, isolation à l’exécution, suppression des capacités et protection du noyau hôte. 

La sécurité Kubernetes couvre à la fois les conteneurs individuels et le cluster qui les entoure, en ajoutant le RBAC, le contrôle d’admission, la politique réseau, etcd et la journalisation d’audit de l’orchestration. La sécurité des conteneurs s’inscrit dans la discipline plus large de la sécurité Kubernetes.

Quel est le lien entre les Pod Security Standards et les Pod Security Policies obsolètes ?

Les Pod Security Policies (PSP) ont été déclarées obsolètes dans Kubernetes v1.21 et supprimées dans v1.25. Les Pod Security Standards (PSS) définissent trois niveaux de politique (Privileged, Baseline, Restricted) et sont appliqués par Pod Security Admission (PSA), un contrôleur d’admission intégré qui applique la politique au niveau de l’espace de noms via des labels. 

PSA est passé au statut stable dans v1.25. Si votre cluster exécute v1.25 ou une version ultérieure et que vous n’avez pas configuré PSA, vous fonctionnez sans la couche d’application au niveau des pods.

Quels référentiels de conformité s’appliquent aux clusters Kubernetes ?

Quatre principaux cadres de conformité s’appliquent aux clusters Kubernetes. Le CIS Kubernetes Benchmark est reconnu par PCI DSS, FedRAMP, SOC 2 et FISMA. Le guide de durcissement Kubernetes de la CISA/NSA sert de référence gouvernementale. 

NIST SP 800-190 associe les contrôles des conteneurs aux familles de contrôles de NIST SP 800-53 Rev 5. Les Pod Security Standards fournissent le mécanisme d’application intégré qui correspond directement au guide de la CISA/NSA.

Les services managés comme EKS, AKS et GKE gèrent-ils la sécurité du cluster à votre place ?

Les services Kubernetes gérés prennent en charge la disponibilité du plan de contrôle, l’application des correctifs et une partie de la sécurité de l’infrastructure. Vous restez responsable des politiques RBAC, des objets NetworkPolicy, de Pod Security Admission, du chiffrement des Secrets et de la surveillance à l’exécution. 

Le modèle de responsabilité partagée s’applique : le fournisseur sécurise l’infrastructure du plan de contrôle, et vous sécurisez les charges de travail, la configuration et les contrôles d’accès. Les CIS Benchmarks spécifiques à la plateforme documentent les contrôles supplémentaires que vous devez appliquer sur chaque service géré.