Kubernetes entre enclaves de sécurité : clusters multi-classification

Les programmes de défense fonctionnent rarement à un seul niveau de classification. Le même logiciel de mission qui ingère des flux open source dans une enclave Unclassified possède souvent une variante Secret qui le fusionne avec une collecte sensible, et parfois une variante Top Secret par-dessus. L'instinct d'un ingénieur habitué au Kubernetes commercial est de modéliser ces niveaux comme des espaces de noms, des locataires ou des clusters virtuels au sein d'une seule plateforme. Cet instinct est erroné pour le travail classifié, et se tromper coûte cher à défaire. Dans un environnement multiniveau sécurisé (MLS), le cluster Kubernetes – et le réseau sur lequel il repose – est la frontière de classification, pas un détail de location en son sein. Cet article explique comment exécuter Kubernetes entre enclaves de sécurité : un cluster accrédité par niveau de classification, une isolation stricte des politiques au sein de chacun, une provenance d'image vérifiable et une promotion contrôlée et unidirectionnelle des artefacts entre domaines.

La frontière est le cluster, pas l'espace de noms

Kubernetes vous offre plusieurs mécanismes qui ressemblent à de l'isolation : espaces de noms, NetworkPolicies, RBAC, quotas de ressources et contrôle d'admission. Chacun d'eux est un contrôle de location opérant au sein d'une seule frontière de confiance. Ils partagent tous le même serveur API, le même magasin de données etcd, le même noyau Linux sur chaque nœud et le même runtime de conteneurs. Une évasion de conteneur via une vulnérabilité du noyau, une faille dans le chemin d'autorisation du serveur API ou un seul ClusterRoleBinding trop large peut franchir d'un coup chacune de ces frontières souples.

Un accréditeur examinant un système MLS pose une question simple : qu'est-ce qui empêche physiquement ou cryptographiquement les données Secret d'atteindre le côté Unclassified ? « Une NetworkPolicy » n'est pas une réponse acceptable, car une NetworkPolicy est imposée par le même plugin CNI et le même noyau sur lesquels s'exécutent les charges de travail elles-mêmes. La réponse acceptée est la séparation : clusters séparés, réseaux séparés, matériel séparé ou partitions cryptographiquement isolées séparées, chacune accréditée pour traiter exactement un niveau. Les espaces de noms restent utiles – mais seulement comme compartiments administratifs au sein d'une seule enclave, jamais comme la ligne entre Unclassified et Secret.

C'est le même principe qui sous-tend les solutions cross-domain pour la défense : les données ne se déplacent entre niveaux que via un garde accrédité, jamais via un contrôle logiciel partagé que les deux côtés peuvent atteindre. Kubernetes multi-enclave applique simplement ce principe à la couche d'orchestration.

Un cluster par enclave : la topologie de référence

La topologie de référence pour un programme à trois niveaux est de trois déploiements Kubernetes entièrement indépendants, un par enclave :

Enclave Unclassified / de développement. C'est là que se déroule l'essentiel de l'ingénierie. Elle dispose de la connectivité la plus large (souvent un chemin vers internet via un proxy pour tirer les dépendances amont), de la cadence de changement la plus permissive et du pipeline de build qui produit les artefacts que les enclaves supérieures consommeront finalement. Elle est tout de même durcie – réseau par défaut refusé, images signées, pas de pods privilégiés – mais c'est la seule enclave où naissent de nouvelles images.

Enclave Secret. Déconnecté de l'internet public, ce cluster exécute la variante Secret du logiciel de mission. Il ne tire des images que de son propre registre intra-enclave, qui est alimenté exclusivement par promotion depuis le bas. Sa cadence de changement est plus lente et chaque déploiement est lié à une version accréditée. La discipline opérationnelle ici ressemble à un déploiement Kubernetes en air gap – registres hors ligne, pas de tirages amont en direct et un processus de mise à niveau qui doit survivre à l'accréditation.

Enclave Top Secret. Le cluster le plus restreint, sur le réseau le plus isolé, avec les contrôles de personnel et physiques les plus stricts. Il reçoit un sous-ensemble organisé d'artefacts du côté Secret, encore une fois uniquement via un transfert accrédité.

Chaque enclave est un univers Kubernetes complet et autosuffisant : son propre plan de contrôle et etcd, son propre CNI et ses classes de stockage, son propre registre d'images, son propre fournisseur d'identité et RBAC, son propre contrôleur GitOps et sa propre pile d'observabilité. Rien dans une enclave supérieure ne dépend de la joignabilité d'un service d'une enclave inférieure à l'exécution. Cette indépendance est ce qui permet à chaque cluster d'être accrédité selon ses propres termes.

Pourquoi la fédération entre niveaux est un canal caché

Le raccourci tentant est de fédérer l'identité, la distribution d'images ou GitOps entre les enclaves afin que les opérateurs aient une seule console. Résistez-y. Une fédération d'authentification en direct qui émet un jeton utilisable à la fois côté Unclassified et côté Secret est, par définition, un canal en temps réel entre les deux niveaux – exactement ce que la séparation est censée empêcher. La présence ou l'absence d'une connexion réussie, le timing des rafraîchissements de jeton, voire les codes d'erreur peuvent encoder de l'information à travers la frontière. La même logique exclut un registre partagé dans lequel les deux côtés écrivent, ou un contrôleur GitOps unique réconciliant des clusters à différents niveaux. Tout ce qui maintient une connexion synchrone à travers la frontière est un canal caché potentiel et ne passera pas l'examen.

Isolation des politiques au sein de chaque enclave

La séparation entre enclaves est nécessaire mais pas suffisante. Au sein de chaque cluster, vous avez toujours besoin d'un cloisonnement rigoureux, car une enclave héberge de nombreuses charges de travail, services et équipes qui ne devraient pas s'atteindre librement. C'est là que les contrôles natifs de Kubernetes gagnent leur place.

Commencez par le contrôle d'admission. Un moteur de politiques tel que Kyverno ou OPA Gatekeeper impose des règles non négociables au moment où une charge de travail est admise : seules les images signées du propre registre de l'enclave peuvent s'exécuter ; aucun pod ne peut demander le mode privilégié, le réseau hôte ou les montages de chemin hôte ; chaque conteneur s'exécute en tant qu'utilisateur non-root avec un système de fichiers racine en lecture seule et un ensemble de capacités abandonné ; et chaque espace de noms respecte le profil restreint des Pod Security Standards. Ce sont les mêmes contrôles de durcissement traités en profondeur dans le durcissement de Kubernetes pour les charges de travail de défense, appliqués de manière identique dans chaque enclave afin que la base de référence ne dérive pas entre niveaux.

Le réseau au sein de l'enclave est par défaut refusé. Chaque espace de noms commence par une NetworkPolicy qui abandonne tout le trafic entrant et sortant, et la connectivité est accordée explicitement par paire de services. Le trafic est-ouest entre compartiments sensibles s'effectue via mutual TLS, généralement à travers un service mesh, de sorte que l'identité d'une charge de travail – et non simplement sa position réseau – contrôle l'accès. Les quotas de ressources et les plages de limites empêchent une seule charge de travail compromise ou défaillante d'affamer le cluster.

RBAC et la discipline de secours

Le RBAC au sein de chaque enclave suit le moindre privilège sans exception. Les opérateurs au quotidien obtiennent des rôles limités à un espace de noms ; personne ne détient de cluster-admin permanent. La capacité cluster-admin vit derrière une procédure de secours : un identifiant scellé, dont l'utilisation déclenche une alerte et dont chaque action est enregistrée dans un stockage d'audit immuable. Parce que les enclaves sont indépendantes, la procédure de secours est indépendante aussi – l'utiliser dans l'enclave Secret n'accorde rien dans l'enclave Unclassified. Les comptes de service sont limités à un seul espace de noms, leurs jetons sont de courte durée et liés à une charge de travail spécifique, et aucun d'eux n'est jamais réutilisé entre clusters.

Provenance des images : confiance gagnée au build, vérifiée à l'exécution

Dans une architecture multi-enclave, la chaîne d'approvisionnement est la surface d'attaque la plus attrayante, car une image construite une fois côté bas peut finalement s'exécuter au niveau Top Secret. Chaque image doit donc porter une provenance vérifiable que l'enclave la plus haute peut contrôler sans faire confiance à aucune enclave inférieure à l'exécution.

La discipline est : construire dans l'enclave la plus basse capable de construire l'image, générer une nomenclature logicielle complète (SBOM) au format SPDX ou CycloneDX, l'analyser par rapport à une base de données de vulnérabilités mise en miroir dans cette enclave, et signer à la fois l'image et le SBOM avec une clé Sigstore Cosign. La signature lie l'empreinte de l'image à un processus de build connu. Chaque enclave exécute son propre registre – Harbor et zot sont les choix courants pour un fonctionnement déconnecté – et le contrôleur d'admission de chaque cluster vérifie la signature Cosign par rapport à une clé publique spécifique à l'enclave avant d'autoriser l'image à s'exécuter. Une image non signée, ou dont l'empreinte ne correspond pas à l'enregistrement promu, ne démarre jamais.

Cela compte à travers la frontière car le cluster côté haut ne fait pas confiance au registre côté bas ; il fait confiance à la signature cryptographique et à l'empreinte enregistrée lors de la promotion. Même si le registre côté bas était compromis après la promotion d'une image, le côté haut rejetterait tout substitut dont l'empreinte diffère de celle qu'il a enregistrée.

Promotion contrôlée entre domaines

La promotion est la seule manière sanctionnée par laquelle un artefact franchit une frontière d'enclave, et elle est strictement de bas en haut. Le chemin passe par une solution cross-domain accréditée ou, pour les liaisons les plus strictes, un data diode matériel qui permet physiquement le transfert dans une seule direction.

Le garde de transfert effectue un véritable travail, pas une simple copie. Il valide l'empreinte de l'image et la signature Cosign par rapport à une liste d'autorisation d'artefacts approuvés ; il inspecte le SBOM et rejette toute image contenant un composant interdit, une licence non approuvée ou un paquet connu pour être vulnérable au-dessus du seuil du programme ; il supprime ou normalise les métadonnées susceptibles de transporter des données cachées ; et il journalise le transfert avec l'identité de l'opérateur, l'horodatage et l'empreinte de l'artefact dans un enregistrement d'audit des deux côtés. Ce n'est qu'après que chaque contrôle est passé que l'artefact est écrit dans le registre côté haut, où le cluster haut peut le tirer.

Le déplacement de haut en bas est la direction dangereuse et est traité en conséquence. Tirer des journaux, des métriques ou de la télémétrie de build d'une enclave Secret vers une enclave Unclassified est une fuite potentielle, donc c'est soit interdit purement et simplement, soit acheminé via un examen séparé, bien plus strict, avec adjudication humaine de chaque enregistrement publié. La posture par défaut est que les données circulent vers le haut et y restent.

GitOps et opérations sans franchir la ligne

Chaque enclave exécute son propre contrôleur GitOps – Argo CD ou Flux – réconciliant par rapport à un dépôt Git qui réside au sein de cette enclave. Les manifestes d'état désiré pour l'enclave supérieure sont eux-mêmes des artefacts qui sont promus vers le haut via la solution cross-domain, examinés de la même manière que les images. Cela préserve la piste d'audit (le dépôt côté haut enregistre exactement ce qui a été promu et par qui) sans jamais connecter un contrôleur à travers la frontière.

L'observabilité suit la même règle. Falco pour la détection des menaces à l'exécution, le journal d'audit Kubernetes, les métriques Prometheus et les journaux de conteneurs centralisés s'exécutent tous au sein de chaque enclave et alimentent un SIEM local à l'enclave. La télémétrie ne sort jamais en flux d'une enclave haute vers un tableau de bord côté bas ; si une image opérationnelle fusionnée et inter-niveaux est réellement requise, elle est construite en exportant des résumés examinés vers l'enclave la plus haute, pas en tirant la télémétrie brute vers le bas. La rétention d'audit est définie par enclave pour répondre à l'exigence d'accréditation de cette enclave, et la surveillance continue – réanalyses de vulnérabilités par rapport au miroir intra-enclave, détection de dérive, revérification périodique des signatures d'images – s'exécute indépendamment dans chaque cluster.

Ce que cela coûte, et pourquoi cela en vaut la peine

Exécuter trois clusters indépendants au lieu d'un seul cluster multi-tenant représente véritablement plus de travail : trois plans de contrôle à patcher, trois registres à alimenter, trois fournisseurs d'identité, trois pipelines GitOps et un processus de promotion entre eux. Les ingénieurs ressentent la friction chaque fois qu'une image qui fonctionne côté bas doit être promue avant de pouvoir s'exécuter plus haut. Mais cette friction est la propriété de sécurité, pas un défaut de celle-ci. La porte de promotion est l'endroit où la provenance est vérifiée, où les composants interdits sont attrapés et où un enregistrement complet et immuable de ce qui a franchi la frontière est créé. Effondrer les enclaves en un seul cluster pour économiser des efforts échangerait une architecture accréditable et défendable contre un seul noyau partagé et un serveur API se tenant entre Unclassified et Secret – un échange qu'aucun accréditeur n'acceptera et qu'aucun programme ne devrait vouloir.

Pour les équipes qui doivent aussi maintenir les enclaves supérieures déconnectées, les modèles opérationnels s'associent naturellement à une pratique Kubernetes en air gap : registres hors ligne, dépendances mises en miroir et une discipline de mise à niveau qui ne suppose pas de chemin en direct vers le monde extérieur.