Kubernetes en air gap pour charges classifiées : RKE2, Rancher et la réalité du registre hors ligne

1. La réalité de Kubernetes en air gap

« Air-gap » signifie rarement ce que laissent entendre les présentations marketing. Dans un déploiement classifié, un air gap est une frontière homologuée : aucun chemin routable vers l'Internet public, aucune résolution DNS sortante, aucune sortie implicite pour les gestionnaires de paquets ou les runtimes de conteneurs. Chaque artefact qui franchit la frontière est journalisé, analysé et approuvé. Le cluster se comporte comme si Internet n'existait pas — parce que, pour l'autorité d'homologation, il n'existe pas.

La première réalité que sous-estiment les ingénieurs est que Kubernetes présuppose la connectivité. kubelet tire depuis registry.k8s.io. Les charts Helm référencent quay.io et docker.io. Les plugins CNI téléchargent des binaires à l'installation. Les pilotes CSI tirent des images sidecar. Les opérateurs se réconcilient en tirant de nouveaux digests d'image. Un kubeadm init vanilla sur un hôte déconnecté échoue dans la première minute.

La seconde réalité est le problème des mises à jour récurrentes. Un cluster ne s'installe pas une fois et ne reste pas figé. Les versions mineures de Kubernetes sortent tous les quatre mois. Les CVE dans containerd, runc, CoreDNS et le noyau arrivent chaque semaine. Les évaluateurs d'homologation posent une question avant toutes les autres : montrez-moi votre cadence de correctifs et la traçabilité associée. Un cluster air-gap sans pipeline de mise à jour documenté et reproductible est un cluster qui se verra refuser l'autorisation d'exploitation lors de la prochaine revue.

Tout ce qui suit découle de ces deux faits : rien ne se tire tout seul, et le cluster doit pouvoir être corrigé pendant des années.

2. Choix de la distribution — RKE2 vs K3s vs kubeadm vs OpenShift

RKE2 (Rancher Kubernetes Engine 2). La distribution durcie de SUSE/Rancher. RKE2 1.31 livre un profil CIS-1.9 prêt à l'emploi : kube-apiserver est configuré avec la politique d'audit, les contrôleurs d'admission et la posture TLS qu'exige le référentiel CIS. L'archive de version regroupe toutes les images système — kube-apiserver, kube-controller-manager, etcd, CoreDNS, le CNI (Cilium ou Canal), le contrôleur d'ingress — dans un unique rke2-images-all.linux-amd64.tar.zst. Pour l'air-gap, c'est la bonne réponse dans 80 % des cas.

K3s. Le petit frère léger. Binaire unique, etcd ou sqlite embarqué, ~50 Mo. Excellent pour les nœuds de bordure à l'intérieur de l'enclave (postes de commandement avancés, abris mobiles, passerelles de capteurs) lorsque le cluster tourne sur un seul boîtier durci. K3s 1.31 suit le même schéma d'archive air-gap que RKE2 mais avec un jeu de composants plus restreint et aucun profil durci par défaut — vous apportez votre propre politique d'admission.

kubeadm. Kubernetes amont. Flexibilité maximale, travail maximal. Chaque image de composant doit être miroitée manuellement, chaque CNI installé manuellement, chaque contrôle CIS appliqué par vos soins. Ne choisissez kubeadm que lorsque l'autorité d'homologation interdit les binaires distribués par éditeur (rare mais bien réel sur certains programmes nationaux).

OpenShift. La distribution de Red Hat. Outillage air-gap plus solide (oc mirror, Operator Lifecycle Manager avec catalogues hors ligne) et empreinte d'homologation sérieuse (FIPS 140-3, CC EAL4+ sur RHEL). Le compromis réside dans la licence — les sièges OpenShift sont coûteux et l'empreinte de la plateforme est lourde. Pour les programmes disposant déjà d'accords entreprise Red Hat, c'est la voie de moindre résistance.

Pour la plupart des engagements de défense, nous recommandons RKE2 1.31 avec Rancher 2.10 comme plan de gestion multi-cluster, à l'intérieur de l'enclave classifiée. K3s 1.31 occupe le créneau de la bordure. Kubeadm et OpenShift sont des choix propres au programme, dictés par les achats et l'homologation, non par une préférence d'ingénierie.

3. Registre d'images hors ligne

Le registre est le cœur d'une plateforme Kubernetes air-gap. Chaque pod y tire ses images. S'il tombe, le cluster se fige au prochain pull. S'il est compromis, toutes les charges de travail le sont.

Harbor 2.11. Le registre de catégorie entreprise, diplômé de la CNCF. L'intégration native avec Trivy scanne chaque image poussée pour détecter les CVE par rapport à une base de vulnérabilités hors ligne que vous synchronisez via le même processus de transfert approuvé que vos images applicatives. Harbor prend en charge la vérification de signature cosign au pull, un RBAC par projet, des politiques de réplication et un modèle de comptes robots qui s'intègre proprement aux webhooks d'admission. Pour un registre primaire à l'intérieur de l'enclave, Harbor est le choix par défaut.

zot. Le registre OCI-natif en binaire Go unique. Bien plus léger que Harbor (pas de Postgres, pas de Redis, pas de sidecar Trivy). zot 2.1 prend en charge les referrers OCI 1.1, cosign et présente une empreinte qui convient aux nœuds avancés où Harbor serait surdimensionné. Associez zot en bordure à Harbor au site central, avec une réplication unidirectionnelle.

Sonatype Nexus. Le gestionnaire d'artefacts polyglotte. Si le programme a déjà standardisé Nexus pour les miroirs Maven, npm et APT, l'ajout de dépôts Docker permet de tout conserver dans un seul outil avec un seul jeu de journaux d'audit. L'analyse de conteneurs de Nexus est plus faible que celle de Harbor ; elle se conjugue donc à un point d'analyse séparé dans le pipeline d'ingestion.

Le schéma vers lequel convergent la plupart des grands programmes est le registre de registres : un Harbor central à l'intérieur de l'enclave comme source de vérité, un zot par site ou par cluster de bordure, et une topologie de réplication documentée. Les clusters applicatifs ne tirent jamais directement depuis le Harbor central — ils tirent depuis le miroir zot local. Les domaines de défaillance restent petits. Les allers-retours réseau restent courts. Le schéma d'homologation tient sur une seule page.

4. Sneakernet et diodes unidirectionnelles

Images, charts Helm, bases de vulnérabilités, miroirs de paquets OS, dépôts GitOps — tout doit physiquement franchir la frontière. Deux schémas de transport dominent.

Sneakernet. Supports amovibles approuvés, transportés à la main. Le support est effacé, écrit, vérifié par hash, scellé, signé au passage de la frontière, vérifié par hash côté haut, ingéré dans un registre de transit, analysé, approuvé manuellement, puis promu vers le registre de production. Le cycle complet prend des heures à des jours. C'est lent, auditable et résistant à toute revue d'homologation.

Diodes de données unidirectionnelles. Transfert unidirectionnel imposé par le matériel (Owl Cyber Defense, Fox-IT DataDiode, Advenica). Le débit est réel (1 à 10 Gbit/s sur le matériel actuel) et l'absence de chemin retour est garantie en fibre, non en configuration. Les diodes fonctionnent à merveille pour la télémétrie sortant du côté haut ; pour les images entrantes, l'absence d'accusé de réception complique les reprises, si bien que la plupart des programmes associent une diode à un protocole strict de retransmission sur échec de checksum, posé par-dessus.

Les deux schémas partagent le même flux d'acceptation par étapes : réception → registre de quarantaine → analyse automatisée (Trivy, ClamAV, YARA) → désarmement et reconstruction de contenu pour tout artefact non-conteneur → approbation manuelle par un analyste → promotion vers le registre de production. Sauter l'étape de quarantaine est la cause la plus fréquente de non-conformités d'homologation.

5. GitOps en air gap

GitOps fonctionne à l'intérieur de l'enclave — à condition que chaque référence soit interne. ArgoCD 2.13 et Flux 2.4 tournent tous deux sans souci en air-gap. La boucle de réconciliation se moque que le serveur Git soit une instance Gitea ou GitLab hébergée côté haut plutôt que github.com. Ce qui casse, ce sont tous les charts Helm qui référencent un dépôt de charts externe, tous les overlays Kustomize qui tirent une base depuis un remote Git public, et tous les opérateurs qui surveillent un flux d'images externe.

Le schéma du miroir de manifestes corrige cela. Un job planifié côté bas tire les charts Helm amont, les images de conteneurs et les dépôts Git ; réécrit chaque référence externe (repository: docker.io/bitnami/postgresql devient repository: harbor.enclave.mil/bitnami/postgresql) ; valide dans un miroir Git interne ; et exporte le bundle pour le sneakernet. À l'intérieur de l'enclave, ArgoCD pointe exclusivement vers le miroir. Il n'y a pas de chemin de repli vers Internet parce qu'il n'y a pas d'Internet.

La détection de dérive sans phone-home est simple — ArgoCD calcule les diffs par rapport à l'état dans le cluster, non par rapport à un service externe. La seule fonctionnalité que vous perdez est la notification automatisée des nouvelles versions de charts amont ; cette détection se déplace vers le job de miroir côté bas, où elle aurait dû se trouver de toute façon. Pour le schéma plus général, voir notre tour d'horizon sur DevSecOps et zero trust dans le pipeline de défense.

6. Intégrité de la chaîne d'approvisionnement

Un air gap empêche l'exfiltration sortante ; il n'empêche pas une image malveillante d'arriver par le canal approuvé. L'intégrité de la chaîne d'approvisionnement est la seconde ligne de défense.

Signature cosign. Chaque image promue vers le registre de production est signée avec une clé cosign dont la racine se trouve dans le HSM de l'enclave. La signature se produit à l'étape de promotion, après l'analyse et l'approbation de l'analyste. La signature atteste « cette image a été validée par notre processus », pas « cette image est authentique en amont » — la provenance amont est vérifiée séparément au point d'ingestion côté bas.

Kyverno ou OPA Gatekeeper à l'admission. Une ClusterPolicy rejette tout pod dont l'image n'est pas signée par une clé du trust bundle de l'enclave et dont le digest n'est pas épinglé. Les références par tag (:latest, :v1) sont bloquées d'office — seuls les digests @sha256:... passent l'admission. Kyverno 1.13 est le choix le plus léger ; Gatekeeper convient aux programmes déjà investis dans Rego.

Vérification de SBOM. Chaque image signée porte un SBOM SPDX ou CycloneDX attaché en tant que referrer OCI. La politique d'admission vérifie la signature du SBOM et contrôle éventuellement la présence de composants interdits (par ex. log4j 2.x en deçà de 2.17, tout paquet figurant sur la liste noire du programme). Pour la vue d'ensemble, voir l'application des SBOM dans les pipelines de défense.

7. Opérations Day-2

La cadence de correction des CVE est le point sur lequel la plupart des programmes air-gap perdent la conversation d'homologation. La question de l'évaluateur est simple : une CVE critique a été divulguée hier — quand atterrit-elle dans votre cluster de production, et où en est la preuve ?

Une réponse défendable comporte trois niveaux. Hot-fix pour les CVE critiques activement exploitées : le pipeline d'ingestion côté bas accepte un correctif d'urgence en 24 heures, le sneakernet tourne hors cycle, le registre de production reçoit l'image corrigée en 72 heures et les enregistrements de changement d'urgence couvrent le déploiement. Fenêtre planifiée pour les CVE hautes et moyennes : des fenêtres de maintenance mensuelles font passer un lot trié par le pipeline complet d'acceptation par étapes. Mises à niveau mineures trimestrielles pour le plan de contrôle Kubernetes lui-même : les versions correctives RKE2 atterrissent d'abord dans un cluster de test, puis en production, avec un plan de rollback documenté.

Le plan de cycle de vie du cluster qui satisfait les évaluateurs d'homologation n'est pas un schéma d'une page. C'est un runbook écrit couvrant : la procédure de mise à niveau du plan de contrôle, la procédure de mise à niveau des nœuds worker, l'exercice de sauvegarde-restauration etcd (exécuté trimestriellement, pas théorique), la procédure de mise à niveau du CNI, la procédure en cas d'échec de réplication du registre, et les personnes nommément responsables de chaque tâche. Les évaluateurs les lisent. Ils remarquent quand le runbook référence un outil que l'équipe n'utilise pas réellement.

Pour le contexte d'architecture cloud plus large dans lequel vivent ces clusters, voir l'architecture cloud souverain pour la défense.

8. Fédération multi-enclaves

Une organisation de défense exploite rarement un seul cluster. Il y a une enclave non classifiée, une enclave NATO SECRET, une enclave SECRET nationale, parfois une enclave TOP SECRET pour des programmes spécifiques. L'instinct est de les « fédérer » via Kubernetes Federation v2 ou un mécanisme similaire. L'instinct se trompe.

La fédération à travers les frontières de classification est interdite par tous les cadres d'homologation sous lesquels nous avons travaillé. Le bon schéma est des clusters distincts par classification, reliés uniquement par des passerelles intersites. Chaque cluster possède son propre plan de contrôle, son propre registre, son propre dépôt GitOps, ses propres clés de signature. Les manifestes des charges partagées sont dupliqués — oui, dupliqués, avec tout le risque de dérive de version que cela implique — parce que l'alternative est un plan de contrôle fédéré qui viole la frontière.

La stratégie de duplication GitOps est la discipline opérationnelle qui rend cela gérable. Le même miroir côté bas qui produit le bundle non classifié produit un bundle NATO SECRET et un bundle SECRET national, chacun avec le même contenu amont mais des clés de signature distinctes et des destinations de registre distinctes. Les dépôts Git divergent uniquement sur la configuration propre à l'enclave (noms d'hôtes de registre, politiques réseau, références de secrets). La dérive entre enclaves est détectée par un outil de comparaison côté bas qui lit les manifestes côté public et les versions caviardées des manifestes côté haut qui reviennent par la diode.

Le flux de messages intersites — télémétrie ascendante, commandes descendantes, renseignement transversal — passe par des solutions intersites homologuées (Forcepoint Trusted Gateway, Owl, équivalents nationaux), non par une intégration au niveau Kubernetes. Le cluster ignore qu'il est multi-enclave. Chaque cluster croit être seul, et c'est cette propriété qui lui permet d'être homologué. Pour le modèle réseau qui enveloppe ces enclaves, voir zero trust sur les réseaux militaires.