Les cybermenaces apparaissent sans cesse, et les acteurs malveillants ont besoin de plus de temps pour s'y préparer. L'optimisation de la sécurité Kubernetes est essentielle pour améliorer la posture de sécurité cloud d'une entreprise. Les administrateurs Kubernetes doivent comprendre le fonctionnement de l'infrastructure afin d'intégrer des mesures de sécurité efficaces.
La liste de contrôle de sécurité Kubernetes pour 2025 peut être classée en trois grandes catégories :
- Clusters
- Pods
- Conteneurs
La liste de contrôle de sécurité Kubernetes doit être simplifiée et la complexité opérationnelle doit être prise en compte. Lorsque les organisations s'efforcent de hiérarchiser les mesures de sécurité et de remédier aux menaces, elles renforcent automatiquement leur réputation. Les entreprises instaurent la confiance parmi leurs clients et établissent leur crédibilité. Elles réduisent également leurs dépenses opérationnelles en se préparant à faire face aux problèmes futurs qui pourraient survenir avec l'augmentation des menaces.
Voyons cela de plus près.
Liste de contrôle de sécurité Kubernetes à plusieurs composants
La liste de contrôle de sécurité Kubernetes comporte plusieurs composants
- Audit et journalisation
- Sécurité réseau
- Authentification et autorisation
- Gestion des secrets
- Contrôle d'admission
- Limites de sécurité Kubernetes
- Politiques de sécurité Kubernetes
- Sécurité Kubelet
- Paramètres par défaut " ouverts "
Selon le rapport Kubernetes , de sécurité et des tendances du marché 2024, les organisations ont documenté de nombreux impacts négatifs (notamment des pertes de revenus et des amendes) dus à la négligence en matière de sécurité des conteneurs Kubernetes. DevSecOps ont déclaré que les vulnérabilités et les erreurs de configuration sont les principales préoccupations en matière de sécurité liées à Kubernetes et aux environnements de conteneurs. Les solutions logicielles open source Kubernetes ne sont pas sûres et affectent la sécurité de la chaîne d'approvisionnement logicielle. Plus de 67 % des entreprises ont retardé leurs opérations commerciales en raison de problèmes de sécurité, et la plupart des entreprises mondiales sont submergées par tous les aspects de la gestion de la sécurité, depuis le développement jusqu'au déploiement et à la maintenance.
La liste de contrôle ultime pour la sécurité Kubernetes en 2025
#1. Suivre les benchmarks CIS
Les benchmarks CIS fournissent des politiques de sécurité de base que les organisations peuvent utiliser pour améliorer la sécurité de Kubernetes. Ils protègent les systèmes informatiques contre les cyberattaques et comprennent un ensemble de processus et de directives consensuels développés par la communauté pour sécuriser les environnements Kubernetes. Selon la liste de contrôle de sécurité Kubernetes CIS Benchmark, les principaux composants que les utilisateurs doivent sécuriser sont les suivants : Kubernetes PKI, kubeadm, fichiers CNI, répertoire de données etcd, kubeadm admin.conf, controller manager.conf et le fichier de spécification des pods.
#2. Authentification API Kubernetes
L'une des méthodes les plus largement adoptées pour l'authentification API Kubernetes dans la liste de contrôle de sécurité Kubernetes consiste à utiliser des certificats X509. Les certificats sont utilisés pour mettre en évidence un groupe d'adhésions et permettent de vérifier les noms des sujets qui envoient des requêtes.
Selon la liste de contrôle de sécurité Kubernetes, il existe d'autres méthodes intégrées pour authentifier les comptes utilisateurs. Les pratiques d'authentification Kubernetes valident l'identité des utilisateurs et déterminent s'ils doivent ou non se voir accorder l'accès. Le contrôle d'accès basé sur les rôles est mis en œuvre dans le processus.
Pour utiliser l'authentification X509, les utilisateurs doivent créer une clé privée et émettre une demande de signature de certificat. Cela peut être initié dans des environnements Unix ou des systèmes d'exploitation similaires. La deuxième technique la plus populaire d'authentification Kubernetes consiste à utiliser des jetons OpenID Connect (OIDC). De nombreux fournisseurs OIDC tels que Google, Okta, dex et OpenUnison facilitent cette opération. Divers services d'authentification unique facilitent l'authentification API Kubernetes, et les étapes de mise en œuvre varient en fonction du service choisi par les utilisateurs. Les jetons d'authentification des comptes de service peuvent être utilisés pour valider les demandes d'authentification, et les jetons porteurs dans les en-têtes HTTP peuvent également émettre des recommandations.
La dernière méthode d'authentification consiste à utiliser des fichiers de mots de passe statiques. Il s'agit de l'approche d'authentification la moins sécurisée, mais aussi la plus simple. Elle nécessite une configuration minimale, et les utilisateurs doivent mettre à jour manuellement le fichier de mots de passe pour actualiser les modifications d'accès des utilisateurs. Pour ceux qui découvrent l'authentification Kubernetes, l'utilisation de fichiers de mots de passe statiques comme solution d'authentification est l'approche la plus simple pour les clusters de test.
#3. Sécurité Kubelet
La sécurité Kubelet implique l'exécution de nœuds sur les clusters Kubernetes. Elle est principalement responsable de la gestion des conteneurs Kubernetes directement sur les nœuds et interagit avec les interfaces d'exécution des conteneurs (CRI).
Deux ports sont concernés : 10255 et 10250. Le port 10255 est un port en lecture seule qui renvoie des données sur les pods et les conteneurs s'exécutant sur les nœuds. Le port 10250 est un port en écriture qui permet de planifier des pods sur des nœuds sélectionnés.
Lors du premier déploiement de clusters Kubernetes, les mesures de sécurité suivantes doivent être prises en compte dans le cadre de la liste de contrôle de sécurité Kubernetes :
- Exécutez toujours les nœuds sur des réseaux internes
- Utilisez kubelet avec le drapeau –anonymous-auth=false et restreignez l'accès anonyme
- Évitez de définir le mode d'autorisation sur AlwaysAllow et sélectionnez une autre option
- Restreindre les autorisations des kubelets. Le plugin d'admission NodeRestriction peut modifier les pods et les lier à des objets Node.
- Utiliser l'authentification par certificat et la configurer correctement pour permettre une communication fluide entre le maître et les nœuds.
- Appliquez des règles de pare-feu strictes et autorisez uniquement le maître Kubernetes à communiquer avec le kubelet.
- Désactivez les ports en lecture seule et limitez les informations partagées par les charges de travail.
- Testez manuellement tous les contrôles de sécurité Kubernetes et assurez-vous que les kubelets sont inaccessibles par défaut
#4. Gestion des secrets
Les secrets Kubernetes stockent des données sensibles telles que des clés API, des mots de passe et des jetons. Les secrets Kubernetes ne sont pas censés être accessibles par les composants Kubernetes internes et ne sont envoyés aux nœuds de pod que lorsque cela est nécessaire. Les secrets sont l'une des principales cibles des attaquants et doivent être protégés avec soin.
Les utilisateurs doivent restreindre l'accès à etcd, le contrôler et appliquer un chiffrement aux clusters etcd. Les conteneurs Kubernetes doivent également respecter le principe d'accès du moindre privilège. L'autorisation des nœuds doit être mise en œuvre parmi d'autres éléments de la liste de contrôle de sécurité Kubernetes. Idéalement, les utilisateurs doivent utiliser différents ensembles de secrets pour différents environnements Kubernetes.
Il est recommandé d'éviter d'intégrer des secrets dans les images. Il est également recommandé d'activer l'analyse en temps réel des secrets dans les référentiels de code source et de les vérifier. Les secrets risquent d'être écrits dans les journaux, et l'une des meilleures pratiques de sécurité consiste à transmettre les secrets dans des fichiers. Définissez le volume monté comme répertoire temporaire au lieu d'écrire sur le disque. Vous pouvez également faire tourner les clés secrètes, choisir différents moyens de les stocker et les transmettre aux conteneurs pour obtenir les meilleurs résultats. Parfois, les applications doivent être redémarrées pour lire les nouveaux mots de passe de la base de données. Pour les utilisateurs de workflows basés sur des fichiers, les secrets de fichiers peuvent être mis à jour automatiquement sans redémarrage.
#5. Contrôleurs d'admission
Les contrôleurs d'admission sont inclus dans la liste de contrôle de sécurité Kubernetes pour 2025. Ils appliquent les cadres de politique de sécurité Kubernetes et constituent une deuxième ligne de défense après les contrôles RBAC.
Les contrôleurs d'admission peuvent définir des règles basées sur différents paramètres et limiter l'utilisation des ressources. Ils peuvent empêcher l'exécution de commandes dans des conteneurs privilégiés et exiger que les pods extraient toujours des images au lieu d'utiliser celles stockées localement sur le nœud. Un autre avantage des contrôleurs d'admission est la surveillance des requêtes entrantes et la définition de contraintes de ressources dans les espaces de noms. Il est recommandé aux utilisateurs d'activer au minimum les contrôleurs d'admission par défaut fournis par Kubernetes.
#6. Limites de sécurité Kubernetes
Les limites de sécurité Kubernetes constituent le fondement de la liste de contrôle de sécurité Kubernetes. Elles empêchent les processus d'accéder aux données d'autres utilisateurs et appliquent des politiques qui offrent une isolation conteneurisée. Les modèles d'admission LimitRanger et ResourceQuota empêchent la privation de ressources, et en ce qui concerne les pods, les utilisateurs peuvent définir des contextes de sécurité personnalisés et les appliquer.
#7. Politiques de sécurité Kubernetes
Les normes de sécurité des pods sont soumises à des degrés de complexité variables. Les politiques de sécurité des pods Kubernetes sont configurées au niveau des ressources du cluster et appliquent l'utilisation de contextes de sécurité et de contrôleurs d'admission. Le pod doit répondre aux exigences de la politique de sécurité des pods, sinon il ne fonctionnera pas. Les politiques de sécurité des pods sont automatiquement supprimées à partir de Kubernetes v1.25, ce qui signifie que les utilisateurs doivent migrer vers le contrôleur d'admission Kubernetes Pod Security.
Les contextes de sécurité définissent les paramètres de contrôle d'accès et les privilèges pour les conteneurs Kubernetes. Ils mettent en œuvre des contrôles d'accès discrétionnaires, définissent des autorisations d'accès aux objets en fonction des identifiants de groupe et configurent les processus non privilégiés. Les utilisateurs peuvent définir des outils de contexte de sécurité internes et les intégrer à des fonctionnalités externes. Ils peuvent utiliser seccomp pour filtrer les appels système, et AppArmor peut restreindre les capacités de composants individuels. Vous n'avez pas besoin de fournir des privilèges d'accès ni d'attribuer des autorisations spécifiques aux ressources, ce qui vous aide à adopter une approche granulaire. Les utilisateurs peuvent inclure des contextes de sécurité avec le code de contexte de sécurité trouvé dans les fichiers de déploiement lors de la création de pods. Kubernetes est très agile et les utilisateurs peuvent également automatiser le déploiement de profils sur les nœuds. Le seul inconvénient est qu'il n'y a pas de prise en charge des conteneurs Windows. Ils peuvent également activer des autorisations pour sécuriser les comptes de service, les nœuds et les utilisateurs.
#8. Sécurité réseau Kubernetes
La sécurité réseau Kubernetes est un élément essentiel de la liste de contrôle de sécurité Kubernetes. Elle ajoute des contrôles qui spécifient comment le trafic circule entre les conteneurs et définit le type de trafic à bloquer. Les utilisateurs peuvent suivre une architecture multi-clusters pour isoler les charges de travail et atténuer les problèmes de sécurité en déployant les charges de travail dans différents clusters. Vous pouvez ainsi obtenir un haut degré d'isolation des conteneurs tout en réduisant la complexité.
Il existe des politiques réseau Kubernetes qui ajoutent des capacités de pare-feu et restreignent le flux de trafic entre les pods. Elles spécifient quels pods communiquent avec les entités réseau sélectionnées. La politique d'entrée est autorisée sur le port de destination, et la politique de sortie doit être sur le pod source pour permettre un flux de trafic optimal. En règle générale, l'utilisation d'étiquettes est recommandée, et les utilisateurs peuvent ajouter des procédures pour autoriser et diriger le trafic uniquement vers les endroits où ils le souhaitent. Ils peuvent restreindre le trafic à des ports spécifiques pour différentes applications. Les maillages de services Kubernetes peuvent simplifier la surveillance et fournir diverses fonctionnalités liées à la surveillance continue et aux alertes. Ils détectent les menaces de sécurité et signalent les incidents ; de nombreux projets de maillage de services sont disponibles. La liste de contrôle de sécurité Kubernetes suggère d'utiliser des options telles que Linkerd, Consul et Istio.
#9. Audit et journalisation Kubernetes
Il est essentiel de conserver les journaux d'événements des conteneurs et de créer une piste d'audit pour les environnements de production. La journalisation d'audit Kubernetes comprend la journalisation de l'identité des images et des utilisateurs qui invoquent les commandes de démarrage et d'arrêt. Les plugins CNI génèrent des interfaces réseau virtuelles utilisées par les conteneurs. Les plugins CNI s'intègrent également à plusieurs plateformes et outils de gestion de configuration tiers, les plus populaires étant Cilium et Project Calico. D'autres aspects de l'audit et de la journalisation Kubernetes comprennent la modification des charges utiles des conteneurs et des montages de volumes, la surveillance des connexions entrantes et sortantes, et la correction des actions ayant échoué. La journalisation des applications est le moyen le plus simple de surveiller l'activité du cluster et peut fournir des informations utiles pour le débogage des applications. La mise en œuvre de la journalisation au niveau du cluster et le transfert des journaux dans des conteneurs de stockage sont des pratiques courantes qui utilisent une plateforme ou un service centralisé de gestion des journaux.
Pourquoi SentinelOne pour la sécurité Kubernetes ?
Cloud Workload Security (CWS) de SentinelOne pour Kubernetes, qui fait partie de la plateforme Singularity™, offre une solution de pointe conçue pour lutter efficacement contre ces menaces modernes. Voici comment SentinelOne renforce la sécurité Kubernetes :
- Protection en temps réel contre les menaces : Singularity CWS surveille et protège en permanence vos charges de travail Kubernetes contre les menaces telles que les ransomwares et les vulnérabilités inconnues. Sa technologie basée sur l'IA garantit une détection et une réponse rapides, protégeant ainsi vos environnements Kubernetes.
- Enquête sur les incidents et recherche des menaces : grâce à Singularity Data Lake, SentinelOne fournit des informations complètes sur l'activité de votre charge de travail. Cet outil facilite les enquêtes sur les incidents et la recherche des menaces. Le Workload Flight Data Recorder™ aide à récupérer après un incident en supprimant les charges de travail problématiques, minimisant ainsi les pertes financières et les dommages.
- Large compatibilité : SentinelOne prend en charge un large éventail de charges de travail conteneurisées, notamment 14 distributions Linux majeures, trois environnements d'exécution de conteneurs populaires et des services Kubernetes gérés et autonomes.
Voir SentinelOne en action
Découvrez comment la sécurité du cloud alimentée par l'IA peut protéger votre organisation lors d'une démonstration individuelle avec un expert produit de SentinelOne.
Obtenir une démonstrationConclusion
Les principes de base de la liste de contrôle de sécurité Kubernetes 2025 tournent autour de l'authentification, de la gestion de la sécurité des pods, du traitement des secrets et d'autres composants. En suivant ces pratiques, les organisations peuvent sécuriser les environnements Kubernetes et garantir que l'accès aux données est restreint. Ces conseils simplifient la sécurité Kubernetes et la sécurité par couches afin de réduire la complexité de l'architecture. Lorsque les utilisateurs optimisent la sécurité Kubernetes pour le cloud, il devient facile de l'intégrer à d'autres workflows de sécurité.
"FAQ sur la liste de contrôle de sécurité Kubernetes
Une liste de contrôle de sécurité Kubernetes est une liste d'étapes à suivre pour verrouiller votre cluster. Elle couvre la sécurisation du serveur API, etcd et kubelet, l'application du RBAC, l'isolation des pods à l'aide de politiques de sécurité réseau et pod, le chiffrement des secrets et l'audit des événements.
La liste de contrôle sert de guide pour garantir que tous les composants critiques, du plan de contrôle aux charges de travail, répondent aux normes de sécurité de base.
Les clusters Kubernetes gèrent des charges de travail critiques, et toute erreur peut exposer des données sensibles ou permettre à des attaquants de se déplacer latéralement. Une liste de contrôle permet d'éviter les dérives : vous appliquez de manière cohérente les contrôles convenus, vous détectez les failles (comme les ports API ouverts ou les RBAC trop permissifs) et vous maintenez la conformité. Le fait de suivre régulièrement la liste de contrôle réduit les surprises et permet de renforcer la protection des clusters contre les menaces connues et émergentes.
Votre liste de contrôle de production doit inclure : la restriction de l'accès au serveur API aux réseaux de confiance ; l'activation des journaux d'audit ; le chiffrement des données etcd au repos ; l'application du RBAC avec le moins de privilèges possible ; l'application de politiques de sécurité ou d'admission des pods ; l'utilisation de politiques réseau pour isoler les services ; la sécurisation des images de conteneurs ; la rotation des certificats ; et la validation de la sécurité du pipeline CI/CD. Chaque élément verrouille une couche de votre cluster avant que le trafic ou les charges de travail ne soient mis en service.
Les équipes doivent revoir la liste de contrôle au moins une fois par trimestre et après chaque mise à niveau majeure de la version Kubernetes ou modification de l'architecture. Des révisions fréquentes permettent de détecter les dérives de configuration, telles que l'ouverture de nouveaux ports ou l'assouplissement des règles RBAC, et de s'assurer que les contrôles s'adaptent aux nouvelles menaces ou aux composants ajoutés.
Les changements critiques, tels que les nouveaux espaces de noms ou les contrôleurs d'admission personnalisés, justifient également une révision immédiate de la liste de contrôle.
Des outils open source tels que kube-bench auditent votre cluster par rapport aux benchmarks CIS Kubernetes. Kube-hunter recherche les expositions et les erreurs de configuration. Polaris valide les charges de travail en direct par rapport à des politiques personnalisées. Les journaux d'audit natifs de Kubernetes sont transmis aux SIEM pour la surveillance des événements.
Combinés, ces outils automatisent les vérifications des paramètres du plan de contrôle, du RBAC, des politiques réseau, etc., ce qui facilite la détection et la correction des écarts par rapport à votre liste de contrôle.
Vous pouvez commencer par la liste de contrôle de sécurité Kubernetes officielle sur GitHub (kubernetes.io/docs/concepts/security/security-checklist/) ou par des guides maintenus par la communauté, tels que le référentiel krol3/kubernetes-security-checklist.
De nombreux fournisseurs de cloud et de sécurité publient également des listes de contrôle téléchargeables au format PDF. Il vous suffit de rechercher " Kubernetes Security Checklist PDF " pour trouver des exemples que vous pouvez adapter à votre environnement.
La mise en œuvre est un effort commun entre les équipes DevOps, les ingénieurs de plateforme et les équipes de sécurité. Les ingénieurs de plateforme configurent les composants du plan de contrôle et les politiques réseau. Les équipes DevOps sécurisent les charges de travail et les pipelines CI/CD.
Les équipes de sécurité définissent les contrôles de base, effectuent des audits et surveillent la conformité. Ensemble, ils veillent à ce que chaque élément de la liste de contrôle, des règles RBAC aux politiques de sécurité des pods, soit appliqué et validé.
