Kubernetes est devenu la plateforme d'orchestration par défaut pour les charges de travail cloud du secteur de la défense — des systèmes C2 conteneurisés et des pipelines de données de capteurs aux services d'inférence IA fonctionnant en bordure tactique. Cette adoption soulève un problème de sécurité que les guides de durcissement Kubernetes d'entreprise n'abordent pas : le modèle de menace pour une charge de travail militaire est fondamentalement différent de celui d'une application SaaS commerciale. L'adversaire dispose de ressources au niveau d'un État-nation, la menace interne possède une habilitation de sécurité, la chaîne d'approvisionnement est un vecteur d'attaque légitime, et les conséquences d'une évasion de conteneur ou d'une exfiltration de données sont une perte de données classifiées plutôt qu'une amende PCI. Le durcissement d'entreprise standard est nécessaire mais insuffisant.

Ce guide couvre la pile complète de sécurité cloud des charges militaires pour Kubernetes : le modèle de menace spécifique à la défense, l'isolation des pods, la segmentation réseau, la gestion des secrets, le durcissement RBAC, l'intégrité de la chaîne d'approvisionnement des images, la détection d'anomalies à l'exécution et l'automatisation de la conformité continue.

1. Modèle de menace Kubernetes pour la défense

Initié hostile avec accès légitime. Dans un environnement de défense, les initiés détiennent des habilitations et bénéficient d'un accès autorisé. Les contrôles doivent supposer qu'un attaquant peut s'authentifier légitimement et s'appuyer sur le principe du moindre privilège, la surveillance comportementale et des pistes d'audit inviolables plutôt que sur la seule authentification périmétrique.

Compromission de la chaîne d'approvisionnement. Les adversaires étatiques compromettent les chaînes d'approvisionnement logicielles en amont — systèmes de build, paquets open-source, images de base de conteneurs et pipelines CI/CD. Les contrôles doivent traiter chaque image de conteneur comme potentiellement compromise jusqu'à ce qu'une attestation cryptographique vérifiée prouve le contraire.

Mouvement latéral par le réseau. Les clusters Kubernetes autorisent par défaut la communication pod-à-pod sans restriction. Un attaquant qui parvient à exécuter du code dans un conteneur peut immédiatement scanner et attaquer tous les autres services du cluster. Les clusters de défense ne peuvent tolérer ce comportement par défaut.

Évasion de conteneur. Une évasion de conteneur permet au code s'exécutant dans un conteneur de briser la frontière du conteneur et de s'exécuter avec les privilèges du noyau hôte ou les droits root hôte. Pour les charges classifiées, une évasion de conteneur équivaut à un accès direct à l'hôte et potentiellement à toutes les autres charges sur ce nœud.

2. Sécurité des pods : PodSecurityAdmission et durcissement des conteneurs

PSA applique l'un des trois profils au niveau de l'espace de noms : privileged, baseline et restricted. Pour les charges militaires, le profil restricted est l'exigence de base. Étiquetez chaque espace de noms d'application avec pod-security.kubernetes.io/enforce: restricted. Le profil restricted applique : aucun conteneur privilégié, aucun partage d'espace de noms hôte, aucun utilisateur root, système de fichiers root en lecture seule, toutes les capabilities supprimées et un profil seccomp RuntimeDefault ou Localhost.

3. Politiques réseau : communication pod-à-pod en mode zéro confiance

Chaque espace de noms nécessite une NetworkPolicy de refus par défaut appliquée à la création, couvrant à la fois le trafic entrant et sortant. Calico et Cilium sont les deux plugins CNI adaptés à un usage défensif. Pour les clusters de défense en réseau isolé, le blocage du trafic sortant est non négociable. L'application eBPF de Cilium rejette les paquets non autorisés dans la pile réseau du noyau avant qu'ils n'atteignent l'application.

4. Gestion des secrets : Vault, Sealed Secrets et KMS avec module HSM

HashiCorp Vault avec l'injecteur sidecar vault-agent est la solution standard de gestion des secrets pour Kubernetes de défense. Les secrets sont écrits dans un volume tmpfs en mémoire — jamais sur disque et jamais comme variables d'environnement. Sealed Secrets permettent des workflows GitOps en chiffrant les manifestes de secrets pour un stockage Git sécurisé. Pour les niveaux de classification les plus élevés, le KMS supportant le déverrouillage automatique de Vault doit être un HSM FIPS 140-2 Level 3.

5. Durcissement RBAC : moindres privilèges, isolation des espaces de noms, journalisation d'audit

Chaque charge de travail s'exécute sous un ServiceAccount dédié avec le montage automatique de tokens désactivé par défaut. Aucun ClusterRoleBinding pour les charges applicatives. La journalisation d'audit du serveur API capture le niveau RequestResponse pour les Secrets, ConfigMaps et objets RBAC, transmis en temps réel vers un magasin de journaux externe, en ajout seul, hors de portée du blast radius d'une charge compromise.

6. Chaîne d'approvisionnement des images : signature Cosign, admission webhooks, registre privé

Chaque image porte une signature Cosign d'une clé stockée dans KMS ou HSM. Kyverno applique la vérification de signature à l'admission, bloquant tout Pod dont l'image ne porte pas de signature valide. Toutes les images de production proviennent d'un registre privé interne — aucun téléchargement depuis des registres publics n'est autorisé dans les espaces de noms de production.

7. Sécurité à l'exécution : Falco, surveillance eBPF, gVisor pour les charges non fiables

Falco surveille les appels système du noyau en temps réel via une sonde eBPF, alertant sur les shells lancés dans des conteneurs, les connexions sortantes inattendues, les écritures dans des chemins sensibles et les tentatives d'escalade de privilèges. Les alertes sont transmises au SIEM en temps réel. gVisor est utilisé pour les niveaux de charges non fiables ; les conteneurs standard avec Falco et seccomp gèrent les charges de mission sensibles à la latence.

8. Automatisation de la conformité : kube-bench, vérifications STIG, reporting continu

kube-bench exécute les vérifications CIS Kubernetes Benchmark comme tâche planifiée, avec des résultats mappés sur les identifiants de vérification DISA Kubernetes STIG pour des preuves de conformité automatisées. Les vérifications échouées au-dessus d'un seuil de gravité bloquent les promotions de pipeline CI/CD. Trivy/Grype, Checkov et Polaris complètent la pile de conformité continue.

Insight clé : Le mode d'échec le plus courant dans la sécurité Kubernetes en environnement de défense est l'écart entre ce que dit la politique d'admission et ce qui s'exécute réellement après six mois de changements opérationnels. Traitez la posture de conformité comme une métrique en temps réel, et non comme un artefact d'audit annuel. Consultez le guide complet de cybersécurité de la défense pour le cadre de contrôle environnant.

La sécurité cloud des charges militaires sur Kubernetes est un ensemble de contrôles en couches — sécurité des pods, politique réseau, Vault, durcissement RBAC, signature d'images, Falco et analyse de conformité continue — chacun adressant un vecteur de menace distinct, chacun maintenu en continu à mesure que le cluster et ses charges évoluent.