Sécurité des conteneurs en 2026 : modélisation des risques, durcissement de la chaîne d’exécution et détection eBPF des compromissions multi-tenant

1. Introduction

Les conteneurs ont transformé la manière dont les applications sont développées, déployées et opérées. Ils ont permis une densification considérable des charges, une standardisation des artefacts logiciels, et une accélération du cycle de livraison qui a redéfini les attentes en matière de disponibilité et de vélocité. En pratique, cette mutation a aussi déplacé la difficulté défensive vers un espace plus fragmenté : images construites à partir de dépendances transitoires, orchestrateurs largement automatisés, privilèges dynamiques, politiques déclaratives, et chaînes CI/CD exposées à des attaques de type supply chain. Dans les organisations matures, le conteneur n’est plus perçu comme une simple unité d’exécution, mais comme un nœud dans une chaîne socio-technique où chaque maillon — développeur, pipeline, registre, runtime, noyau, réseau, secret manager, IAM — peut devenir un point de rupture.

En 2026, la sécurité des conteneurs doit être comprise dans un contexte où les attaquants exploitent des combinaisons de faiblesses, et non un seul défaut isolé. L’abus de CAP_SYS_ADMIN, les montages de /var/run/docker.sock, les volumes hostPath, les conteneurs privilégiés, les images issues de registres non signés, les secrets injectés en clair, les politiques Kubernetes permissives et les journaux de runtime insuffisants constituent des facilitateurs classiques. Mais la réalité opérationnelle inclut également des scénarios plus subtils : empoisonnement d’artefacts de build, détournement de runners CI, exploitation d’outils d’administration embarqués, ou persistance via mutation d’objets Kubernetes. L’essor de l’IA appliquée à la défense n’annule pas ces risques ; il les rend parfois plus visibles sans les neutraliser, car la qualité d’une détection dépend toujours de signaux observables, de règles d’agrégation et de contexte métier.

La problématique centrale est donc la suivante : comment concevoir une défense des conteneurs qui soit à la fois mesurable, opérationnelle et résiliente face à des adversaires capables d’abuser des couches applicatives et système dans un environnement cloud-native fortement automatisé ? Une réponse crédible doit aller au-delà du scanning d’images ou de la simple revue des manifests. Elle doit intégrer une formalisation des actifs et des menaces, une hiérarchisation des contrôles, et une stratégie de télémétrie orientée noyau et orchestration. L’usage d’eBPF, désormais mature en production dans plusieurs plateformes de sécurité en 2026, permet d’observer des événements à faible niveau avec un coût acceptable, tout en conservant une granularité suffisante pour relier des comportements à des TTP connues.

Ce papier défend l’idée qu’une sécurité de conteneurs efficace est une composition de barrières plutôt qu’une barrière unique. Formellement, si l’on modélise le risque global comme une fonction des probabilités d’exposition des différentes couches, alors la réduction de surface est plus robuste lorsque plusieurs mécanismes indépendants réduisent simultanément la probabilité de succès. On peut schématiser cela par : $$ R = \sum_{i=1}^{n} P(E_i) \cdot I(E_i) $$ où $P(E_i)$ est la probabilité d’occurrence d’un événement de compromission et $I(E_i)$ son impact. La stratégie défensive vise à réduire à la fois $P(E_i)$ par durcissement et $I(E_i)$ par segmentation, moindre privilège et détection rapide.

L’apport principal de cet article est triple. Premièrement, nous proposons une formalisation pragmatique de la menace adaptée à l’écosystème conteneurisé de 2026. Deuxièmement, nous présentons une méthodologie de défense couvrant la chaîne de livraison, le runtime et l’orchestrateur, avec une emphase sur la vérification d’intégrité et la télémétrie. Troisièmement, nous décrivons une implantation réaliste basée sur des outils et cadres réellement disponibles en 2026, notamment Kubernetes, containerd, gVisor, Falco, Cilium, Kyverno, Sigstore, cosign, Trivy, Grype, Syft et des capteurs eBPF. L’ambition n’est pas de proposer un idéal théorique, mais un cadre exploitable par des équipes de sécurité et d’exploitation confrontées à des clusters hétérogènes, à des contraintes de performance et à des obligations de conformité.

2. Background and Related Work

L’histoire de la conteneurisation contemporaine s’enracine dans les primitives Linux de compartimentation : namespaces, cgroups, seccomp, capabilities POSIX, AppArmor et SELinux. Les conteneurs modernes n’ajoutent pas un nouveau modèle de confinement fondamental ; ils orchestrent des mécanismes existants de manière plus ergonomique, avec un écosystème d’outillage qui a démocratisé leur adoption. Ce point est essentiel, car il rappelle qu’un conteneur compromis n’échoue pas forcément par défaut de “technologie conteneur”, mais bien souvent par mauvaise composition des contrôles sous-jacents. La littérature académique et industrielle a progressivement convergé vers ce constat : la sécurité n’est pas une propriété émergente automatique, elle est une conséquence d’architectures et de politiques correctement configurées (MERKEL, 2014; PAWLOWSKI, 2018).

Les travaux sur les attaques de conteneurs ont mis en évidence plusieurs classes dominantes. La première concerne l’évasion ou la rupture d’isolement, généralement via un défaut de configuration, une vulnérabilité du noyau ou une capacité excessive. Les CVE historiques comme CVE-2019-5736 dans runc, CVE-2024-21626 dans runc, ou les vecteurs liés à l’overlay filesystem et aux montages sensibles ont montré que le runtime n’est pas un simple détail d’implémentation, mais une surface critique. La seconde classe porte sur l’abus du plan de contrôle Kubernetes : comptes de service trop privilégiés, objets mutables, webhooks, accès au kubelet, exec abusif, port-forward, et secrets exposés. La troisième concerne la chaîne de livraison : images construites à partir de composants vulnérables, pipelines contaminés, dépendances compromise, ou signatures absentes. Les attaques de supply chain ont particulièrement gagné en importance après les incidents ayant touché les registres d’images, les dépôts de paquets et les systèmes CI/CD. La quatrième classe regroupe les abus multi-tenant dans les environnements partagés, où la résidence de charges de travail hétérogènes dans un même nœud accroît la valeur des primitives d’observation et d’interférence.

La recherche en durcissement s’est organisée autour de plusieurs familles de contrôles. Les politiques de sécurité Pod Security Standards de Kubernetes ont remplacé les anciens PodSecurityPolicy dépréciés, en établissant des niveaux privileged, baseline et restricted. Les mécanismes d’admission dynamique comme OPA Gatekeeper et Kyverno permettent d’exprimer des contraintes telles que l’interdiction des conteneurs privilégiés, la restriction des images non signées, ou l’obligation de readOnlyRootFilesystem. Les solutions de signature et d’attestation, notamment Sigstore, cosign et rekor, ont rendu plus pratique l’adoption de la validation cryptographique des artefacts. Les outils de détection et de conformité tels que Trivy, Grype, Syft, Checkov, kube-bench, kube-hunter et kubescape ont standardisé des contrôles de surface. Cependant, ces outils ne sont pas interchangeables : certains se concentrent sur les vulnérabilités, d’autres sur les mauvaises configurations, d’autres encore sur la traçabilité d’artefacts.

Les travaux sur la détection runtime se sont accélérés avec l’essor d’eBPF. L’observabilité noyau s’est imposée comme une réponse à la faiblesse des journaux applicatifs dans les conteneurs, souvent éphémères et pauvres en contexte. Des solutions telles que Falco, Tetragon et des agents basés sur libbpf ont démontré la capacité à capturer des séquences comportementales : ouvertures de fichiers sensibles, lancement de shell interactif, création de sockets, accès à des namespaces, mount, ptrace, chargement de modules ou appels système anormaux. La maturité d’eBPF en 2026 ne signifie pas absence de risque ; elle implique plutôt que la défense dispose enfin d’un plan de télémétrie suffisamment profond pour identifier des TTP au plus près de leur exécution.

Le champ des politiques de moindre privilège a également mûri. Les seccomp profiles se sont généralisés, la réduction des capabilities est devenue une pratique standard, et les environnements comme gVisor ou Kata Containers ont offert des couches supplémentaires de séparation en isolant l’exécution de certaines charges. Les architectures à sandbox renforcée ont toutefois des coûts : latence, complexité opérationnelle, compatibilité applicative. C’est pourquoi les évaluations empiriques montrent souvent qu’un compromis sélectif — sandbox pour charges à risque, conteneur standard pour charges internes contrôlées — maximise le rapport bénéfice/coût.

Table 1. Comparaison synthétique des principaux mécanismes de protection des conteneurs

Mécanisme	Couche	Avantage principal	Limite principale	Maturité en 2026
seccomp	Runtime	Réduction des appels système	Faux positifs sur charges hétérogènes	Élevée
AppArmor/SELinux	Hôte	Confinement MAC	Complexité de profilage	Élevée
Admission control	Orchestrateur	Prévention ex ante	Dépend de la qualité des politiques	Très élevée
Signature/attestation	Supply chain	Intégrité et provenance	Adoption incomplète	Élevée
eBPF runtime detection	Observabilité	Détection comportementale fine	Tuning et coût d’exploitation	Très élevée
Sandbox renforcée (gVisor, Kata)	Isolation	Réduction du blast radius	Surcoût et compatibilité	Élevée

En synthèse, la littérature et les retours d’expérience convergent vers une idée simple : la sécurité des conteneurs n’est efficace que si elle traite simultanément l’artefact, l’environnement, l’exécution et la gouvernance. Une approche centrée sur une seule couche crée une illusion de contrôle. À l’inverse, une approche multi-couche, corrélée et mesurable permet d’absorber les défauts locaux sans transformer un incident en compromission de domaine.

3. Threat Model and Problem Formalization

Notre modèle de menace considère un environnement Kubernetes ou assimilé, exécutant des conteneurs Linux sur des nœuds mutualisés, avec intégration à une chaîne CI/CD, un registre d’images et des services de secrets. L’attaquant peut être externe, interne malveillant, ou disposer d’un point d’entrée applicatif légitime. Il peut viser la confidentialité, l’intégrité, la disponibilité, ou la persistance au sein du cluster. En 2026, il faut aussi intégrer des attaquants capables d’exploiter des flux automatisés, des identités de charge de travail, et des artefacts signés de manière trompeuse si les politiques de validation sont mal conçues.

Les actifs critiques sont les suivants : les images conteneurisées, les secrets de déploiement, les jetons de service, les identités IAM liées aux pods, les objets Kubernetes, les nœuds sous-jacents, le plan de contrôle et les pipelines de livraison. Les frontières de confiance sont fragmentées : un namespace n’est pas une frontière de sécurité absolue ; un cluster n’est pas un périmètre monolithique ; un registre privé n’est pas garanti fiable si sa chaîne d’alimentation est compromise. Le problème est donc celui de la composition correcte de barrières imparfaites.

Nous formalisons la compromission d’un conteneur par un triplet $\langle A, V, C \rangle$, où $A$ est l’actif visé, $V$ la vulnérabilité exploitable et $C$ la capacité de l’attaquant à l’exploiter dans le contexte donné. Le succès d’une attaque dépend d’une fonction : $$ S = f(A, V, C, P, D) $$ où $P$ représente les protections actives et $D$ la capacité de détection/réponse. Une politique de sécurité n’est donc utile que si elle réduit $S$ suffisamment pour que le coût d’attaque dépasse le bénéfice attendu. En pratique, nous cherchons à minimiser : $$ \mathbb{E}[L] = \sum_{i=1}^{n} p_i \cdot l_i $$ où $p_i$ est la probabilité de succès de la chaîne d’attaque $i$ et $l_i$ la perte attendue. Cette formalisation permet d’intégrer les contrôles de prévention, de confinement et de détection comme des facteurs multiplicatifs plutôt que des objectifs indépendants.

Le modèle de menace distingue cinq vecteurs principaux. Le premier est l’abus de configuration, par exemple les privilèges, les montages d’hôte, les variables d’environnement sensibles ou l’usage de hostNetwork. Le deuxième est l’exploitation de vulnérabilités logicielles dans le runtime, le noyau ou les bibliothèques. Le troisième est l’attaque de la supply chain, incluant les registres, les dépendances, les images de base et les pipelines. Le quatrième est l’exfiltration d’identifiants via accès aux fichiers, à la mémoire ou aux métadonnées cloud. Le cinquième est la persistance et le mouvement latéral, souvent réalisés par modification d’objets Kubernetes, de règles réseau ou de secrets.

Table 2. Surface d’attaque typique dans un cluster conteneurisé

Surface	Exemple	Impact	Contrôle principal
Image	Paquet vulnérable, binaire trojanisé	Exécution initiale	Signature, SBOM, scanning
Pod spec	privileged: true, hostPath	Évasion ou accès hôte	Admission control
Node	Kernel vulnérable, cgroups abusés	Compromission du nœud	Patch, hardening, sandbox
Control plane	RBAC excessif, webhook malveillant	Persistance cluster-wide	IAM, audit, segmentation
CI/CD	Runner compromis, secret exposé	Supply chain compromise	Isolation, attestations
Runtime	Shell interactif, ptrace, mount	Lateral movement local	eBPF, seccomp

Le problème de défense peut alors être énoncé comme suit : étant donné un ensemble de workloads $W$, des contraintes de performance $B$ et une matrice de risques $R$, déterminer l’ensemble de contrôles $K$ minimisant le risque résiduel sous contrainte budgétaire. Formellement : $$ \min_{K} \sum_{w \in W} R_w(K) \quad \text{sous la contrainte} \quad Cost(K) \leq B $$ Cette formulation reflète la réalité opérationnelle, où la défense parfaite est inatteignable et où l’optimisation doit tenir compte de la latence, du coût humain et de la compatibilité applicative. Les organisations qui réussissent sont celles qui alignent la politique de sécurité sur les profils de risque réels des charges, plutôt que d’imposer une uniformité punitive.

4. Proposed Methodology

Nous proposons une méthodologie en quatre couches : prévention de la livraison, validation à l’admission, confinement à l’exécution, et détection comportementale. L’hypothèse centrale est que la sécurité des conteneurs repose sur la réduction simultanée du risque avant déploiement et pendant exécution. Cette approche est inspirée des architectures zéro confiance arrivées à maturité en 2026 : aucun artefact ni aucune identité n’est considéré comme intrinsèquement fiable, et chaque transition de confiance doit être prouvée.

La première couche consiste à sécuriser la supply chain. Toute image candidate doit produire un SBOM conforme à CycloneDX ou SPDX, être signée par une identité vérifiée, et être associée à une attestation de provenance. Les outils Syft et cosign s’intègrent naturellement dans cette étape. La politique recommandée est de refuser tout déploiement d’image ne possédant pas simultanément un hash attendu, une signature valide, et une provenance attestée. Cette exigence réduit la probabilité d’introduction d’artefacts frauduleux ou altérés.

La deuxième couche est l’admission control. Des politiques Kyverno ou OPA Gatekeeper peuvent bloquer les configurations dangereuses : privileged, hostPID, hostNetwork, hostPath non justifié, absence de runAsNonRoot, absence de readOnlyRootFilesystem, capabilities excessives, images sans digest, ou absence de limite de ressources. Les politiques doivent être versionnées et traitées comme du code. L’objectif n’est pas seulement de refuser ce qui est connu comme dangereux, mais d’imposer une norme d’expressivité minimale à chaque workload.

La troisième couche est le confinement runtime. Ici, nous combinons seccomp, AppArmor ou SELinux, réduction des capabilities, sandboxing sélectif (gVisor, Kata Containers) et durcissement du runtime (containerd, runc). La stratégie consiste à attribuer des profils de protection selon le niveau de sensibilité de la charge. Une charge exposée à l’extérieur ou manipulant des données réglementées peut être exécutée sous sandbox renforcée, alors qu’un microservice interne à faible criticité peut rester sur le runtime standard mais avec politiques strictes. Cette différenciation optimise le coût sans sacrifier la sécurité là où elle est la plus nécessaire.

La quatrième couche est la détection. Nous exploitons des capteurs eBPF pour observer des événements tels que le lancement de shell, l’accès à des fichiers de secret, la création de sockets inhabituelles, les appels mount, les accès à /proc, l’ouverture de namespaces, ou les connexions vers des destinations non approuvées. Les règles doivent être corrélées avec le contexte Kubernetes : namespace, service account, image digest, nœud, label d’application, et phase du cycle de vie. La même action — par exemple curl depuis un conteneur — n’a pas le même sens selon qu’elle se produit dans un pod de build, un pod applicatif ou un pod de base de données.

Table 3. Contrôles recommandés par étape du cycle de vie

Étape	Contrôle	Outil typique	Objectif
Build	SBOM + signature	Syft, cosign	Provenance
Registry	Scan vulnérabilités	Trivy, Grype	Réduction des défauts
Admission	Policy as code	Kyverno, Gatekeeper	Prévention
Runtime	Confinement	seccomp, AppArmor, gVisor	Limitation d’impact
Observabilité	Télémétrie noyau	Falco, Tetragon	Détection
Réponse	Isolation/kill/cordon	kubectl, SIEM, SOAR	Containment

L’approche repose aussi sur un classement du risque. Nous définissons un score : $$ \text{RiskScore} = \alpha \cdot \text{Exposure} + \beta \cdot \text{Privilege} + \gamma \cdot \text{Connectivity} + \delta \cdot \text{Sensitivity} - \epsilon \cdot \text{Controls} $$ avec $\alpha, \beta, \gamma, \delta, \epsilon > 0$. Cette fonction n’a pas vocation à être universelle ; elle sert à prioriser les efforts. Un pod exposé à Internet, disposant d’un compte de service privilégié, avec accès aux secrets et au réseau interne, doit recevoir un traitement radicalement plus strict qu’un batch éphémère sans données sensibles.

Deux principes gouvernent enfin la mise en œuvre. Le premier est la réversibilité : tout contrôle doit pouvoir être testé, mesuré et ajusté sans casser l’exploitation. Le second est la traçabilité : toute décision de sécurité doit être expliquable à partir d’un signal, d’une règle et d’un contexte. Sans cela, l’adoption s’effondre rapidement sous le poids des exceptions.

5. Implementation

L’implémentation de la méthodologie peut être réalisée sur un cluster Kubernetes standard, avec containerd comme runtime, un registre privé, et un pipeline CI/CD intégrant build, signature et admission. Nous avons retenu une architecture réaliste et largement disponible en 2026 : Trivy pour le scanning, Syft pour le SBOM, cosign pour la signature, Kyverno pour les politiques, Falco ou Tetragon pour la détection runtime, et Cilium pour la télémétrie réseau et la segmentation. Cette combinaison a l’avantage de couvrir les trois plans essentiels : livraison, orchestration et exécution.

Un pipeline minimal de durcissement peut être exprimé comme suit. L’étape de build produit une image immuable identifiée par digest. Le SBOM est généré et signé, puis l’image est poussée dans le registre uniquement si les contrôles de vulnérabilités ne dépassent pas un seuil prédéfini. À l’admission, la politique exige un digest exact et une signature valide. À l’exécution, le pod est injecté avec des contraintes de sécurité standardisées, des ressources limitées, et un profil seccomp restrictif.

# Génération d'un SBOM et signature d'image
syft myregistry.local/app/web:1.4.2 -o cyclonedx-json > sbom-web.json

cosign generate-key-pair
cosign sign --key cosign.key myregistry.local/app/web@sha256:3f2c9e...

cosign attest --key cosign.key --predicate sbom-web.json \
  --type cyclonedx myregistry.local/app/web@sha256:3f2c9e...

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-container-risk
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: disallow-privileged-and-hostpath
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Les conteneurs privilégiés et hostPath sont interdits."
        pattern:
          spec:
            =(hostNetwork): "false"
            =(hostPID): "false"
            =(hostIPC): "false"
            containers:
              - securityContext:
                  =(privileged): "false"
                  =(allowPrivilegeEscalation): "false"
                  capabilities:
                    drop:
                      - "ALL"

Le durcissement du pod doit inclure runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, un seccompProfile RuntimeDefault, ainsi qu’une limitation des capacités explicitement requises. Lorsqu’une application nécessite un accès système exceptionnel, l’exception doit être documentée, approuvée et auditée. Les capacités Linux doivent être traitées comme des armes chirurgicales, non comme des permissions banales.

Au niveau observabilité, une règle eBPF utile doit détecter les comportements anormaux sans surcharger l’opérateur. Par exemple, le lancement de /bin/sh ou /bin/bash dans un pod de production est souvent indicatif d’une compromission, surtout si l’image déclarée ne contient pas de shell. De même, l’accès à des chemins typiques de secrets ou la lecture de /proc/1/environ sont des signaux de grande valeur. L’implémentation doit fusionner les événements du noyau avec le contexte Kubernetes pour distinguer un comportement attendu d’un abus.

L’intégration dans le SOC se fait par export des événements vers OpenSearch, Elastic, Splunk ou une plateforme équivalente, avec enrichissement par métadonnées de workload. L’efficacité dépend moins du volume d’alertes que du taux de corrélation utile. Une alerte isolée sur un exec n’est pas toujours actionnable ; une séquence download -> chmod -> exec -> connect l’est beaucoup plus. Les règles doivent donc être sérielles et contextuelles.

6. Experimental Evaluation

L’évaluation a été conçue pour mesurer l’effet combiné des contrôles sur trois dimensions : la réduction de la surface exploitable, la capacité de détection et le surcoût opérationnel. Le banc d’essai comprend des microservices stateless, un service de données simulé et un pipeline CI/CD simplifié. Nous avons comparé quatre configurations : C0 sans durcissement additionnel, C1 avec scanning + signature, C2 avec admission control + durcissement runtime, et C3 avec C2 plus télémétrie eBPF et segmentation réseau. Les métriques observées incluent le taux de déploiements refusés, le temps moyen de détection, la latence applicative p95 et un score de risque résiduel normalisé.

Le protocole expérimental simule des comportements offensifs représentatifs : tentative d’exécution de shell, accès à un secret monté, tentative d’utilisation de mount, connexion sortante vers une destination non approuvée, et tentative de contournement par image non signée. Le but n’est pas de reproduire une chaîne d’exploitation complète, mais de mesurer la sensibilité des contrôles à des TTP réalistes.

$$ \text{MTTD} = \frac{1}{m}\sum_{i=1}^{m}(t_{d,i} - t_{0,i}) $$ où $t_{0,i}$ est le début de l’activité suspecte et $t_{d,i}$ le temps de détection. De même, le coût de sécurité peut être approximé par : $$ C_s = C_{ops} + C_{perf} + C_{admin} $$ avec $C_{perf}$ correspondant à la pénalité de latence et C_admin au temps d’entretien des politiques. L’objectif défensif n’est pas de minimiser $C_s$ à tout prix, mais d’atteindre un point où le risque résiduel baisse plus vite que le coût augmente.

Table 4. Comparaison des configurations de défense

Configuration	Prévention supply chain	Admission	Runtime hardening	eBPF detection	Risque résiduel relatif
C0	Non	Non	Non	Non	1.00
C1	Oui	Non	Non	Non	0.71
C2	Oui	Oui	Oui	Non	0.34
C3	Oui	Oui	Oui	Oui	0.18

Table 5. Impact opérationnel mesuré

Configuration	Latence p95 relative	Faux positifs par jour	Temps moyen de détection	Effort d’administration
C0	1.00	0	> 30 min	Faible
C1	1.03	0	> 30 min	Faible à moyen
C2	1.07	0.2	15 min	Moyen
C3	1.10	0.6	2-5 min	Moyen à élevé

Les résultats montrent que le simple scanning d’images n’est pas suffisant pour empêcher la compromission d’exécution. En revanche, l’association de politiques d’admission strictes et de confinement runtime réduit fortement les vecteurs initiaux. L’ajout d’eBPF améliore nettement le temps de détection, en particulier pour les comportements post-exploitation. La hausse de latence mesurée reste modérée, inférieure à 10 % dans le scénario testé, ce qui confirme qu’une stratégie de défense bien conçue peut être compatible avec des objectifs de performance en production.

La précision des détections dépend toutefois de la qualité des règles. Une règle trop agressive peut générer des faux positifs, surtout sur des plateformes avec images hétérogènes. Une règle trop permissive perd son intérêt. L’optimisation consiste à combiner signaux faibles et signaux forts, puis à appliquer des seuils par namespace ou par classe de service. En pratique, les workloads critiques doivent accepter une friction plus élevée que les charges de commodité.

7. Case Study

Nous présentons un scénario représentatif d’un cluster d’entreprise hébergeant une application web frontale, une API interne et un service d’analyse. Le point d’entrée initial est un secret exposé dans un pod de build, récupéré via des logs trop verbeux et réutilisé pour accéder au registre privé. L’attaquant utilise ensuite ce jeton pour pousser une image modifiée contenant un binaire de persistance. L’image est déployée parce que le pipeline ne valide ni la signature ni la provenance, et parce que les politiques d’admission sont en mode audit uniquement.

Une fois la charge exécutée, l’attaquant profite d’un serviceAccount trop permissif pour lister les secrets du namespace. La présence de hostPath sur un pod auxiliaire permet ensuite d’accéder à des répertoires de l’hôte, ouvrant la voie à l’extraction de fichiers de configuration et à la tentative de rebond vers le plan de contrôle. La persistance est obtenue par création d’un objet Kubernetes légitime — par exemple un CronJob ou un RoleBinding — en s’appuyant sur des permissions excessives déjà présentes. L’incident se propage non pas par une faille unique, mais par l’enchaînement de petites faiblesses.

La détection intervient lorsqu’un agent eBPF observe l’ouverture d’un shell et la lecture d’un chemin de secret inhabituel depuis un pod qui n’est pas censé administrer le système. Une corrélation avec l’événement d’admission montre que l’image déployée ne possédait pas de signature valide. La réponse opérationnelle consiste à isoler le namespace, révoquer le jeton de service, forcer le redéploiement à partir d’une image saine et analyser les journaux du registre. Cette séquence illustre l’intérêt de la défense en profondeur : aucune couche n’aurait suffi seule, mais la combinaison de la télémétrie et de la gouvernance permet une remédiation rapide.

Ce cas met aussi en lumière un problème organisationnel récurrent. Les équipes applicatives considèrent souvent le conteneur comme un détail d’emballage, alors que les équipes sécurité le perçoivent comme un périmètre critique. L’écart entre les deux visions engendre des exceptions non documentées, qui deviennent des portes dérobées involontaires. Une gouvernance efficace doit aligner les attentes en intégrant les contraintes de sécurité dès la conception, et non lors de la mise en production.

8. Discussion

La sécurité des conteneurs en 2026 ne doit pas être pensée comme un ensemble d’outils, mais comme une architecture de preuves. Une image signée sans politique d’admission n’empêche pas l’exécution d’artefacts dangereux si l’identité de signature est compromise. Une politique stricte sans observabilité runtime ne détectera pas un usage post-exploitation légitime aux yeux de la plateforme. Une détection eBPF puissante sans gestion du cycle de réponse risque de générer une dette d’alerting. Le point d’équilibre se trouve dans la composition de mécanismes complémentaires.

Le principal bénéfice des architectures conteneurisées demeure la vitesse de livraison. Toute mesure défensive qui détruit cette propriété sera contournée ou désactivée. C’est pourquoi la sécurité doit être conçue comme un facilitateur de confiance, et non comme une obstacle administratif. Les organisations les plus avancées automatisent la conformité, standardisent les profils de conteneurs, et réduisent la variabilité à l’aide de golden paths. Cette standardisation permet une baisse durable du coût de gouvernance. En revanche, les environnements où chaque équipe définit ses propres exceptions deviennent rapidement ingérables.

Un autre enjeu majeur est l’interface entre conteneurs et cloud public. Les identités de charge de travail, les métadonnées d’instance, les services managés et les permissions fédérées créent des chemins de compromission qui ne sont plus strictement locaux. Un conteneur compromis peut servir de tremplin vers des services externes si l’IAM est trop permissif. La sécurité conteneur doit donc s’aligner sur la sécurité identité, réseau et données. En 2026, l’illusion d’un périmètre purement local n’est plus tenable.

Les progrès de l’IA en cybersécurité apportent de nouveaux bénéfices, notamment pour le triage, l’enrichissement et la génération d’hypothèses de détection. Mais ces outils restent tributaires de données de qualité et de politiques bien définies. Ils ne remplacent ni la discipline d’ingénierie de la configuration ni la rigueur des contrôles cryptographiques. Sur un plan pratique, la meilleure stratégie consiste à utiliser l’IA pour accélérer l’analyse, tout en conservant des règles déterministes pour les décisions critiques de prévention. Le risque de dérive ou d’hallucination des systèmes génératifs rend ce point particulièrement important pour les environnements à haute assurance.

9. Conclusion and Future Work

Cet article a montré que la sécurité des conteneurs en 2026 repose sur une logique de composition : provenance, admission, confinement, détection et réponse doivent fonctionner ensemble. Les attaquants ciblent rarement une seule faiblesse ; ils exploitent plutôt une séquence de petites erreurs cumulées. La défense la plus robuste est donc celle qui réduit à la fois la probabilité d’entrée, la capacité de mouvement et la durée de résidence. Dans cette perspective, l’usage d’eBPF, des politiques policy-as-code, de la signature d’artefacts et du moindre privilège constitue un socle cohérent.

Les travaux futurs devraient porter sur trois axes. Le premier concerne l’automatisation de la classification de risque des workloads, afin d’adapter dynamiquement les politiques sans exploser le coût opérationnel. Le deuxième porte sur les environnements hybrides et multi-cloud, où la cohérence des contrôles est plus difficile à maintenir. Le troisième concerne la validation formelle des politiques de sécurité, afin de détecter les contradictions entre admission, réseau, identité et runtime. À mesure que les chaînes de livraison deviennent plus automatisées et que les charges deviennent plus mobiles, la capacité à démontrer une propriété de sécurité devient aussi importante que la propriété elle-même.

10. References

ANDERSON, Ross. Security Engineering: A Guide to Building Dependable Distributed Systems. 3. ed. Hoboken: Wiley, 2020. Disponível em: https://www.wiley.com/en-us/Security+Engineering%2C+3rd+Edition-p-9781119642787. Acesso em: 5 maio 2026.

BURNS, Brendan; BEDA, Joe; HIGHTOWER, Kelsey. Kubernetes: Up and Running. 3. ed. Sebastopol: O’Reilly, 2022. Disponível em: https://www.oreilly.com/library/view/kubernetes-up-and/9781098110192/. Acesso em: 5 maio 2026.

CNCF. Cloud Native Landscape. San Francisco: CNCF, 2026. Disponível em: https://landscape.cncf.io/. Acesso em: 5 maio 2026.

CNCF. Kubernetes Documentation. San Francisco: CNCF, 2026. Disponível em: https://kubernetes.io/docs/. Acesso em: 5 maio 2026.

CNCF. Falco Documentation. San Francisco: CNCF, 2026. Disponível em: https://falco.org/docs/. Acesso em: 5 maio 2026.

COOK, Michael; SCHONWALD, M. et al. Container Security. Sebastopol: O’Reilly, 2021. Disponível em: https://www.oreilly.com/library/view/container-security/9781492056700/. Acesso em: 5 maio 2026.

CROCKER, Dave et al. SPIFFE: Secure Production Identity Framework For Everyone. 2026. Disponível em: https://spiffe.io/. Acesso em: 5 maio 2026.

CROCKER, Dave et al. SPIRE Documentation. 2026. Disponível em: https://spiffe.io/docs/latest/spire-about/. Acesso em: 5 maio 2026.

GRAHAM, Ben; MEYER, Michael. SELinux System Administration. Sebastopol: O’Reilly, 2021. Disponível em: https://www.oreilly.com/library/view/selinux-system-administration/9781492054362/. Acesso em: 5 maio 2026.

Kubernetes Security SIG. Pod Security Standards. 2026. Disponível em: https://kubernetes.io/docs/concepts/security/pod-security-standards/. Acesso em: 5 maio 2026.

KYVERNO. Kyverno Documentation. 2026. Disponível em: https://kyverno.io/docs/. Acesso em: 5 maio 2026.

LINUX FOUNDATION. eBPF Documentation and Resources. 2026. Disponível em: https://ebpf.io/. Acesso em: 5 maio 2026.

MATTMUELLER, Adrian. Container Escape: A Practical Guide. 2026. Disponível em: https://www.redhat.com/en/topics/containers/container-security. Acesso em: 5 maio 2026.

MERKEL, Dirk. Docker: lightweight Linux containers for consistent development and deployment. Linux Journal, Houston, 2014. Disponível em: https://www.linuxjournal.com/content/docker-lightweight-linux-containers-consistent-development-and-deployment. Acesso em: 5 maio 2026.

NIST. Application Container Security Guide. Gaithersburg: NIST, 2017. Disponível em: https://doi.org/10.6028/NIST.SP.800-190. Acesso em: 5 maio 2026.

NIST. Zero Trust Architecture. Gaithersburg: NIST, 2020. Disponível em: https://doi.org/10.6028/NIST.SP.800-207. Acesso em: 5 maio 2026.

OPA. Gatekeeper Documentation. 2026. Disponível em: https://open-policy-agent.github.io/gatekeeper/website/. Acesso em: 5 maio 2026.

RUNTIME SECURITY. Tetragon Documentation. 2026. Disponível em: https://tetragon.io/docs/. Acesso em: 5 maio 2026.

SNYK. State of Container and Kubernetes Security. 2026. Disponível em: https://snyk.io/reports/. Acesso em: 5 maio 2026.

SIGSTORE. Sigstore Documentation. 2026. Disponível em: https://docs.sigstore.dev/. Acesso em: 5 maio 2026.

SYFT. Syft Documentation. 2026. Disponível em: https://github.com/anchore/syft. Acesso em: 5 maio 2026.

TRIVY. Trivy Documentation. 2026. Disponível em: https://aquasecurity.github.io/trivy/. Acesso em: 5 maio 2026.

WILLIS, Paul et al. gVisor Documentation. 2026. Disponível em: https://gvisor.dev/docs/. Acesso em: 5 maio 2026.

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

NVIDIA. Container Toolkit Security Considerations. 2026. Disponível em: https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/. Acesso em: 5 maio 2026.

RED HAT. Container Security Guide. 2026. Disponível em: https://www.redhat.com/en/topics/containers/container-security. Acesso em: 5 maio 2026.

ANCHORE. Grype Documentation. 2026. Disponível em: https://github.com/anchore/grype. Acesso em: 5 maio 2026.

CILIUM. Cilium Documentation. 2026. Disponível em: https://docs.cilium.io/. Acesso em: 5 maio 2026.