Durcissement de Kubernetes : une base pratique

Kubernetes est devenu le plan de contrôle par défaut des charges de travail modernes et, avec cette omniprésence, une cible de choix. Un cluster n'est pas un système unique mais une collection distribuée d'API, de contrôleurs, de chemins réseau et d'identités, et chacune de ces couches peut être mal configurée de façons qui élargissent en silence le rayon d'impact d'un seul conteneur compromis. Cet article présente une base pratique de durcissement pour les défenseurs et les ingénieurs de plateforme qui exploitent des clusters en production. Le cadre, de bout en bout, est comprendre pour défendre : nous décrivons comment naissent les faiblesses, quelle télémétrie révèle l'abus et quels contrôles réduisent la surface d'attaque sans rendre la plateforme inexploitable.

Pourquoi une base de durcissement compte

Les installations par défaut de Kubernetes optimisent la fonctionnalité et la vitesse de développement, non le moindre privilège. En sortie de boîte, vous pouvez trouver des jetons de compte de service montés de façon permissive, des conteneurs tournant en root, aucune politique réseau et un serveur d'API joignable depuis plus d'endroits que prévu. Rien de tout cela n'est un bogue ; c'est un point de départ qui suppose que vous poserez vos propres garde-fous. Une base fournit une définition écrite et vérifiable de la posture minimale que tout cluster doit atteindre, afin que la sécurité soit une propriété de la plateforme plutôt qu'une chose que chaque équipe réinvente. Sans elle, la dérive est inévitable et les audits deviennent de l'archéologie.

Une bonne base est en couches. Elle couvre le plan de contrôle, les nœuds, les charges de travail, le réseau, la chaîne d'approvisionnement et les identités qui relient le tout. Elle est en outre imposée par la mécanique et non par la bonne volonté : le contrôle d'admission, la politique comme code et l'analyse continue de configuration font de la base quelque chose que le cluster refuse de violer.

Le plan de contrôle et le serveur d'API

Le serveur d'API est la porte d'entrée de tout. L'authentification anonyme doit être désactivée, et chaque requête doit porter une identité vérifiable adossée à des identifiants à courte durée de vie. Le journal d'audit de kube-apiserver est votre source de vérité la plus précieuse ; activez-le avec une politique qui enregistre les métadonnées pour les lectures et le corps complet des requêtes pour les écritures sur des ressources sensibles comme les secrets, les rôles et les liaisons de rôle. Stockez ces journaux hors du cluster afin qu'un attaquant qui atterrit à l'intérieur ne puisse pas rogner ses propres traces. Etcd, qui détient tout l'état du cluster y compris les secrets, doit être chiffré au repos et joignable uniquement par le serveur d'API via TLS mutuel.

Restreignez au niveau réseau qui peut atteindre le point de terminaison de l'API. Un plan de contrôle géré avec un point de terminaison privé et une liste d'autorisation de réseaux supprime une large part du risque exposé à internet. Les certificats doivent tourner automatiquement, et la kubeconfig d'administration du cluster doit être traitée comme un identifiant joyau de la couronne et non comme un fichier qui vit sur des portables.

Identité de charge de travail et RBAC

Le contrôle d'accès basé sur les rôles est l'endroit où la plupart des clusters réels fuient du privilège. Les deux anti-patrons à traquer sont les verbes ou ressources joker dans un rôle et les liaisons au rôle intégré cluster-admin pour des humains ou des comptes de service qui n'en ont pas vraiment besoin. Accordez l'ensemble le plus étroit de verbes sur l'ensemble le plus étroit de ressources dans la portée la plus étroite, et préférez des rôles à espace de noms plutôt qu'à l'échelle du cluster. Tout compte de service capable de créer des pods, de lire des secrets ou de modifier des liaisons de rôle est en pratique un chemin vers un contrôle plus large, car ces verbes peuvent s'enchaîner en escalade.

Désactivez le montage automatique des jetons de compte de service par défaut et n'y souscrivez que pour les charges qui appellent réellement l'API. Là où une charge a besoin de permissions cloud, utilisez la fédération d'identité de charge de la plateforme pour que les pods reçoivent des jetons à courte durée de vie et à audience restreinte plutôt que des clés statiques à longue durée de vie enfouies dans des secrets. Revoyez le RBAC en continu ; une liaison raisonnable le trimestre dernier peut devenir dangereuse après une réorganisation d'équipe.

Durcir les charges de travail elles-mêmes

Au niveau du pod, l'objectif est de transformer un conteneur compromis en impasse plutôt qu'en rampe de lancement. Exécutez en tant qu'utilisateur non root avec un système de fichiers racine en lecture seule, abandonnez toutes les capacités Linux et n'ajoutez que le strict nécessaire, et interdisez l'élévation de privilèges avec allowPrivilegeEscalation: false. Les conteneurs privilégiés, le partage des espaces de noms de l'hôte (hostPID, hostNetwork, hostIPC) et les montages de chemins hôtes sont les fonctions que les attaquants convoitent le plus, car chacune érode la frontière entre le conteneur et le nœud. Traitez-les comme des exceptions exigeant une revue explicite, non comme des valeurs par défaut.

Appliquez un profil seccomp comme RuntimeDefault pour contraindre les appels système qu'un conteneur peut émettre et, là où vos charges le tolèrent, superposez AppArmor ou SELinux. Les Pod Security Standards vous donnent trois niveaux nommés — privileged, baseline et restricted — et le contrôleur intégré Pod Security Admission peut imposer le niveau restricted par espace de noms. Pour des règles plus riches, un moteur de politiques comme Kyverno ou un déploiement OPA/Gatekeeper permet d'exprimer et d'imposer des contraintes propres à l'organisation sous forme de code.

Segmentation réseau

Par défaut, chaque pod peut parler à tout autre, ce qui signifie qu'un seul point d'appui voit toute la surface est-ouest. Une NetworkPolicy de refus par défaut par espace de noms, suivie de règles d'autorisation explicites pour les flux dont chaque application a réellement besoin, est l'un des contrôles au plus fort levier que vous puissiez appliquer. Elle transforme le déplacement latéral d'un saut trivial en une activité qui doit franchir une frontière imposée, et rend visibles les connexions anormales. Pour des garanties plus fortes, un maillage de services peut ajouter le TLS mutuel entre services et une autorisation consciente de l'identité, de sorte qu'une position réseau volée ne soit pas la même chose qu'une identité volée.

N'oubliez pas la sortie. Verrouiller ce que les pods peuvent atteindre vers l'extérieur limite l'exfiltration de données et émousse les logiciels malveillants qui appellent leur hôte de commande et contrôle. Combinez la politique réseau avec la journalisation DNS et de sortie afin que des destinations sortantes inattendues deviennent des événements détectables.

Détection : signaux qui révèlent l'abus

Le durcissement réduit la surface d'attaque ; la détection vous dit quand quelqu'un sonde ce qui reste. Le signal le plus riche est le journal d'audit de l'API. Surveillez les requêtes visant à énumérer les secrets à travers les espaces de noms, la création ou la modification d'objets ClusterRoleBinding, les exec ou attach dans des pods en cours d'exécution, et les pods lancés avec des réglages privilégiés ou d'espace de noms hôte. Une rafale soudaine de réponses 403 Forbidden depuis un seul compte de service signifie souvent que des identifiants ont été volés et sont testés contre des ressources qu'ils ne devaient jamais toucher.

À l'exécution, un capteur comportemental comme Falco ou un agent EDR conscient des conteneurs peut signaler un shell ouvert dans un conteneur, un processus inattendu lisant /etc/shadow, une écriture sur un chemin normalement en lecture seule ou une connexion sortante vers une adresse suspecte. Corrélez les événements du cluster avec les journaux du nœud et du fournisseur cloud ; un attaquant qui s'échappe vers le nœud ou pivote vers le point de terminaison de métadonnées cloud laisse des traces à plus d'un endroit, et la corrélation est ce qui transforme le bruit isolé en une histoire claire.

Pièges courants

Les équipes livrent souvent une politique forte dans un cluster de préproduction puis accordent de larges exceptions en production parce qu'une échéance menaçait, et l'exception n'est jamais réexaminée. Une autre erreur récurrente est d'imposer la sécurité des pods tout en laissant le serveur d'API joignable de partout, de sorte que le mur le plus fort n'a pas de porte. Des secrets de tirage d'image trop larges, des secrets passés comme variables d'environnement où ils affleurent dans les journaux et les vidages sur incident, et des clusters qui ne tournent jamais leurs identifiants sont des lacunes courantes. Et désactiver le journal d'audit parce qu'il est bruyant échange votre meilleur atout d'investigation contre un peu moins de stockage : un marché que vous regretterez lors d'un incident.

Une liste de contrôle pratique

Utilisez ceci comme base de départ et adaptez-la à votre risque. Plan de contrôle : auth anonyme désactivée, audit activé et expédié hors cluster, etcd chiffré, point de terminaison d'API privé avec liste de réseaux. Identité : pas de cluster-admin permanent, pas de RBAC joker, automontage de jetons désactivé par défaut, identité de charge pour l'accès cloud. Charges : non root, système de fichiers racine en lecture seule, capacités abandonnées, pas d'élévation de privilèges, seccomp RuntimeDefault, Pod Security Admission restricted, pas d'espaces de noms hôtes sans revue. Réseau : refus par défaut de l'entrée et de la sortie par espace de noms, règles d'autorisation explicites, mTLS de maillage lorsque faisable. Chaîne d'approvisionnement : images signées, vérification à l'admission, analyse de vulnérabilités comme porte. Détection : alertes du journal d'audit, capteur comportemental à l'exécution, rétention de journaux qui dépasse le temps de présence.

FAQ : Pod Security Admission suffit-il à lui seul ?

C'est un socle intégré et solide pour imposer le profil restricted, et tout cluster devrait l'utiliser. Mais il est délibérément limité à un ensemble fixe de contrôles au niveau du pod. Pour des règles propres à l'organisation — étiquettes requises, registres autorisés, vérification de signatures d'image ou quotas de ressources liés à une politique — vous voudrez un moteur de politiques général comme Kyverno ou Gatekeeper à ses côtés. Voyez Pod Security Admission comme le sol et le moteur de politiques comme les murs que vous bâtissez dessus.

FAQ : Comment durcir sans bloquer les développeurs ?

Commencez dans un mode d'audit ou d'avertissement pour que les équipes voient ce qui serait bloqué avant que quoi que ce soit ne casse vraiment, et publiez la base avec un guide de remédiation clair. Offrez des chemins dorés — images de base durcies, processus d'exemption prêts et modèles qui satisfont déjà les règles — pour que l'option sûre soit aussi la facile. L'imposition se pose en douceur quand l'équipe de plateforme supprime la friction au lieu de se contenter de dire non.

Conclusion

Une base de durcissement Kubernetes n'est pas un projet ponctuel mais un contrat vivant entre la sécurité et les équipes qui livrent sur la plateforme. Verrouillez le plan de contrôle, contraignez l'identité par un RBAC au moindre privilège et une identité de charge, faites des conteneurs compromis des impasses, segmentez le réseau par défaut, vérifiez votre chaîne d'approvisionnement et instrumentez tout pour que l'abus soit visible. Imposez-le par le contrôle d'admission et la politique comme code afin que la posture ne dérive pas en silence. Bien mené, le durcissement est invisible pour ceux qui bâtissent sur le cluster et décisif contre ceux qui tentent d'entrer par effraction.