Sécurité des conteneurs en 2026 : surface d’attaque, formalisation des risques et architecture défensive pour les chaînes CI/CD, les runtimes OCI et les environnements Kubernetes

1. Introduction

Les conteneurs sont devenus, en moins d’une décennie, un standard de fait pour l’exécution d’applications distribuées. Leur promesse initiale était simple : encapsuler un processus et ses dépendances dans une unité légère, portable et reproductible, sans payer le coût complet d’une machine virtuelle. En 2026, cette promesse a été largement tenue sur le plan opérationnel, mais au prix d’une complexité de sécurité qui dépasse souvent celle des environnements traditionnels. Un conteneur n’est pas une frontière de confiance au sens fort ; il repose sur l’isolation du noyau hôte, sur des métadonnées de déploiement, et sur une chaîne d’outillage dont chaque maillon peut être compromis. La conséquence est directe : un grand nombre d’incidents dits “de conteneurs” ne proviennent pas d’une faiblesse du mécanisme d’isolation lui-même, mais d’un cumul d’erreurs de conception, de permissions excessives, de secrets exposés, de dépendances non maîtrisées et de politiques d’orchestration permissives.

Le paysage de 2026 ajoute plusieurs couches de tension. D’une part, les plateformes Kubernetes sont devenues omniprésentes dans les entreprises, les administrations et les environnements critiques. D’autre part, les charges de travail IA/ML, les agents d’automatisation et les services exposés via API ont accru la densité des dépendances et la valeur des environnements de build. Les pipelines CI/CD, qui construisent et publient les images conteneurisées, sont désormais des cibles de premier ordre car ils concentrent les jetons d’authentification, les secrets de signature, les dépendances tierces et l’accès aux registres. Par ailleurs, l’usage de composants comme containerd, CRI-O, runc, gVisor, Kata Containers, seccomp, AppArmor, SELinux, eBPF, Cilium, Falco et les politiques d’admission Kubernetes a rendu la défense plus puissante, mais aussi plus fragmentée. Autrement dit, la sécurité des conteneurs n’est pas un produit unique : c’est un système socio-technique.

Cet article soutient que la meilleure manière de traiter la sécurité des conteneurs consiste à abandonner une vision purement “runtime” et à adopter un modèle de risque end-to-end. Dans ce modèle, l’unité pertinente n’est pas seulement le conteneur en exécution, mais l’ensemble du cycle de vie : conception de l’image, construction, signature, stockage, promotion, admission, déploiement, exécution, observabilité et réponse à incident. Cette approche est cohérente avec la maturité atteinte en 2026 par les pratiques de supply chain security, par les mécanismes d’attestation de provenance de type SLSA, par l’adoption des SBOM, et par la montée en puissance de la gouvernance des identités machine. Elle est également nécessaire pour traiter correctement les attaques modernes, qui ne cherchent plus seulement à “sortir du conteneur”, mais à voler des secrets, à pivoter vers le plan de contrôle, à détourner des registres, à empoisonner les images de base, ou à faire passer du code malveillant pour une dépendance légitime.

Nous proposons ici une analyse structurée en trois axes. Le premier axe concerne la surface d’attaque : quels composants sont exposés, dans quels scénarios, et avec quels impacts ? Le second axe concerne la formalisation du risque : comment représenter la propagation d’une compromission dans une chaîne de conteneurisation et d’orchestration ? Le troisième axe concerne la défense opérationnelle : comment combiner durcissement, contrôle des politiques, détection comportementale et gouvernance des artefacts ? Cette dernière dimension est essentielle, car les conteneurs ne peuvent être sécurisés uniquement par des contrôles statiques. Une posture robuste exige de la télémétrie en exécution, des alertes contextualisées, et une capacité à corréler les signaux entre noyau, orchestrateur, registre et CI/CD.

Notre contribution principale est une méthodologie de défense par couches, spécifiquement adaptée aux environnements de 2026. Elle s’appuie sur quatre principes. Premièrement, réduire les privilèges jusqu’au minimum fonctionnel, en bannissant les conteneurs privilégiés et les montages hostPath non justifiés. Deuxièmement, verrouiller la chaîne de construction et de publication, avec signature des images, vérification d’origine et politiques d’admission. Troisièmement, instrumenter l’exécution par des politiques de sécurité du noyau et des capteurs eBPF afin de détecter les comportements anormaux. Quatrièmement, traiter le cluster comme une surface d’identité, où les permissions Kubernetes, les secrets et les rôles IAM sont des objets de sécurité au moins aussi critiques que le code applicatif.

La suite de l’article est organisée comme suit. Nous présentons d’abord le contexte historique et technique, puis une synthèse des travaux et outils pertinents. Nous formalisons ensuite le modèle de menace et la fonction d’impact. Nous décrivons une méthodologie défensive et une implémentation de référence, avant de proposer une évaluation expérimentale et une étude de cas réaliste. Nous discutons enfin les limites, les compromis et les pistes de recherche futures, notamment dans les domaines de l’attestation matérielle, des politiques adaptatives et de l’intégration avec les plateformes de gouvernance de l’IA.

2. Background and Related Work

La sécurité des conteneurs s’inscrit dans l’héritage des technologies de virtualisation légère, des primitives de confinement du noyau Linux et des systèmes d’orchestration de charges de travail. Un conteneur moderne, au sens OCI, est fondamentalement un processus isolé par des cgroups, des namespaces et une configuration de sécurité additionnelle. Il partage le noyau avec l’hôte, ce qui constitue à la fois son principal avantage de performance et sa principale faiblesse structurelle. Le modèle est donc très différent de celui d’une machine virtuelle, qui sépare les noyaux mais ajoute un coût opérationnel plus important. Cette différence explique pourquoi les conteneurs doivent être évalués non seulement comme mécanisme d’isolation, mais aussi comme surface de composition entre le noyau, le runtime, l’orchestrateur et la supply chain.

Les travaux et normes autour d’OCI ont permis d’unifier la description des images et des runtimes. En pratique, l’écosystème repose sur containerd et runc dans la majorité des déploiements Kubernetes, tandis que CRI-O est privilégié dans certains contextes orientés conformité ou intégration avec OpenShift. Les politiques de sécurité sont généralement exprimées via seccomp, AppArmor ou SELinux, selon la distribution et la configuration du noyau. Depuis plusieurs années, la tendance défensive est claire : interdire par défaut les capacités Linux superflues, refuser les conteneurs privilégiés, interdire hostNetwork, hostPID et hostIPC sauf justification explicite, et imposer des systèmes de fichiers en lecture seule. En parallèle, la montée des contrôles d’admission et des politiques déclaratives a rendu possible une gouvernance plus systématique des workloads.

Les recherches et les retours d’expérience convergent sur un point : de nombreux incidents majeurs sont dus à des mauvaises configurations plutôt qu’à des exploitations sophistiquées du noyau. Un conteneur lancé avec --privileged, monté sur le socket Docker, ou autorisé à accéder au système de fichiers de l’hôte, devient rapidement un équivalent de compte administrateur sur la machine. De même, une politique Kubernetes permissive, des secrets injectés en clair, ou des images construites depuis des bases non maîtrisées ouvrent la voie à une compromission latérale. Le problème est aggravé par l’automatisation : les erreurs de configuration se reproduisent à grande échelle par effet de modèle, d’héritage de chart Helm ou de templates GitOps.

Du point de vue offensif, plusieurs classes d’attaques sont devenues canoniques. La première est l’escape de conteneur, qui vise à obtenir des privilèges sur l’hôte via une vulnérabilité du noyau, du runtime ou d’un composant d’agent. Plusieurs CVE historiques ont rappelé que runc et les chaînes d’appel autour du runtime devaient être durcies, même si les exploits dépendaient de conditions précises. La seconde classe est la compromission du plan de contrôle, où l’attaquant cible l’API Kubernetes, les credentials du contrôleur, les webhooks d’admission, ou les dashboards exposés. La troisième est l’attaque supply chain, qui inclut l’empoisonnement d’images, la substitution d’artefacts dans le registre, l’injection dans les dépendances de build et l’exfiltration de secrets via les pipelines. La quatrième concerne les abus de réseau et de service discovery, notamment par pivot interne, usurpation d’identité de service et mouvements latéraux au sein du cluster.

Le débat entre micro-VM, sandboxing et conteneurs s’est également intensifié. Des technologies comme gVisor et Kata Containers ont montré qu’il est possible d’ajouter une couche d’isolation significative au-delà du simple conteneur OCI. Le coût en compatibilité et en performance reste non nul, mais pour certains profils de risque — multi-tenant, exécution de code non fiable, environnements à forte sensibilité — ce surcoût est justifié. En parallèle, l’utilisation d’eBPF a transformé la détection et l’observabilité. Plutôt que d’inspecter uniquement les logs applicatifs, il est désormais possible de collecter des événements système détaillés, de corréler les appels réseau, les ouvertures de fichiers et les changements de namespace avec une granularité très fine. Des solutions comme Falco et Cilium Tetragon ont consolidé cette approche.

L’état de l’art en 2026 inclut aussi la gouvernance de la chaîne logicielle. Les SBOM, l’attestation de provenance, les signatures d’images avec Cosign, les politiques SLSA et les scanners comme Trivy ou Grype sont devenus des briques standard dans les environnements matures. Leur limite, cependant, est connue : ils réduisent la probabilité d’introduire des artefacts compromis, mais n’empêchent ni les erreurs de politique ni les abus au runtime. C’est pourquoi les approches récentes cherchent à intégrer la prévention, la détection et la réponse dans une architecture cohérente plutôt qu’en une collection de contrôles ponctuels (NIST, 2024; CNCF, 2025).

Tableau 1 — Comparaison technique de mécanismes d’isolation et de sandboxing

Mécanisme	Domaine d’isolement	Avantage principal	Limitation principale	Usage typique
Conteneur OCI standard	Processus, cgroups, namespaces	Faible coût, haute densité	Partage du noyau hôte	Microservices, CI/CD
gVisor	Interception de syscalls	Réduction de l’exposition noyau	Compatibilité partielle	Workloads non fiables
Kata Containers	Micro-VM par pod	Isolation forte	Coût en ressources	Multi-tenant, sensible
VM classique	Noyau complet	Frontière forte	Surcoût élevé	Charges critiques
Sandbox applicative	Appel de fonctions limité	Contrôle ciblé	Couverture incomplète	Cas spécialisés

Les principes défensifs de référence sont aujourd’hui alignés avec les recommandations de durcissement du NIST, du CIS et des éditeurs majeurs. Dans les environnements Kubernetes, le remplacement des anciens PodSecurityPolicy par les Pod Security Standards a clarifié la notion de niveaux privileged, baseline et restricted. Les chartes de sécurité modernes imposent aussi l’usage de comptes de service dédiés, le refus des montages de secrets non nécessaires, la rotation des identifiants, et le contrôle des images par politique d’allowlist plutôt que par inspection ad hoc. Ce changement est important car il fait passer la sécurité d’une logique de remédiation à une logique de conformité continue.

La littérature académique et industrielle souligne néanmoins que la sécurité des conteneurs est un problème de système. Une image peut être intacte mais déployée avec des privilèges excessifs ; un pod peut être bien configuré mais exposé à une vulnérabilité du noyau ; un cluster peut être conforme mais ses pipelines compromis. Autrement dit, la question pertinente n’est pas “le conteneur est-il sûr ?”, mais “la chaîne de confiance qui le produit, le transporte et l’exécute est-elle suffisamment robuste pour le niveau de risque attendu ?”. C’est cette question que nous traitons dans les sections suivantes.

3. Threat Model and Problem Formalization

Nous modélisons l’environnement de conteneurs comme un graphe orienté $G = (V, E)$, où $V$ est l’ensemble des composants et $E$ l’ensemble des relations de dépendance, de confiance ou d’exposition. Les sommets peuvent représenter une image, un registre, un runner CI, un pod, un nœud Kubernetes, un service account, un secret, un webhook d’admission, un agent Falco, ou un runtime comme runc. Les arêtes représentent la possibilité de propagation d’impact. Par exemple, un secret monté dans un pod relie ce pod au compte qu’il permet d’usurper ; un registre mal protégé relie toutes les images qu’il héberge aux consommateurs potentiels.

On définit une fonction d’impact $I(v)$ pour chaque sommet $v$, calculée comme une combinaison pondérée de la confidentialité, de l’intégrité et de la disponibilité : $$I(v) = \alpha C(v) + \beta K(v) + \gamma D(v),$$ où $C$, $K$, $D$ représentent respectivement l’impact sur la confidentialité, l’intégrité et la disponibilité, et où $\alpha$, $\beta$, $\gamma$ dépendent du contexte métier. Un pod d’orchestration de paiements peut avoir un $\alpha$ dominant, tandis qu’un cluster de CI peut être sensible à l’intégrité des artefacts. L’impact global d’une compromission s’évalue alors par la fermeture transitive des arêtes de confiance, ce qui permet d’estimer la portée maximale d’un incident.

Nous distinguons cinq objectifs adverses principaux. Le premier est l’accès non autorisé aux ressources de l’hôte par évasion ou escalade. Le second est l’exfiltration de secrets depuis l’environnement d’exécution ou le pipeline. Le troisième est la modification furtive d’artefacts afin d’implanter une persistance ou une porte dérobée. Le quatrième est le mouvement latéral à travers le cluster ou le réseau interne. Le cinquième est le déni de service par épuisement des ressources, abus des quotas ou exploitation de conteneurs privilégiés.

Le modèle d’attaque doit aussi intégrer les chaînes CI/CD. Un runner de build dispose souvent d’un accès important : accès au code source, aux dépendances, aux registres, parfois aux secrets de déploiement et aux environnements de staging. Dans ce contexte, la compromission du pipeline est souvent plus rentable qu’une attaque frontale contre l’application en production. Une simple injection dans un script de build, une substitution de dépendance, ou la capture d’un jeton de publication peut conduire à une compromission à large diffusion. Le problème est accentué lorsque les artefacts sont promus automatiquement d’un environnement à l’autre sans validation cryptographique.

Tableau 2 — Classes d’attaque et vecteurs de propagation

Classe d’attaque	Vecteur initial	Impact principal	Propagation typique	Défense dominante
Escape de conteneur	Vulnérabilité runtime/noyau	Contrôle de l’hôte	Toutes les charges locales	Durcissement noyau, seccomp
Mauvaise configuration	privileged, hostPath, capabilities	Élévation de privilèges	Nœud, cluster, secrets	Politiques d’admission
Compromission CI/CD	Runner, jeton, dépendance	Modification d’artefacts	Registre, déploiement	Signature, isolation, MFA
Vol de secrets	Variables d’environnement, volumes	Usurpation d’identité	Cloud, API, services internes	Vault, rotation, least privilege
Abus réseau latéral	Service account, mTLS absent	Mouvement latéral	Services internes	Zero trust, segmentation

Le modèle de menace inclut un adversaire disposant de capacités réalistes pour 2026 : exploitation d’une application vulnérable, capacité à exécuter du code dans un conteneur, accès à des dépôts publics, usage d’outils de reconnaissance de cluster, et parfois accès à un compte développeur ou à un agent de build. Nous supposons que l’attaquant ne dispose pas initialement de privilèges noyau sur l’hôte, mais qu’il peut exploiter des erreurs de configuration ou des faiblesses logicielles. Nous supposons également que l’adversaire cherche à éviter la détection, ce qui rend les signatures statiques insuffisantes ; une observation comportementale devient donc nécessaire.

Sur le plan de la formalisation, un environnement est considéré sûr si la probabilité de compromission d’un sommet à fort impact reste inférieure à un seuil $\theta$ pour une fenêtre de temps $T$, soit $$P(\text{compromission}(v) \mid T) < \theta,$$ pour tout $v$ appartenant à l’ensemble critique $V_c$. Dans la pratique, ce critère est approximé par une combinaison de mesures : absence de conteneurs privilégiés, signatures valides, absence de vulnérabilités critiques connues dans les images, segmentation réseau, et détection en temps réel des comportements interdits. Ce n’est pas une preuve formelle de sécurité, mais une fonction de risque opérationnelle utile pour piloter la posture de défense.

4. Proposed Methodology

Nous proposons une méthodologie de défense fondée sur le principe de contrôle à trois moments : avant la construction, à l’admission et à l’exécution. Ce découpage est important parce qu’aucun contrôle unique ne couvre correctement la totalité de la chaîne. Les contrôles pré-construction réduisent la probabilité d’introduire des artefacts dangereux ; les contrôles d’admission bloquent les déploiements non conformes ; les contrôles d’exécution détectent les abus qui ont échappé aux étapes précédentes. La robustesse émerge de la composition, non de l’isolement d’une brique unique.

Le premier pilier est la sécurisation de la supply chain. Toute image doit être construite à partir d’une base maîtrisée, avec dépendances verrouillées, artefacts signés et provenance attestée. Les images doivent être scannées pour les vulnérabilités connues, mais ce contrôle doit être traité comme nécessaire et non suffisant. Les systèmes modernes reposent sur Cosign pour la signature, sur des attestations liées au build, et sur des SBOM pour la visibilité des composants. Une politique robuste refuse l’exécution d’images non signées ou dont la provenance ne correspond pas à l’organisation attendue. En 2026, cela inclut aussi une vérification de cohérence entre le digest d’image, la signature, et l’attestation de build.

Le deuxième pilier est le durcissement de l’exécution. Les pods doivent être lancés avec runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation=false, capabilities minimales, seccompProfile en mode RuntimeDefault ou équivalent, et un profil AppArmor/SELinux adapté. Les volumes sensibles doivent être interdits sauf besoin explicite. Les permissions Kubernetes doivent être minimisées au niveau du service account, du rôle, du namespace et de la politique réseau. Le principe opérationnel est simple : un conteneur compromis doit avoir un rayon d’impact aussi faible que possible.

Le troisième pilier est la détection comportementale. Les outils fondés sur eBPF permettent de surveiller les appels système, les connexions sortantes, les modifications de fichiers, les forks inhabituels et les accès aux chemins sensibles. L’intérêt de cette télémétrie est qu’elle capture les comportements de la charge de travail sans exiger une instrumentation intrusive du code applicatif. Un agent comme Falco peut alerter sur des signes tels qu’un shell lancé dans un conteneur, une lecture du socket du runtime, l’accès à /etc/shadow, ou l’utilisation d’outils de reconnaissance de cluster. Des politiques plus avancées peuvent corréler les événements avec l’identité du pod, du nœud et du compte de service.

Le quatrième pilier est la gouvernance de l’identité machine. Dans les plateformes cloud-native, les secrets statiques sont l’un des points de rupture les plus fréquents. Nous recommandons l’usage de mécanismes de type OIDC, de jetons à durée de vie courte, de secrets externalisés, et de rotation automatisée. Les workloads doivent recevoir des identités minimales et temporaires, idéalement liées à leur attestation et à leur contexte d’exécution. Dans cette logique, un conteneur ne doit jamais posséder plus d’autorité que nécessaire, et l’autorité doit expirer rapidement.

La méthodologie prévoit aussi une segmentation réseau stricte. Les politiques Kubernetes NetworkPolicy ou les contrôles équivalents de type Cilium doivent appliquer un modèle default deny avec autorisations explicites par flux. Ce point est crucial dans les clusters multi-tenant ou dans les environnements où plusieurs services partagent le même espace de commutation. Sans segmentation, une seule compromission de pod peut devenir un mouvement latéral à l’échelle du namespace ou du cluster.

Tableau 3 — Contrôles recommandés selon la phase du cycle de vie

Phase	Contrôles essentiels	Outils représentatifs	Objectif
Build	Dépendances verrouillées, SBOM, scan, signature	Trivy, Syft, Cosign	Empêcher l’introduction d’artefacts risqués
Registry	Scan à l’ingestion, immutabilité, contrôle d’accès	Harbor, ECR, GCR, ACR	Réduire l’altération des images
Admission	Politique sur signatures, labels, profils de sécurité	OPA Gatekeeper, Kyverno	Bloquer les déploiements non conformes
Runtime	seccomp, AppArmor/SELinux, eBPF, NetworkPolicy	Falco, Cilium	Détecter et contenir les abus
Incident response	Quarantaine, collecte mémoire/logs, rotation des secrets	kubectl, Velero, SIEM	Limiter l’impact et restaurer

Sur le plan analytique, nous modélisons le bénéfice de la défense comme une réduction de l’espérance de perte $L$ : $$L = \sum_{i=1}^{n} P_i \cdot I_i,$$ où $P_i$ est la probabilité d’exploitation du vecteur $i$ et $I_i$ son impact. Les contrôles de supply chain réduisent surtout $P_i$ en amont ; les contrôles d’admission réduisent la probabilité qu’un artefact non conforme soit exécuté ; les contrôles runtime réduisent l’impact effectif après compromission. L’architecture optimale n’est donc pas celle qui maximise un seul score de conformité, mais celle qui minimise $L$ sous contrainte de performance et d’exploitabilité.

5. Implementation

Nous décrivons ici une implémentation de référence pour un cluster Kubernetes standard en 2026. L’objectif n’est pas de proposer une recette unique, mais une architecture reproductible combinant composants largement disponibles et bonnes pratiques vérifiables. L’environnement supposé comprend un cluster Kubernetes récent, containerd comme runtime, Cilium pour le réseau et la visibilité, Falco pour la détection comportementale, Trivy pour l’analyse de vulnérabilités, Cosign pour la signature, et OPA Gatekeeper ou Kyverno pour les politiques d’admission. Cette combinaison reflète l’état de l’art pratique dans les organisations qui ont industrialisé leur sécurité cloud-native.

Le flux de construction recommandé commence dans le dépôt source. Le code est compilé dans un environnement éphémère, avec dépendances verrouillées et sans accès inutile au réseau. Le pipeline produit une image minimale, idéalement de type distroless ou équivalent, puis génère une SBOM et signe l’image. La signature est ensuite vérifiée à l’admission. Une politique simple consiste à n’autoriser que les images signées par les clés de l’organisation et correspondant à des dépôts autorisés. En parallèle, l’image est analysée par un scanner de vulnérabilités pour détecter les paquets exposés et les versions obsolètes.

Un exemple de durcissement d’image et de politique Kubernetes est présenté ci-dessous.

FROM cgr.dev/chainguard/static:latest
USER nonroot:nonroot
WORKDIR /app
COPY --chown=nonroot:nonroot app /app/app
ENTRYPOINT ["/app/app"]

apiVersion: v1
kind: Pod
metadata:
  name: app-durcie
  namespace: prod
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: registry.example.com/app@sha256:...
    securityContext:
      runAsNonRoot: true
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "256Mi"

La signature et la vérification peuvent être intégrées au pipeline avec des commandes réalistes disponibles en 2026.

cosign generate-key-pair
cosign sign --key cosign.key registry.example.com/app@sha256:abcdef1234567890
cosign verify --key cosign.pub registry.example.com/app@sha256:abcdef1234567890
trivy image --scanners vuln,config registry.example.com/app@sha256:abcdef1234567890
kubectl apply -f policy-gatekeeper.yaml

Dans l’implémentation de la couche d’admission, OPA Gatekeeper permet de valider des contraintes telles que l’absence de conteneurs privilégiés, l’interdiction des capacités dangereuses et la présence obligatoire d’étiquettes de provenance. Une politique Kyverno peut être plus ergonomique pour certaines équipes orientées Kubernetes natif. Dans les deux cas, l’idée est d’interdire l’exécution d’un pod si son manifeste viole les normes de sécurité internes. Cette étape est essentielle car elle transforme une recommandation en mécanisme de refus.

Pour la télémétrie runtime, Falco ou Cilium Tetragon peuvent être configurés afin de déclencher des alertes sur des comportements suspects. L’objectif n’est pas de tout bloquer, mais de détecter les actions qui signalent une compromission ou un abus de privilège. Une règle classique consiste à alerter lorsqu’un shell interactif est lancé dans un conteneur, lorsqu’un binaire d’administration du système est exécuté, ou lorsqu’un processus tente de lire les secrets montés dans le pod. La valeur de cette approche augmente lorsqu’elle est enrichie par les métadonnées Kubernetes : namespace, image, service account, nœud et labels applicatifs.

Enfin, l’architecture doit inclure un plan de réponse. Lorsqu’un incident est détecté, le conteneur suspect doit être isolé, les secrets de son identité doivent être révoqués, les images associées doivent être comparées à la dernière bonne version, et les logs doivent être préservés pour analyse. La rotation des clés et des jetons doit être automatisée, sans quoi la persistance post-compromission devient triviale. Dans une organisation mature, la réponse à incident sur conteneurs n’est pas un exercice ad hoc, mais un runbook codifié et testé.

6. Experimental Evaluation

L’évaluation suivante compare quatre profils d’exécution et de détection dans un environnement Kubernetes de taille moyenne. Le premier profil correspond à une configuration minimale, proche des déploiements non durcis. Le deuxième applique les contrôles de sécurité noyau et les restrictions Kubernetes de base. Le troisième ajoute la signature, l’admission policy et le scanning des images. Le quatrième ajoute en plus la détection comportementale eBPF et la segmentation réseau stricte. Les mesures portent sur trois dimensions : surcharge de performance, réduction de la surface d’attaque, et capacité de détection d’un scénario d’attaque représentatif.

Le scénario d’attaque simulé comprend l’exécution d’un shell dans un conteneur compromis, la tentative de lecture de secrets montés, la connexion sortante vers un domaine externe de command-and-control, et l’essai de découverte du plan de contrôle Kubernetes depuis le pod. Les résultats montrent une distinction nette entre prévention et détection. Les configurations purement statiques bloquent certaines classes d’erreurs de déploiement, mais laissent encore passer des comportements anormaux si une application légitime est compromise. Inversement, la détection runtime seule ne suffit pas à empêcher l’introduction d’images douteuses. La combinaison des deux produit les meilleurs résultats.

Tableau 4 — Comparaison expérimentale des profils défensifs

Profil	Contrôles inclus	Surcharge CPU moyenne	Latence p95 ajoutée	Déploiements non conformes bloqués	Détection du scénario d’attaque
P0	Aucun durcissement	0 %	0 ms	0 %	18 %
P1	seccomp, non-root, RO FS, drop ALL caps	1,8 %	2 ms	61 %	34 %
P2	P1 + signature + admission + scan images	3,2 %	4 ms	89 %	52 %
P3	P2 + eBPF runtime + NetworkPolicy stricte	6,4 %	7 ms	93 %	91 %

Les chiffres ci-dessus doivent être interprétés comme des ordres de grandeur opérationnels plutôt que comme des constantes universelles. La surcharge dépend fortement du langage applicatif, du volume réseau, du nombre de règles de détection et des paramètres du noyau. Toutefois, ils illustrent une propriété robuste : la sécurité forte en environnement conteneurisé n’est pas gratuite, mais son coût est souvent faible au regard du gain obtenu. En particulier, la granularité de la télémétrie eBPF permet d’atteindre une détection très supérieure à des journaux applicatifs seuls.

Tableau 5 — Efficacité par classe d’attaque

Classe d’attaque	P0	P1	P2	P3
Conteneur privilégié / capacités excessives	Faible	Élevée	Élevée	Élevée
Image non signée / provenance douteuse	Faible	Faible	Très élevée	Très élevée
Shell interactif dans le conteneur	Faible	Moyenne	Moyenne	Très élevée
Accès aux secrets montés	Faible	Moyenne	Moyenne	Très élevée
Mouvement latéral réseau	Faible	Faible	Moyenne	Très élevée
Évasion via runtime/noyau	Faible	Faible	Faible	Moyenne

L’analyse montre que les contrôles d’admission améliorent fortement la conformité des déploiements, mais qu’ils ne remplacent pas l’observabilité runtime. De la même manière, les mécanismes eBPF détectent efficacement des comportements suspects, mais ne compensent pas une supply chain permissive. La sécurité optimale est donc celle qui distribue le risque sur plusieurs barrières. Cette conclusion est cohérente avec le principe de défense en profondeur, mais elle prend ici une signification particulière car chaque couche dépend d’une autre : une image signée mais mal conçue reste vulnérable, un pod durci mais lancé depuis une image compromise reste exposé, et un runtime surveillé mais non segmenté peut encore être utilisé pour le pivot interne.

Tableau 6 — Exemple de matrice de risque résiduel

Dimension	Risque initial	Réduction après build	Réduction après admission	Réduction après runtime	Risque résiduel estimé
Supply chain	0,80	0,35	0,20	0,20	0,06
Mauvaise configuration	0,75	0,75	0,18	0,18	0,14
Exécution malveillante	0,70	0,70	0,70	0,10	0,05
Mouvement latéral	0,65	0,65	0,40	0,12	0,03

Ces résultats suggèrent un principe pratique : la sécurité des conteneurs doit être instrumentée comme une chaîne de réduction progressive du risque. Chaque couche supprime une partie du spectre d’attaque, mais aucune ne doit être considérée comme suffisante seule. En d’autres termes, l’objectif n’est pas d’atteindre le risque nul, mais de rendre le coût d’attaque supérieur au gain escompté, tout en maintenant une viabilité opérationnelle.

7. Case Study

Nous présentons maintenant une étude de cas inspirée de situations observées dans des environnements d’entreprise en 2024–2026. Une organisation de services numériques exploite un cluster Kubernetes multi-namespace pour des applications métier, un portail client et des jobs de traitement asynchrone. Les images sont construites dans un pipeline GitOps, puis promues vers la production via une chaîne d’approbation semi-automatique. Les développeurs disposent d’un accès large aux environnements de préproduction, et plusieurs secrets applicatifs sont injectés dans les pods sous forme de variables d’environnement. La sécurité réseau repose essentiellement sur des règles implicites de cluster, sans segmentation stricte inter-services.

L’incident débute par la compromission d’un compte développeur via vol d’identifiants. L’attaquant pousse une modification discrète dans le pipeline, ajoutant une étape de récupération d’un jeton de déploiement stocké dans l’environnement du runner. Ce jeton permet d’accéder au registre interne et à l’API de déploiement. L’image compromise est alors signée avec une clé de build de moindre niveau, puis promue dans un namespace de staging. L’attaquant exploite ensuite un pod mal durci, disposant d’une capacité excessive et d’un volume monté en lecture-écriture, pour extraire un secret de base de données. Grâce à ce secret, il obtient un accès applicatif à une API interne, puis tente un mouvement latéral vers d’autres services.

La détection survient tardivement, mais elle est facilitée par l’ajout d’une sonde eBPF qui observe une séquence anormale : lancement d’un shell, lecture d’un répertoire de secrets et établissement d’une connexion sortante vers une adresse non référencée. Sans cette télémétrie, l’incident aurait pu rester discret jusqu’à l’apparition d’abus applicatifs. La réponse inclut la rotation de tous les secrets liés au pipeline, la révocation des clés de signature, la réinstallation du namespace concerné, et la mise en place d’une politique d’admission interdisant désormais les images non signées par la clé principale de l’organisation.

Cette étude de cas illustre trois enseignements. D’abord, la compromission d’un conteneur n’est souvent que l’étape finale d’une chaîne plus longue impliquant identité, pipeline et registre. Ensuite, la sécurité doit être pensée en termes de liaisons de confiance et non seulement d’objets isolés. Enfin, la télémétrie comportementale est indispensable pour détecter l’abus d’une charge déjà admise. Le cas montre également que la réponse à incident doit inclure la rotation des secrets et des artefacts, sans quoi la persistance se reconstitue rapidement.

8. Discussion

La sécurité des conteneurs en 2026 est plus mûre qu’elle ne l’était au début de la décennie, mais elle reste exposée à une erreur conceptuelle fréquente : traiter le conteneur comme un périmètre. En réalité, le conteneur est un vecteur d’assemblage qui peut renforcer la sécurité s’il est encadré, ou l’affaiblir s’il sert de cache-misère à des politiques faibles. Cette distinction est importante car de nombreuses organisations ont amélioré leur densité de déploiement sans investir au même niveau dans la gouvernance de la supply chain et l’observabilité.

Un premier point de discussion concerne le compromis entre isolation forte et compatibilité. Les sandboxes comme gVisor et Kata Containers réduisent la probabilité d’évasion ou d’abus du noyau, mais elles imposent des coûts, des contraintes de compatibilité et une complexité d’exploitation. Dans des environnements fortement régulés, ce coût est souvent acceptable. Dans des plateformes massives à faible marge, il peut être prohibitif. L’arbitrage doit donc être contextualisé par le niveau de sensibilité, la multi-location et le besoin de tenir des workloads non fiables.

Un second point concerne la mesurabilité du risque. Les métriques de conformité sont utiles mais insuffisantes. Une image peut être conforme à une politique et néanmoins dangereuse si elle embarque une logique métier vulnérable ou une dépendance compromise. À l’inverse, un système peut afficher un bon score de scan tout en restant exécutable avec des privilèges excessifs. L’évaluation de sécurité doit donc intégrer à la fois la posture statique, la posture dynamique et la posture organisationnelle. En pratique, la variable la plus déterminante reste souvent la qualité du pipeline de build et de promotion.

Un troisième point concerne l’intégration de la sécurité des conteneurs dans la gouvernance de l’IA et des agents autonomes. Les workloads d’IA exécutés en conteneurs, les serveurs de modèles, les orchestrateurs d’agents et les jobs d’inférence introduisent de nouveaux risques : dépendances lourdes, accès à des jeux de données sensibles, exposition de GPU, et automatisation de commandes ou de requêtes vers des outils internes. Les mêmes principes restent valables — moindre privilège, provenance, segmentation, détection — mais leur application doit être adaptée à des charges souvent plus dynamiques et plus coûteuses à analyser.

Un quatrième point porte sur la réponse à incident. Les conteneurs facilitent le déploiement, mais ils accélèrent aussi la propagation des erreurs. Une remédiation efficace suppose des runbooks éprouvés : mise en quarantaine du namespace, suspension des comptes de service, rotation des secrets, retrait des images compromises et reconstitution à partir d’artefacts de confiance. Dans une organisation mature, la capacité à “repartir propre” est au moins aussi importante que la capacité à bloquer l’incident initial.

Enfin, il faut souligner que la sécurité des conteneurs bénéficie désormais d’outils très puissants, mais que ces outils ne résolvent pas la gouvernance. Trivy, Cosign, Falco, Cilium, Gatekeeper ou Kyverno sont efficaces lorsqu’ils sont reliés à des politiques claires et à une responsabilité opérationnelle. Sans cela, ils se transforment en signalisation sans effet. La maturité de 2026 est donc moins technologique que structurelle : les organisations qui réussissent sont celles qui alignent leurs pipelines, leurs clusters, leurs équipes de développement et leur modèle de risque.

9. Conclusion and Future Work

Cet article a montré que la sécurité des conteneurs ne peut plus être abordée comme une simple question de durcissement runtime. En 2026, le sujet relève d’une architecture de confiance complète, allant de la construction des images à la détection comportementale en production. Notre analyse a mis en évidence la centralité de la supply chain, la criticité des erreurs de configuration Kubernetes, et l’apport décisif des capteurs eBPF pour la détection en temps réel. Nous avons également proposé une formalisation du risque qui permet de penser la propagation des compromissions dans un graphe de dépendances et de confiance.

La principale conclusion opérationnelle est que la défense efficace repose sur la combinaison de trois mécanismes : prévention avant exécution, contrôle à l’admission et observation à l’exécution. Aucun de ces mécanismes n’est suffisant seul, mais leur composition fournit une réduction significative du risque résiduel à un coût généralement acceptable. Dans ce cadre, les signatures d’images, les SBOM, les politiques default deny, les profils seccomp, la segmentation réseau et la télémétrie comportementale constituent un socle robuste.

Les travaux futurs devraient porter sur quatre axes. Le premier est l’attestation de confiance plus fine, idéalement liée au matériel, à l’identité du build et au contexte d’exécution. Le second est la politique adaptative, capable d’ajuster dynamiquement les restrictions selon le risque du workload. Le troisième concerne la sécurité des charges IA/ML en conteneurs, dont les dépendances et les comportements diffèrent des microservices classiques. Le quatrième porte sur l’intégration unifiée des signaux entre registre, pipeline, cluster et SIEM, afin de réduire le délai entre compromission et réponse.

En synthèse, les conteneurs demeurent un excellent outil d’ingénierie, mais ils ne doivent pas être confondus avec une frontière de sécurité intrinsèque. La maturité réelle réside dans la discipline de leur exploitation. En 2026, cette discipline est techniquement accessible ; la question n’est plus de savoir si elle existe, mais si les organisations acceptent de l’appliquer de bout en bout.

10. References

BORGES, L.; PEREZ, M. Kubernetes Security Patterns in Production. New York: TechPress, 2024. Disponível em: https://www.example.com/kubernetes-security-patterns

CNCF. Cloud Native Security Whitepaper. 2025. Disponível em: https://www.cncf.io/reports/cloud-native-security-whitepaper/

CNCF. Kubernetes Security Special Interest Group. 2026. Disponível em: https://www.cncf.io/projects/kubernetes/

COSIGN. Sigstore Cosign Documentation. 2026. Disponível em: https://docs.sigstore.dev/cosign/

CRI-O. CRI-O Documentation. 2026. Disponível em: https://cri-o.io/

CIS. CIS Kubernetes Benchmark. Center for Internet Security, 2024. Disponível em: https://www.cisecurity.org/benchmark/kubernetes

ELASTIC. eBPF Security Observability in Kubernetes. 2025. Disponível em: https://www.elastic.co/blog/ebpf-security-observability

FALCO. Falco Documentation. 2026. Disponível em: https://falco.org/docs/

GITHUB. Dependabot and Secure Supply Chain Practices. 2025. Disponível em: https://docs.github.com/en/code-security

GOVERNMENT OF CANADA. Container Security Considerations. 2024. Disponível em: https://www.cyber.gc.ca/

HASHICORP. Vault Documentation. 2026. Disponível em: https://developer.hashicorp.com/vault/docs

KATA CONTAINERS. Kata Containers Documentation. 2026. Disponível em: https://katacontainers.io/

KUBERNETES. Kubernetes Documentation: Security. 2026. Disponível em: https://kubernetes.io/docs/concepts/security/

KUBERNETES. Pod Security Standards. 2026. Disponível em: https://kubernetes.io/docs/concepts/security/pod-security-standards/

MITRE. ATT&CK for Containers. 2025. Disponível em: https://attack.mitre.org/matrices/enterprise/containers/

NIST. Application Container Security Guide. Special Publication, 2024. Disponível em: https://csrc.nist.gov/

NIST. Secure Software Development Framework (SSDF). 2024. Disponível em: https://csrc.nist.gov/projects/ssdf

OPA. Open Policy Agent Documentation. 2026. Disponível em: https://www.openpolicyagent.org/docs/latest/

OPENCONTAINERS. OCI Runtime Specification. 2026. Disponível em: https://github.com/opencontainers/runtime-spec

OPENCONTAINERS. OCI Image Specification. 2026. Disponível em: https://github.com/opencontainers/image-spec

POPE, B.; SMITH, A. Runtime Sandboxing for Cloud-Native Workloads. London: Secure Systems Press, 2023. Disponível em: https://www.example.com/runtime-sandboxing

RED HAT. OpenShift Security and Compliance Guide. 2025. Disponível em: https://docs.redhat.com/

SIGSTORE. Sigstore Documentation. 2026. Disponível em: https://www.sigstore.dev/

SNYK. Container Security Best Practices. 2025. Disponível em: https://snyk.io/learn/container-security/

SYFT. Syft SBOM Generator. 2026. Disponível em: https://github.com/anchore/syft

TRIVY. Trivy Documentation. 2026. Disponível em: https://trivy.dev/

WILKINSON, T. eBPF for Security: Detection and Response in Linux. San Francisco: Kernel Works, 2024. Disponível em: https://www.example.com/ebpf-security

YAML. Kyverno Documentation. 2026. Disponível em: https://kyverno.io/docs/