Kubernetes pour les charges de travail de défense : orchestration d'applications conteneurisées classifiées

L'orchestration de conteneurs est devenue le modèle de déploiement dominant pour les logiciels de défense modernes, mais les exigences de sécurité opérationnelle des environnements classifiés imposent des contraintes que les configurations Kubernetes standard n'adressent pas par défaut. Un cluster bootstrappé avec kubeadm expose des API kubelet non authentifiées, stocke les Secrets en clair dans etcd, n'applique aucune politique réseau entre les pods et génère des journaux d'audit qui ne sont ni transmis ni protégés contre la falsification. Chacun de ces paramètres par défaut constitue une constatation dans toute revue de sécurité sérieuse. Cet article traite de ce qu'il faut pour exécuter Kubernetes correctement dans un environnement classifié : du durcissement des nœuds selon les référentiels CIS et STIG jusqu'à la gestion des secrets adossée à un HSM, la micro-segmentation réseau, l'architecture de journalisation d'audit, les contrôles de la chaîne d'approvisionnement des images et le parcours documentaire vers une autorisation d'exploitation.

Pourquoi l'orchestration de conteneurs est essentielle au déploiement des logiciels de défense modernes

Les logiciels de défense ont historiquement été déployés en tant qu'applications monolithiques sur des serveurs physiques dédiés, chaque mise à niveau nécessitant une coordination manuelle entre plusieurs domaines de sécurité et des tests approfondis avant qu'un changement n'atteigne un environnement opérationnel. L'orchestration de conteneurs inverse ce modèle : les applications sont conditionnées sous forme d'images immuables, l'infrastructure est déclarée sous forme de code, et l'orchestrateur gère la planification, la vérification de l'état et les mises à jour progressives sur un parc de nœuds. Pour les programmes qui doivent pousser des mises à jour de capacités vers les opérateurs en quelques semaines plutôt qu'en plusieurs années, cette transition n'est pas optionnelle.

Kubernetes offre des avantages supplémentaires particulièrement pertinents pour les charges de travail classifiées. L'isolation des ressources au niveau de l'espace de noms permet à plusieurs applications au même niveau de classification de partager l'infrastructure des nœuds sans interférer avec les ressources CPU, mémoire ou réseau de l'autre. Les quotas de ressources empêchent une charge de travail défaillante de consommer toute la capacité du cluster. Les budgets de perturbation des pods appliquent des contraintes de disponibilité pendant les fenêtres de maintenance. Ces contrôles correspondent directement aux exigences de fiabilité et d'isolation que les officiers d'autorisation s'attendent à voir documentées dans un Plan de sécurité du système.

Le défi est que le projet Kubernetes est conçu pour des environnements cloud commerciaux orientés internet, et sa configuration par défaut reflète cet héritage. Les programmes de défense adoptant Kubernetes doivent traiter la configuration par défaut comme un point de départ pour le durcissement, et non comme une base acceptable. L'écart entre un cluster par défaut et un cluster prêt à l'accréditation est substantiel, mais il est bien documenté par la DISA et le Center for Internet Security, et il peut être comblé avec un travail de configuration délibéré.

Durcissement des nœuds : conformité aux référentiels CIS et STIG pour les nœuds workers Kubernetes

Le durcissement des nœuds commence au niveau du système d'exploitation avant l'installation d'un seul composant Kubernetes. Les nœuds workers doivent être construits à partir d'une image de base durcie STIG ou CIS Niveau 2 — Red Hat Enterprise Linux CoreOS (RHCOS) pour les clusters basés sur OpenShift, ou une version durcie d'Ubuntu ou Rocky Linux pour Kubernetes upstream. La configuration du système d'exploitation de base couvre le partitionnement du système de fichiers (montages séparés /tmp, /var, /var/log), le durcissement des paramètres noyau (désactivation du transfert IP sauf si requis par le CNI, activation des syncookies, désactivation du routage par la source IP), le contrôle d'accès obligatoire (mode SELinux enforcing ou profils AppArmor), et la suppression des paquets et services inutiles.

Au niveau Kubernetes, le DISA STIG pour Kubernetes et le référentiel CIS Kubernetes Benchmark Niveau 2 convergent sur un ensemble central d'exigences de configuration du kubelet. Le port en lecture seule du kubelet doit être désactivé (--read-only-port=0). L'authentification anonyme doit être désactivée (--anonymous-auth=false). Le mode d'autorisation doit être réglé sur Webhook, délégant toutes les décisions d'autorisation au moteur RBAC du serveur API plutôt que de faire confiance aux décisions locales du nœud. La rotation des certificats doit être activée pour que les certificats client du kubelet soient renouvelés automatiquement avant expiration. L'environnement d'exécution des conteneurs — containerd ou CRI-O — doit être configuré avec un profil seccomp par défaut (RuntimeDefault) appliqué à tous les pods, sauf s'ils nécessitent explicitement un profil plus permissif ou personnalisé.

L'exécution de kube-bench, l'auditeur open-source du référentiel CIS, contre un cluster configuré produit un rapport de conformité structuré au format XCCDF. Ce rapport est une pièce jointe requise dans la plupart des dossiers d'accréditation. Les constatations de Catégorie I (haute sévérité) doivent être résolues avant la soumission ; les constatations de Catégorie II doivent être résolues ou documentées avec des contrôles compensatoires. Les playbooks de remédiation automatisée — Ansible ou similaire — qui appliquent de manière reproductible les contrôles du référentiel sur tous les nœuds sont fortement préférés à la configuration manuelle, tant parce qu'ils réduisent la dérive de configuration que parce qu'ils produisent des enregistrements de changements auditables.

Application des politiques réseau : micro-segmentation entre les charges de travail classifiées

Par défaut, tous les pods d'un cluster Kubernetes peuvent communiquer avec tous les autres pods, quel que soit l'espace de noms. Ce modèle de réseau plat est approprié pour les environnements de développement mais inacceptable pour les charges de travail classifiées, où le principe du moindre privilège doit s'appliquer au trafic réseau tout comme il s'applique aux permissions RBAC. L'application de la segmentation réseau nécessite deux éléments : un plugin CNI qui implémente la spécification NetworkPolicy de Kubernetes, et un ensemble d'objets NetworkPolicy définissant les chemins de communication autorisés.

Le modèle de durcissement de base est une politique de refus par défaut appliquée à chaque espace de noms au moment du bootstrap du cluster. Cette politique refuse tout le trafic entrant et sortant, sauf si une règle d'autorisation explicite le permet. Des règles d'autorisation explicites sont ensuite ajoutées pour chaque chemin de trafic requis : la résolution DNS (ports TCP et UDP 53 vers CoreDNS dans kube-system), le trafic de vérification de l'état du kubelet vers les conteneurs d'application, et la communication service à service spécifique aux applications. Chaque règle d'autorisation doit être aussi restrictive que possible — par sélecteur de libellé de pod, sélecteur de libellé d'espace de noms et port — plutôt que d'utiliser de larges plages CIDR qui passeront la revue d'un auditeur mais ne contraindront pas réellement le mouvement latéral.

Pour les charges de travail opérant à différents niveaux de classification devant coexister sur une infrastructure partagée, la NetworkPolicy basée sur les libellés seule est insuffisante. Le plugin CNI applique les politiques dans la couche netfilter du noyau Linux, et un conteneur compromis suffisamment privilégié peut contourner netfilter. Les programmes de défense hébergeant des charges de travail à plusieurs niveaux de sensibilité sur un seul cluster doivent placer chaque niveau de sensibilité dans un pool de nœuds dédié avec des interfaces réseau ou des VLAN dédiés, et appliquer les contrôles de trafic entre niveaux au niveau matériel ou de l'hyperviseur. L'architecture d'interconnexion cloud de défense fournit la séparation physique et logique que les contrôles uniquement basés sur des politiques ne peuvent garantir sur une infrastructure à noyau partagé.

Gestion des secrets : intégration de Kubernetes avec des magasins de clés adossés à un HSM

Les Secrets Kubernetes sont, par défaut, stockés dans etcd sous forme de valeurs encodées en base64 sans chiffrement. Tout utilisateur ou processus disposant d'un accès en lecture à etcd — ou disposant de permissions RBAC suffisantes pour appeler kubectl get secret — peut récupérer la valeur en clair. Pour les environnements classifiés, il ne s'agit pas d'un écart de configuration ; c'est un problème architectural fondamental qui doit être résolu avant que des données sensibles ne soient stockées dans le cluster. La solution est le chiffrement au repos d'etcd à l'aide d'un fournisseur KMS qui délègue la gestion des clés à un magasin de clés adossé à un HSM.

La ressource EncryptionConfiguration du kube-apiserver spécifie une liste de fournisseurs de chiffrement pour chaque type de ressource. Pour le fournisseur kms, la configuration pointe vers un socket Unix où un processus de plugin KMS écoute. Le plugin traduit le protocole gRPC KMS de Kubernetes en appels vers le HSM ou le service de gestion de clés — généralement via PKCS#11 pour un HSM en réseau, ou via l'API de gestion de clés d'un KMS cloud de qualité défense. Lorsque le serveur API écrit un Secret dans etcd, il appelle le plugin KMS pour chiffrer la clé de chiffrement des données (DEK) sous la clé de chiffrement de clé (KEK) détenue par le HSM. Seule la DEK enveloppée est stockée dans etcd aux côtés du texte chiffré. Le déchiffrement nécessite un aller-retour vers le HSM. Le HSM doit être validé FIPS 140-2 Niveau 3 pour les charges de travail de niveau SECRET ; le Niveau 2 est généralement acceptable uniquement pour les matériaux SENSIBLES mais NON CLASSIFIÉS.

Journalisation d'audit : capture des événements du serveur API pour la conformité et la forensique

Le serveur API Kubernetes génère un journal d'audit de chaque requête qu'il traite : qui a formulé la requête, quel verbe et quelle ressource étaient impliqués, quel espace de noms, si la requête a réussi, et — selon le niveau d'audit configuré — le corps complet de la requête et de la réponse. Ce journal est l'enregistrement faisant autorité pour répondre à la question « qui a fait quoi dans ce cluster et quand ». Pour les environnements classifiés, une journalisation d'audit complète n'est pas optionnelle ; c'est une exigence de contrôle spécifique dans le RMF, le JSIG et les cadres équivalents, et l'absence de journaux d'audit adéquats est généralement une constatation bloquante lors d'une revue d'accréditation.

La politique d'audit est un fichier YAML transmis au kube-apiserver au démarrage qui associe les types de ressources et les verbes aux niveaux d'audit. Les quatre niveaux sont None (pas de journalisation), Metadata (utilisateur, verbe, ressource, statut — sans corps), Request (ajoute le corps de la requête) et RequestResponse (ajoute les corps de la requête et de la réponse). Une politique de niveau conformité capture RequestResponse pour les Secrets, ConfigMaps, Roles, RoleBindings, ClusterRoles, ClusterRoleBindings et ServiceAccounts — les ressources dont la modification pourrait indiquer une élévation de privilèges ou un vol d'identifiants. Les appels exec et attach aux pods doivent également être capturés au niveau RequestResponse, car ce sont les principaux vecteurs de mouvement latéral interactif dans un cluster compromis. Toutes les autres ressources peuvent être journalisées au niveau Metadata, ce qui produit un enregistrement d'accès complet sans la surcharge de stockage liée à la capture de chaque charge utile d'application.

Les journaux d'audit stockés uniquement sur le nœud du plan de contrôle sont vulnérables à la falsification par un administrateur de cluster compromis. Une architecture d'audit de qualité défense expédie les journaux vers une destination externe que le cluster lui-même ne peut pas écrire ni supprimer : un SIEM (système de gestion des informations et des événements de sécurité), un magasin d'objets compatible S3 en mode ajout uniquement avec rétention object-lock, ou un redirecteur syslog dédié vers une infrastructure d'agrégation de journaux à accès restreint. L'expéditeur de journaux — un DaemonSet Fluentd ou Fluent Bit sur les nœuds du plan de contrôle — doit s'exécuter avec un compte de service Kubernetes n'ayant aucune permission sur les objets du cluster journalisés, afin qu'un expéditeur compromis ne puisse pas effacer ses traces en modifiant la politique d'audit ou en supprimant des fichiers journaux.

Analyse des images et sécurité de la chaîne d'approvisionnement dans les registres de conteneurs classifiés

Chaque image de conteneur déployée dans un cluster classifié est une surface d'attaque potentielle de la chaîne d'approvisionnement. Une image extraite d'un registre public sans inspection peut contenir des versions de bibliothèques présentant des vulnérabilités connues, des identifiants intégrés ou du code malveillant introduit pendant le pipeline de build. Les programmes de défense doivent exploiter un registre de conteneurs privé isolé de l'internet public, nécessitant un accès authentifié et appliquant l'analyse des vulnérabilités et la signature des images avant qu'une image ne soit admise dans le cluster.

Les outils d'analyse de vulnérabilités des images tels que Trivy ou Grype analysent chaque couche d'image par rapport à la base de données de conseils OSV et aux bulletins de sécurité des fournisseurs, produisant une liste de CVE avec des scores de sévérité et les versions de paquets affectées. Dans un pipeline CI classifié, l'analyse s'exécute dans le cadre du processus de build de l'image ; les images contenant des CVE de sévérité Critique ou Haute sont bloquées avant d'être poussées vers le registre de production jusqu'à ce que les vulnérabilités soient remédiées ou formellement acceptées comme risques. Les résultats d'analyse sont stockés aux côtés de l'image dans les métadonnées du registre et référencés dans le dossier de preuves d'accréditation comme preuve que l'inventaire logiciel est connu et examiné.

La signature des images ajoute une assertion cryptographique qu'un condensat d'image spécifique a été produit par un pipeline de build spécifique et n'a pas été modifié depuis la signature. L'outil cosign du projet Sigstore prend en charge la signature avec une clé stockée dans un HSM ou KMS, produisant une attestation de signature stockée dans le registre aux côtés de l'image. Le webhook d'admission Kubernetes — utilisant un moteur de politiques tel que Kyverno ou OPA Gatekeeper — vérifie la signature avant que tout pod ne soit planifié. Cette chaîne de contrôle du build au déploiement est précisément ce que les cadres de sécurité de la chaîne d'approvisionnement exigent : chaque charge de travail s'exécutant dans le cluster peut être tracée jusqu'à un artefact de build signé spécifique, et les images non signées ou falsifiées sont rejetées au niveau de la couche d'admission plutôt que découvertes lors d'une revue forensique post-incident.

Parcours d'accréditation : faire passer un cluster Kubernetes par une ATO ou équivalent

Une autorisation d'exploitation pour un cluster Kubernetes n'est pas un document unique mais un dossier de preuves constitué pour démontrer que le système satisfait aux contrôles de sécurité spécifiés dans le cadre applicable — le Risk Management Framework (RMF) pour les programmes fédéraux américains, le JSIG pour les systèmes de renseignement interarmées, ou des équivalents spécifiques aux programmes pour les marchés de défense des nations alliées. L'officier d'autorisation examine ce dossier et prend une décision d'acceptation du risque. Comprendre ce que le dossier doit contenir est essentiel pour planifier le calendrier d'accréditation, car les lacunes découvertes tardivement dans le processus de revue peuvent retarder la mise en service de plusieurs mois.

Le Plan de sécurité du système est le document central. Pour un cluster Kubernetes, le PSS doit décrire l'architecture du cluster (nombre et placement des nœuds du plan de contrôle, topologie etcd, pools de nœuds workers, topologie réseau), la configuration de durcissement des nœuds avec références au rapport de conformité kube-bench, la configuration de chiffrement pour etcd, le modèle RBAC (quels comptes de service ont quelles permissions et pourquoi), l'architecture des politiques réseau, la provenance des images et la chaîne de signature, et l'architecture de transfert des journaux d'audit. Chaque contrôle dans le référentiel applicable est soit satisfait (avec une référence à la preuve), non applicable (avec une justification), soit ouvert (avec un contrôle compensatoire ou une entrée au plan d'action et d'étapes clés).

La surveillance continue est une condition de la plupart des ATO plutôt qu'une étape unique. Le cluster doit être intégré dans un système de gestion de la configuration qui détecte les dérives par rapport au référentiel durci, un processus de gestion des vulnérabilités qui suit les CVE dans les images déployées et les paquets du système d'exploitation des nœuds par rapport aux SLA de remédiation, et un processus de revue des journaux qui surveille les événements d'audit pour détecter les anomalies. Les outils automatisés — kube-bench planifié en tant que CronJob Kubernetes, réanalyse des images selon un calendrier nocturne, règles d'alerte SIEM pour les modèles suspects du serveur API — produisent les preuves de surveillance continue sans nécessiter d'effort manuel pour chaque cycle de revue. Les programmes qui construisent cette automatisation avant la soumission initiale de l'ATO sont en bien meilleure position pour la réautorisation que ceux qui traitent la surveillance continue comme une réflexion après l'autorisation.