Durcissement Kubernetes pour les charges de travail de défense : benchmarks CIS et directives NSA

Kubernetes est devenu la plateforme de déploiement standard pour les applications conteneurisées dans le secteur de la défense — du DoD Platform One aux programmes de cloud de défense nationaux dans les États membres de l'OTAN. Son adoption dans les environnements de défense est motivée par les mêmes avantages opérationnels qui ont conduit à son adoption commerciale : déploiement cohérent dans différents environnements, mise à l'échelle automatisée, charges de travail auto-réparables et gestion déclarative de l'infrastructure. Mais une installation Kubernetes par défaut est conçue pour la facilité d'utilisation, pas pour la sécurité — et l'écart de sécurité entre une installation par défaut et un déploiement durci de niveau défense est significatif.

La NSA et la CISA ont publié le Guide de durcissement Kubernetes (v1.2, août 2022) spécifiquement pour combler cette lacune. Le guide couvre le durcissement du plan de contrôle, la sécurité réseau, la sécurité des Pods, la journalisation d'audit ainsi que l'authentification et l'autorisation. Le CIS Kubernetes Benchmark fournit un ensemble complémentaire et plus granulaire de contrôles de configuration scorés. Ensemble, ces deux documents définissent ce que signifie « durci » pour Kubernetes dans un contexte de défense.

Guide de durcissement Kubernetes NSA/CISA : recommandations clés

Le guide NSA/CISA organise les recommandations en six catégories. Les plus significatives opérationnellement pour la défense sont :

Sécurité des Pods Kubernetes. Les Pods doivent utiliser des conteneurs non root, des systèmes de fichiers racine en lecture seule et avoir des capabilities réduites au minimum requis. Les conteneurs privilégiés — qui ont un accès complet au système hôte — ne doivent pas être autorisés dans les charges de travail de production.

Séparation et durcissement du réseau. Tout le trafic inter-services doit être chiffré à l'aide de TLS (maillage de services avec mTLS). Les politiques réseau doivent limiter la communication Pod-à-Pod aux chemins explicitement autorisés. Le serveur API Kubernetes ne doit pas être directement accessible depuis internet.

Authentification et autorisation. Le serveur API ne doit pas activer l'authentification anonyme ni les ports non sécurisés. Le contrôle d'accès basé sur les rôles (RBAC) doit être activé et configuré selon les principes du moindre privilège.

Journalisation d'audit. La journalisation d'audit du serveur API doit être activée avec une politique qui capture au moins les opérations de création, mise à jour, suppression et obtention sur les types de ressources sensibles. Les journaux d'audit doivent être transférés vers un SIEM central.

Fréquence des mises à niveau. Les versions Kubernetes reçoivent des correctifs de sécurité pendant environ 14 mois après la sortie. Exécuter des versions Kubernetes non prises en charge est un risque de sécurité significatif, inacceptable dans les déploiements de défense.

Pod Security Standards : le profil Restricted

Les Pod Security Standards (PSS) de Kubernetes définissent trois profils de politique — Privileged, Baseline et Restricted — représentant des niveaux croissants de restriction de la configuration des Pods. Le profil Restricted est la base de référence appropriée pour les charges de travail de défense : il impose les contraintes de configuration des Pods les plus importantes du point de vue de la sécurité.

Le profil Restricted interdit : les conteneurs privilégiés (conteneurs avec le flag privileged défini à true), les conteneurs s'exécutant en tant que root (imposé via runAsNonRoot: true), les conteneurs accédant au réseau hôte, les conteneurs accédant aux PIDs ou IPCs hôtes, les conteneurs montant des chemins hôtes comme volumes, et les conteneurs ajoutant des capabilities Linux au-delà d'une liste blanche définie.

L'implémentation du profil Restricted dans un environnement Kubernetes existant nécessite souvent des modifications applicatives. Pour le nouveau développement d'applications de défense, la conformité au profil Restricted doit être une exigence de conception dès le début.

Les Pod Security Standards sont imposés via le contrôleur d'admission intégré PodSecurity. Les déploiements de défense doivent utiliser le mode Enforce pour le profil Restricted dans tous les namespaces de production.

Politiques réseau : microsegmentation avec Calico ou Cilium

Les politiques réseau Kubernetes définissent quels Pods peuvent communiquer avec quels autres Pods au niveau IP/port. Sans politiques réseau, tous les Pods dans un cluster peuvent communiquer avec tous les autres Pods — une topologie réseau plate architecturalement incompatible avec les principes zero-trust. Les politiques réseau implémentent la couche de microsegmentation au niveau du réseau de conteneurs.

Calico est l'implémentation de politique réseau Kubernetes la plus largement déployée, prenant en charge les ressources Kubernetes NetworkPolicy standard et les ressources spécifiques à Calico avec des fonctionnalités supplémentaires. Pour les environnements de défense air-gapped, le modèle de déploiement sur site de Calico et l'absence de dépendances au plan de contrôle cloud le rendent opérationnellement adapté.

Cilium utilise eBPF (Extended Berkeley Packet Filter) pour l'application des politiques réseau dans le noyau Linux, offrant des performances supérieures aux solutions basées sur iptables et prenant en charge des politiques réseau de couche 7. Le composant d'observabilité Hubble de Cilium fournit une visibilité détaillée des flux réseau.

Le principe clé pour la conception des politiques réseau de défense est le refus par défaut : les nouveaux namespaces doivent avoir une NetworkPolicy par défaut qui bloque tout le trafic entrant et sortant jusqu'à la création de règles d'autorisation explicites.

Contrôleurs d'admission : Policy-as-Code avec OPA/Gatekeeper et Kyverno

Les contrôleurs d'admission sont des plugins qui interceptent les requêtes du serveur API avant qu'elles ne soient persistées dans etcd, permettant d'appliquer des politiques au niveau de l'API du cluster. OPA/Gatekeeper et Kyverno sont les deux frameworks dominants de policy-as-code pour le contrôle d'admission Kubernetes.

OPA/Gatekeeper utilise le moteur de politique OPA (Open Policy Agent) avec le langage de politique Rego. Gatekeeper s'enregistre en tant que ValidatingAdmissionWebhook qui appelle le moteur de politique OPA pour chaque requête API pertinente. Les Constraint Templates définissent la structure de la politique ; les Constraints instancient le template pour des ressources spécifiques.

Kyverno utilise le YAML natif Kubernetes pour exprimer des politiques, le rendant plus accessible aux équipes familières avec les définitions de ressources Kubernetes. Kyverno supporte à la fois la validation (blocage des ressources non conformes) et la mutation (ajout automatique des labels requis ou des champs de contexte de sécurité aux ressources qui en manquent).

Pour les déploiements de défense, les politiques de contrôle d'admission doivent imposer au minimum : la provenance des images (les images doivent provenir de registres approuvés), la signature des images (les images doivent avoir des signatures cosign valides), les exigences de contexte de sécurité, les labels requis et les limites de ressources.

Sécurité à l'exécution : Falco, seccomp et AppArmor

Falco (diplômé CNCF) est l'outil de sécurité à l'exécution standard pour Kubernetes : il surveille les appels système du noyau en temps réel et génère des alertes lorsque le comportement correspond à des patterns suspects. Les règles Falco couvrent l'exécution de processus, l'accès aux fichiers, l'activité réseau et l'activité de l'API Kubernetes. Falco s'intègre avec les systèmes SIEM via la sortie syslog ou Webhook.

Les profils seccomp (secure computing mode) restreignent les appels système disponibles pour les processus de conteneurs. Kubernetes fournit un profil seccomp par défaut (RuntimeDefault) qui bloque les appels système les plus dangereux. Les charges de travail de défense doivent utiliser au minimum le profil RuntimeDefault.

AppArmor (sur les distributions Linux qui le prennent en charge) fournit une couche de contrôle d'accès obligatoire qui restreint ce que chaque processus peut accéder en termes de fichiers, capabilities et opérations réseau. Les profils AppArmor pour les conteneurs Kubernetes ajoutent une couche de défense en profondeur.