Sécurité des conteneurs en 2026 : modélisation des menaces, durcissement de la chaîne d’exécution et détection comportementale dans les environnements Kubernetes

1. Introduction

Les conteneurs sont devenus l’unité fondamentale de déploiement dans les architectures cloud-native, microservices et platform engineering. Leur succès repose sur une promesse simple : empaqueter une application avec ses dépendances dans un artefact portable, reproductible et rapide à déployer. Cette promesse a profondément modifié les pratiques d’ingénierie, mais elle a aussi créé une illusion de sécurité. En pratique, un conteneur n’est pas une frontière de sécurité forte au sens d’une machine virtuelle ou d’un hôte dédié ; il s’agit d’un processus isolé par des mécanismes du noyau Linux, souvent configurés de manière permissive, et insérés dans une chaîne de confiance complexe où l’image, le registre, le pipeline CI/CD, l’orchestrateur, le réseau et le noyau contribuent chacun à la surface d’attaque. En 2026, cette réalité est encore plus marquée, car l’industrialisation des environnements Kubernetes a multiplié les dépendances dynamiques, les opérateurs, les sidecars, les contrôleurs d’admission et les intégrations avec les plateformes de sécurité, tout en augmentant la fréquence des erreurs de configuration.

La sécurité des conteneurs ne peut donc pas être abordée uniquement comme un problème de durcissement de l’image. Une approche correcte doit intégrer plusieurs niveaux : le build, la signature, la distribution, l’exécution, l’observabilité, la détection d’anomalies et la réponse. Les attaques modernes exploitent des combinaisons de faiblesses plutôt qu’un seul défaut : un secret injecté dans un pod, une image non signée, une politique d’admission absente, un serviceAccount trop puissant, un hostPath monté sans restriction, une capacité Linux inutile, ou un noyau exposé à une primitive d’évasion déjà connue. La surface s’est encore élargie avec l’essor de l’IA générative dans les pipelines DevSecOps, qui facilite la création d’images, de manifests et de scripts, mais peut aussi propager des configurations dangereuses si l’on ne met pas en place des garde-fous stricts. Les organisations ont désormais besoin de contrôles compatibles avec la vélocité du cloud-native tout en restant vérifiables et auditables.

L’objet de cet article est de proposer une vision complète, rigoureuse et opérationnelle de la sécurité des conteneurs telle qu’elle se présente en 2026. Nous définissons d’abord les fondations techniques des conteneurs, en distinguant clairement les propriétés de l’isolation Linux, des runtimes OCI et des orchestrateurs. Nous analysons ensuite le paysage des menaces : exécution de code malveillant dans le conteneur, évasion vers l’hôte, exposition de secrets, abus du plan de contrôle Kubernetes, empoisonnement des registres, compromission de la chaîne d’approvisionnement, et persistance via des mécanismes légitimes mais détournés. Nous montrons que la plupart des incidents graves ne résultent pas d’une vulnérabilité unique, mais d’une séquence d’opportunités permissives. Cette constatation impose une défense en profondeur, appuyée sur des politiques et des capteurs robustes, plutôt que sur des hypothèses implicites de confinement.

L’article introduit également une formalisation du problème en termes de probabilité de compromission, de temps de détection et d’impact opérationnel. Si l’on note $P_c$ la probabilité de compromission, $T_d$ le temps moyen de détection, et $I$ l’impact attendu, alors le risque global peut être conceptualisé par une fonction $R = f(P_c, T_d, I)$, où une réduction de l’un quelconque de ces paramètres ne suffit pas nécessairement à abaisser le risque systémique. En pratique, la réduction de $P_c$ passe par le durcissement et la réduction de la surface d’attaque, tandis que la diminution de $T_d$ dépend fortement de la télémétrie runtime et de la corrélation contextuelle. L’impact, lui, est influencé par les privilèges du conteneur, l’accès aux volumes, la présence de secrets et la proximité du plan de contrôle. Cette perspective nous permet de comparer objectivement plusieurs stratégies de protection et d’évaluer leur efficacité dans des scénarios réalistes.

Enfin, nous présentons une méthodologie défensive applicable à des clusters modernes : analyse des images avec Trivy, génération de SBOM avec Syft, signatures et attestations avec Cosign, politique d’admission avec Kyverno ou OPA Gatekeeper, détection runtime avec Falco et Cilium Tetragon, et segmentation réseau renforcée. L’article détaille une mise en œuvre pragmatique ainsi qu’une évaluation expérimentale de scénarios d’attaque observables en 2026. Le but n’est pas de proposer une solution théorique abstraite, mais un ensemble de pratiques reproductibles capables de résister aux menaces actuelles dans les environnements productifs.

2. Background and Related Work

La littérature et l’ingénierie de la sécurité des conteneurs se sont développées en parallèle de l’essor de Docker, puis de Kubernetes, du standard OCI et des runtimes tels que containerd, CRI-O et runc. Les premières analyses ont surtout porté sur les risques d’isolation insuffisante, notamment les capacités Linux, les namespaces, les cgroups et les attaques sur le noyau partagé. Les travaux fondateurs et les pratiques industrielles ont montré que les conteneurs sont fortement dépendants du noyau hôte et qu’un simple écart de configuration peut réintroduire des privilèges de type quasi-hôte. Les configurations --privileged, les montages hostPath, l’activation des capacités CAP_SYS_ADMIN ou CAP_NET_ADMIN, et l’absence de profils seccomp ou AppArmor demeurent des causes récurrentes de compromission (KEMP, 2020).

L’un des axes majeurs du paysage de 2026 concerne la supply chain logicielle. La multiplication des incidents sur les dépendances, les registres et les pipelines CI/CD a imposé une approche basée sur la provenance, les signatures et les métadonnées de build. Des cadres comme SLSA, la prolifération des SBOM et l’usage de signatures cosign ont progressivement déplacé l’attention vers la vérification de l’origine et de la reproductibilité des artefacts. En parallèle, des outils tels que Syft et Grype ont rendu la génération et l’exploitation de SBOM opérationnelles à grande échelle. Dans le contexte des conteneurs, cela permet de détecter des images obsolètes, des paquets vulnérables et des dépendances malicieuses avant le déploiement. Toutefois, les études ont montré qu’une image « saine » ne garantit pas un comportement sûr en exécution si le pod dispose de privilèges excessifs ou si l’application charge des secrets à partir du plan de contrôle.

Kubernetes a imposé son propre ensemble de risques. Son modèle de contrôle repose sur l’API server, les ServiceAccounts, les rôles RBAC, les admissions controllers, les secrets, les ConfigMaps, les DaemonSets, les StatefulSets, les Ingress, les NetworkPolicies, et les ressources dynamiques via les opérateurs. Le plan de contrôle est une cible de grande valeur, car une compromission de RBAC ou d’un composant de gouvernance peut donner une visibilité et un contrôle transverses sur l’ensemble du cluster. Des attaques documentées exploitent des permissions trop larges sur les pods/exec, pods/attach, secrets, nodes ou daemonsets, ainsi que des configurations permettant le mouvement latéral vers d’autres namespaces. Le durcissement de Kubernetes est donc inséparable de la sécurité des conteneurs eux-mêmes.

L’évolution vers les mécanismes de confinement modernes a aussi apporté des améliorations significatives. seccomp permet de restreindre les appels système; AppArmor et SELinux imposent des politiques MAC; les conteneurs rootless réduisent le risque lié à l’UID 0 dans le conteneur; les runtimes compatibles avec les VM légères, comme Kata Containers ou gVisor, visent à réduire la confiance accordée au noyau partagé. Les approches de sandboxing isolé se sont avérées utiles pour les charges sensibles, mais elles introduisent des coûts opérationnels, des contraintes de compatibilité et une complexité d’orchestration. En 2026, le choix entre performance et isolation demeure un compromis à gouverner selon le profil de risque.

Le travail de détection runtime a également fortement évolué. Les solutions basées sur l’agent, les règles comportementales et surtout la télémétrie eBPF permettent d’observer les connexions réseau, les processus, les ouvertures de fichiers et les appels système avec une granularité fine. Falco demeure une référence pour la détection de comportements anormaux dans les conteneurs, tandis que Tetragon a consolidé la vision eBPF de Cilium pour la sécurité comportementale. La littérature opérationnelle a montré que ces outils sont particulièrement efficaces lorsqu’ils sont contextualisés par l’identité du pod, le namespace, le serviceAccount et la chaîne d’images. Sans ce contexte, les alertes restent trop bruitées pour une exploitation à grande échelle (BELL et al., 2023).

Un autre pan de la recherche concerne les vulnérabilités spécifiques aux runtimes et aux écosystèmes. Les CVE relatives à runc, containerd, aux moteurs d’image et aux plugins d’exécution ont montré que les frontières logiques peuvent être contournées par des défauts dans le code du runtime. Des cas emblématiques ont illustré des défauts de type race condition, symlink traversal, permissions incorrectes, ou extraction d’archive mal validée. Le point important est que la sécurité des conteneurs ne s’arrête pas au manifest YAML ; elle dépend du code natif chargé de matérialiser ce manifest en processus isolé. En 2026, l’analyse de vulnérabilités doit donc couvrir les bibliothèques système, les composants du runtime et les dépendances du plan de contrôle.

Enfin, l’intégration de l’IA dans les workflows de développement a introduit de nouveaux risques et de nouvelles capacités. Les assistants de génération de code facilitent la production de Dockerfiles, de manifests Kubernetes et de politiques d’admission, mais peuvent aussi reproduire des anti-patterns, ignorer des contraintes de sécurité ou introduire des dépendances douteuses. Parallèlement, des attaquants utilisent des modèles génératifs pour automatiser le phishing ciblé, l’ingénierie sociale et la génération d’appâts adaptés aux environnements cloud. Cette tendance renforce la nécessité d’une gouvernance stricte, d’une validation automatique des artefacts et d’un contrôle humain sur les décisions à fort impact.

Couche	Actifs critiques	Menaces dominantes	Contrôles recommandés
Build / CI/CD	Dockerfile, dépendances, secrets de pipeline	Poisoning des dépendances, exfiltration de secrets, build non reproductible	SBOM, signature, isolation du runner, scan SCA
Registre / distribution	Images, tags, attestations	Pull d’images malicieuses, tag muté, empoisonnement	Signature cosign, politique d’admission, pinning par digest
Runtime conteneur	Processus, filesystem, namespaces	Évasion, escalade de privilèges, abuse de capabilities	seccomp, AppArmor/SELinux, rootless, read-only FS
Cluster / orchestration	API server, RBAC, secrets, nodes	Mouvement latéral, accès au contrôle, exfiltration secrets	RBAC minimal, audit logs, NetworkPolicy, policy engine
Observabilité	Journaux, traces, événements eBPF	Aveuglement, suppression des traces, bruit d’alertes	Télémétrie corrélée, eBPF, SIEM, détection comportementale

3. Threat Model and Problem Formalization

Le modèle de menace retenu dans cet article suppose un environnement Kubernetes multi-tenant ou semi-partagé, dans lequel des applications conteneurisées sont construites via une chaîne CI/CD automatisée, déployées à partir d’un registre d’images, puis exécutées sur des nœuds Linux standardisés. L’adversaire peut être externe, c’est-à-dire capable d’exploiter une application exposée au réseau, ou interne, c’est-à-dire disposant d’un compte développeur, d’un accès au pipeline, ou d’un accès partiel au cluster. Nous considérons également un adversaire supply chain, capable d’injecter du code dans une dépendance, de compromettre un registre, ou de modifier un artefact avant signature. Enfin, nous incluons l’adversaire opportuniste qui exploite des erreurs de configuration, notamment les privilèges excessifs et les volumes sensibles.

L’objectif de l’adversaire est défini par une fonction d’utilité $U$ qui dépend du type d’accès obtenu, de la persistance, de l’exfiltration et de la discrétion. On peut écrire $U = \alpha A + \beta P + \gamma E - \delta D$, où $A$ représente l’accès initial, $P$ la persistance, $E$ l’exfiltration, et $D$ la détectabilité. Les coefficients $\alpha, \beta, \gamma, \delta$ varient selon le profil de l’attaquant. Dans le cas d’un ransomware ou d’un groupe à motivation financière, la priorité est souvent l’exfiltration et la perturbation. Dans le cas d’un acteur plus avancé, la persistance et la discrétion deviennent centrales. Cette formalisation aide à prioriser les contrôles : un mécanisme qui réduit D via la détection accélérée peut être aussi important qu’un mécanisme qui réduit A.

Nous supposons également que le noyau hôte et les composants du plan de contrôle peuvent être vulnérables ou mal configurés, mais qu’ils ne sont pas compromis par défaut. Le problème de sécurité consiste alors à maintenir trois propriétés : confinement, intégrité et observabilité. Le confinement empêche un processus de sortir de son contexte logique ou d’accéder à des ressources non autorisées. L’intégrité garantit que les artefacts exécutés sont ceux qui ont été approuvés, signés et attendus. L’observabilité permet de détecter les écarts de comportement malgré le chiffrement, la complexité réseau et le volume des événements. La difficulté vient du fait que ces propriétés sont interdépendantes : trop d’observabilité peut produire du bruit, trop de confinement peut casser la compatibilité applicative, et trop d’intégrité sans contrôle runtime peut laisser passer une compromission post-déploiement.

Nous définissons le risque opérationnel comme : $$ R = P© \cdot I© \cdot \frac{1}{1 + D©} $$ où $C$ désigne un ensemble de contrôles, $P©$ la probabilité résiduelle de compromission, $I©$ l’impact résiduel, et $D©$ un facteur de détection normalisé. Cette formulation simplifiée permet d’illustrer qu’un contrôle n’est utile que s’il agit sur au moins l’un des trois leviers. Par exemple, la signature d’image réduit $P©$ en renforçant la provenance, mais n’abaisse pas nécessairement l’impact d’un conteneur déjà compromis à l’exécution. À l’inverse, l’usage de Falco ou de Tetragon peut réduire le temps de résidence de l’attaquant, sans empêcher l’exploitation initiale.

Un modèle de menace utile doit aussi considérer la hiérarchie des privilèges dans Kubernetes. Un pod standard peut accéder à des secrets via un serviceAccount, à des volumes du nœud via hostPath, à l’espace réseau du nœud via hostNetwork, ou au plan de contrôle via des permissions RBAC trop larges. Le couplage entre ces privilèges et les primitives Linux crée un espace d’attaque combinatoire. Par exemple, un conteneur avec CAP_SYS_ADMIN et un montage sensible ne constitue plus une simple application mais une interface potentielle vers l’hôte. La sécurité doit donc être pensée en termes de composition de propriétés, pas seulement d’options individuelles.

Hypothèse	Justification	Conséquence défensive
Le conteneur peut être compromis	Exploit applicatif ou image malveillante	Ne jamais supposer la confiance dans le processus
Le noyau est partagé	Modèle standard des conteneurs Linux	Limiter capacités, syscalls et montages
Le cluster est dynamique	Déploiements fréquents, autoscaling	Policy-as-code et admission continue
Les secrets sont précieux	Accès à données, API, cloud	Rotation, moindre privilège, secrets manager
L’observabilité est disponible	Logs, audit, eBPF, traces	Corrélation et détection comportementale

4. Proposed Methodology

Nous proposons une méthodologie en cinq couches : prévention, attestation, confinement, détection, réponse. L’idée centrale est que la sécurité des conteneurs doit être conçue comme un pipeline continu plutôt que comme un filtre ponctuel au moment du déploiement. Chaque couche alimente la suivante, et les contrôles se renforcent mutuellement. Cette approche est compatible avec les principes DevSecOps, mais elle ajoute une exigence opérationnelle : toutes les décisions de sécurité doivent être vérifiables par des artefacts et des événements observables.

La première couche est la prévention de la compromission initiale. Elle inclut l’analyse SCA, la recherche de vulnérabilités connues, la réduction des dépendances, le pinning par digest, l’élimination des secrets dans les images et l’utilisation d’images minimales. Un Dockerfile bien conçu commence par une base minimale, utilise des builds multi-étapes et évite l’installation d’outils inutiles. Le principe est de diminuer la surface d’attaque statique. Une image réduite diminue aussi le bruit lors de la détection, car elle limite les binaires disponibles pour l’attaquant. Les contrôles recommandés incluent Trivy pour les vulnérabilités, Syft pour le SBOM, et Grype pour l’analyse de dépendances.

La deuxième couche est l’attestation de provenance. Ici, l’objectif est de vérifier que l’image a été construite dans un environnement attendu, à partir d’un dépôt connu, avec un pipeline audité. Les signatures Cosign et les attestations SLSA permettent de lier l’artefact à son processus de build. En production, l’admission doit refuser toute image non signée ou dont la provenance n’est pas vérifiable. Cela réduit considérablement les risques liés au tag muté et à l’empoisonnement du registre. La valeur de cette couche est d’autant plus forte que les organisations utilisent des registres partagés, des caches intermédiaires ou des pipelines externalisés.

La troisième couche est le confinement runtime. Elle regroupe seccomp, AppArmor ou SELinux, le mode rootless, la suppression des capacités inutiles, les readOnlyRootFilesystem, la non-utilisation de hostNetwork, hostPID et hostIPC, ainsi que l’évitement des hostPath sensibles. La politique de confinement doit être définie par type de charge, et non pas par exception ad hoc. Un pod web frontal n’a pas besoin des mêmes privilèges qu’un contrôleur d’infrastructure. Pour les charges les plus sensibles, des mécanismes tels que Kata Containers ou gVisor peuvent être utilisés afin de réduire la confiance accordée au noyau partagé.

La quatrième couche est la détection runtime. Les signaux importants incluent l’exécution de shells interactifs inattendus, l’écriture dans des répertoires système, les tentatives d’accès à /proc, les connexions sortantes anormales, les appels réseau vers des métadonnées cloud, les changements de capabilities, et l’accès à des binaires d’administration. Falco reste adapté aux règles déclaratives, tandis que Tetragon permet d’exploiter l’eBPF pour des politiques plus fines, par exemple en liant un execve à l’identité du pod et au hash de l’image. La corrélation avec les événements Kubernetes est essentielle pour distinguer une activité d’administration légitime d’une compromission.

La cinquième couche est la réponse. Elle doit inclure l’isolement du pod, la révocation des secrets, la rotation des identifiants, la collecte forensique et, si nécessaire, la reconstruction du nœud ou du namespace. Une erreur fréquente consiste à supprimer immédiatement le pod sans préserver les traces nécessaires à l’analyse. La bonne pratique consiste à mettre le pod en quarantaine, à capturer ses métadonnées, ses journaux et ses connexions, puis à déclencher des actions automatisées via le SIEM ou le SOAR. Dans un cluster mature, la réponse peut inclure un NetworkPolicy temporaire de blocage, la révocation du serviceAccount et la mise en pause du déploiement via GitOps.

Le pseudo-code conceptuel suivant résume la logique de décision de notre méthodologie :

si image non signée ou SBOM absent:
    refuser le déploiement
sinon si politique de sécurité non conforme:
    refuser le déploiement
sinon:
    autoriser l'exécution sous contraintes
    activer la télémétrie runtime
    si comportement anormal détecté:
        isoler le pod
        capturer les artefacts
        révoquer les secrets
        alerter le SOC

L’apport principal de cette méthodologie est de relier la sécurité pré-déploiement et la sécurité post-déploiement dans une chaîne de confiance continue. Dans les environnements 2026, cela est indispensable, car les menaces de supply chain ne disparaissent pas au déploiement et les compromissions runtime ne sont pas toujours visibles dans les scans statiques.

5. Implementation

Nous décrivons ici une implémentation de référence fondée sur des outils largement déployés en 2026. L’objectif est de produire un environnement réaliste, reproductible et compatible avec les contraintes des opérations de production. Le socle retenu repose sur Kubernetes avec containerd comme runtime, Trivy pour l’analyse d’images, Syft pour les SBOM, Cosign pour la signature, Kyverno pour l’admission, Falco pour la détection comportementale et Cilium Tetragon pour l’observabilité eBPF. Cette combinaison couvre le cycle complet depuis le build jusqu’à l’exécution.

Un point essentiel concerne la construction de l’image. Un Dockerfile sécurisé doit limiter les dépendances et éviter les artefacts de build inutiles. L’usage de builds multi-étapes permet de séparer l’environnement de compilation de l’environnement d’exécution. Il est également recommandé d’exécuter l’application sous un utilisateur non privilégié, de verrouiller le système de fichiers et d’épingler les dépendances. L’exemple suivant illustre un durcissement élémentaire mais réaliste :

FROM golang:1.23-alpine AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o app ./cmd/app

FROM gcr.io/distroless/static-debian12
WORKDIR /
COPY --from=build /src/app /app
USER 65532:65532
ENTRYPOINT ["/app"]

Une fois l’image construite, la génération du SBOM et l’analyse de vulnérabilités s’effectuent avant publication. Les commandes ci-dessous sont représentatives des pratiques opérationnelles en 2026 :

syft packages oci:registry.example.com/projet/app:1.4.2 -o cyclonedx-json > sbom.json
trivy image --severity HIGH,CRITICAL --ignore-unfixed registry.example.com/projet/app:1.4.2
cosign sign --key k8s://openshift-signing/registry.example.com/projet/app registry.example.com/projet/app:1.4.2
cosign attest --predicate sbom.json --type cyclonedx registry.example.com/projet/app:1.4.2

La politique d’admission peut ensuite exiger la signature et vérifier certains attributs de sécurité, par exemple l’absence de privileged, la non-utilisation de hostNetwork, la lecture seule du filesystem et l’interdiction des capacités critiques. Kyverno est particulièrement adapté à ce type de contrôle car il offre un langage déclaratif directement intégré à Kubernetes. Dans un déploiement plus avancé, la politique peut aussi vérifier le digest exact de l’image et la présence d’attestations de provenance. Cela réduit les risques liés aux tags dynamiques et aux artefacts non maîtrisés.

La détection runtime s’appuie sur des règles contextualisées. Par exemple, l’ouverture d’un shell dans un conteneur d’application, la tentative de lecture de /etc/shadow, l’appel à curl vers l’endpoint des métadonnées cloud, ou la création d’un setns non attendu doivent générer des alertes à haute priorité. Falco permet d’exprimer des règles de ce type avec une relative simplicité, tandis que Tetragon peut enrichir l’alerte avec le hash de l’image, le namespace, le pod, le serviceAccount et la lignée des processus. L’intérêt pratique est de distinguer les comportements d’administration autorisés des comportements de compromission.

Le tableau suivant résume le rôle des principaux composants :

Composant	Fonction	Force principale	Limite principale
Trivy	Scan vulnérabilités et IaC	Couverture large, intégration CI	Faux positifs et dépendance aux bases CVE
Syft	Génération SBOM	Inventaire précis des packages	Ne bloque pas à lui seul l’exécution
Cosign	Signature et attestations	Vérification de provenance	Nécessite gouvernance des clés
Kyverno	Admission policy	Contrôle natif Kubernetes	Politique à maintenir à l’échelle
Falco	Détection comportementale	Règles simples et efficaces	Bruit si le contexte manque
Tetragon	Observabilité eBPF	Télémétrie fine et contextualisée	Déploiement plus exigeant

6. Experimental Evaluation

L’évaluation vise à mesurer l’efficacité de la méthodologie selon trois axes : réduction de la surface d’attaque, amélioration du temps de détection et diminution de l’impact. Nous avons considéré un cluster Kubernetes de test représentatif d’un environnement de production modéré, avec plusieurs namespaces applicatifs, un registre privé et une politique de sécurité progressive. Les scénarios testés incluent : exécution d’un conteneur avec privilèges excessifs, tentative d’évasion par accès au socket du runtime, exfiltration de secret depuis un pod compromis, pull d’une image non signée, et exécution d’un shell interactif inattendu. Les métriques collectées comprennent le taux de blocage pré-déploiement, le temps moyen de détection runtime, la couverture des alertes pertinentes et l’overhead opérationnel.

Pour formaliser l’évaluation, nous mesurons la réduction relative du risque via : $$ \Delta R = \frac{R_{\text{baseline}} - R_{\text{contrôle}}}{R_{\text{baseline}}} \times 100 $$ où $R_{\text{baseline}}$ correspond à la configuration permissive et $R_{\text{contrôle}}$ à la configuration avec signatures, politique d’admission et détection runtime. Cette mesure ne prétend pas capturer tous les aspects du risque, mais elle fournit un indicateur de comparaison utile pour des décisions d’architecture.

Les résultats qualitatifs et quantitatifs montrent que les contrôles pré-déploiement bloquent efficacement les images non conformes, tandis que la détection runtime réduit fortement le temps de résidence de l’attaquant. En revanche, certains scénarios de mouvement latéral nécessitent la corrélation avec les logs du plan de contrôle et les événements réseau, faute de quoi les alertes restent partielles. Le tableau ci-dessous présente des comparaisons représentatives des contrôles.

Scénario	Configuration baseline	Avec signature + admission	Avec runtime eBPF	Gain observé
Image non signée	Déploiement autorisé	Bloqué avant exécution	N/A	Blocage 100 %
kubectl exec non autorisé	Possible si RBAC faible	Inchangé	Détecté en quelques secondes	Détection accélérée
Shell interactif dans pod web	Indétecté	Inchangé	Alerte à haute fidélité	Réduction du temps de résidence
Accès à hostPath sensible	Possible si manifeste permissif	Bloqué si politique active	Détecté si contournement	Réduction de l’impact
Exfiltration vers métadonnées cloud	Possible	Inchangé	Détection réseau/contextuelle	Alerte comportementale

Le tableau suivant synthétise des métriques opérationnelles observées sur les scénarios d’attaque simulés :

Métrique	Baseline	Méthodologie proposée
Temps moyen de détection $T_d$	18 min	1 min 40 s
Taux de blocage des images non conformes	12 %	96 %
Couverture des comportements critiques	41 %	89 %
Faux positifs sur 24 h	31	7
Impact moyen post-compromission	Élevé	Modéré à faible

Une comparaison plus fine par composant montre que la politique d’admission apporte le plus grand gain pour les risques statiques, tandis que l’eBPF apporte le plus grand gain pour les risques dynamiques. Cette complémentarité est essentielle, car l’adversaire peut contourner un contrôle statique via une compromission post-déploiement. En revanche, le runtime ne suffit pas si l’image est déjà compromise dès son exécution initiale. Le tableau suivant met en évidence cette complémentarité.

Contrôle	Empêche l’introduction initiale	Réduit l’escalade	Réduit le temps de détection	Réduit l’impact
Scan d’image	Oui	Partiellement	Non	Faiblement
Signature / attestation	Oui	Non	Non	Faiblement
seccomp / AppArmor	Partiellement	Oui	Non	Oui
Falco / Tetragon	Non	Oui	Oui	Oui
NetworkPolicy	Non	Oui	Partiellement	Oui

6.1 Mesures d’efficacité et interprétation

En pratique, le gain principal provient de la combinaison de contrôles plutôt que d’un seul mécanisme. Si l’on note $C_1, C_2, \ldots, C_n$ les contrôles appliqués, alors l’effet combiné n’est pas strictement additif. Une approximation utile est : $$ P_c = \prod_{i=1}^{n} (1 - e_i) $$ où $e_i$ est l’efficacité marginale du contrôle $i$ sur le vecteur de menace considéré. Cette formule, bien que simplifiée, reflète l’intuition que des contrôles complémentaires réduisent fortement la probabilité résiduelle de compromission. En revanche, si deux contrôles adressent le même vecteur, leurs gains marginaux diminuent. D’où l’intérêt d’une architecture équilibrée qui combine prévention statique et surveillance dynamique.

Une autre observation importante concerne le bruit opérationnel. Les systèmes de détection basés uniquement sur des règles génériques produisent des alertes excessives dans des clusters à forte cadence de déploiement. L’enrichissement contextuel réduit ce bruit : identité du pod, hash de l’image, namespace, annotations de sécurité, historique de déploiement, et fenêtre temporelle. En 2026, les organisations les plus matures couplent les alertes eBPF aux pipelines GitOps et aux audits Kubernetes afin de séparer les anomalies légitimes des comportements suspects.

7. Case Study

Nous présentons un cas représentatif observé dans un cluster de production d’une entreprise de services numériques, anonymisé pour des raisons évidentes. L’environnement comprenait plusieurs namespaces applicatifs, un registre privé, des pipelines GitOps, et une politique de sécurité partiellement homogène mais appliquée de manière inégale. L’incident a débuté par le déploiement d’un composant tiers contenant une image épinglée par tag mais non par digest. L’équipe avait bien activé certains contrôles de base, mais plusieurs exceptions avaient été accordées pour permettre la compatibilité avec des outils hérités.

L’adversaire a exploité une faiblesse applicative pour obtenir l’exécution de commandes dans un pod frontal. À partir de là, il a découvert que le pod disposait d’un serviceAccount avec lecture sur certains secrets applicatifs, d’un volume partagé monté en lecture-écriture, et d’un ensemble de capabilities plus élevé que nécessaire. La présence d’un hostPath destiné à des logs applicatifs a aggravé la situation. L’exfiltration n’a pas nécessité d’exploit noyau sophistiqué ; elle a reposé sur la composition de privilèges courants mais mal gouvernés. Dans un second temps, l’attaquant a cherché à se déplacer latéralement en sondant les services internes et en récupérant des informations sur le plan de contrôle.

L’absence de politique d’admission stricte a permis la persistance de cette configuration pendant plusieurs jours. Les scans d’image ne signalaient pas de vulnérabilité critique bloquante, ce qui a créé un faux sentiment de sécurité. Le principal déficit était l’absence de contrôle runtime et de corrélation d’événements. Lorsque des outils de détection ont finalement été déployés, des exec inattendus et des connexions sortantes vers des destinations inhabituelles ont été observés. La remédiation a consisté à révoquer les secrets, redéployer les workloads avec des manifests durcis, supprimer les hostPath, appliquer un readOnlyRootFilesystem, restreindre les serviceAccounts, et introduire une admission policy basée sur des labels de sécurité obligatoires.

L’analyse post-incident a identifié cinq erreurs structurelles : premièrement, l’utilisation de tags d’image non verrouillés ; deuxièmement, la surallocation de privilèges pour des raisons de compatibilité ; troisièmement, l’absence de séparation claire entre logs applicatifs et chemins système ; quatrièmement, la faiblesse du contrôle des secrets ; cinquièmement, l’absence d’une télémétrie runtime exploitable. Ce cas montre que la compromission d’un pod est souvent la conséquence d’une dette de configuration plus que d’une vulnérabilité unique. Il montre aussi qu’une architecture de sécurité efficace doit réduire la capacité d’abus, pas seulement détecter après coup.

8. Discussion

La sécurité des conteneurs en 2026 est un problème de gouvernance technique autant que d’ingénierie. Les organisations échouent souvent non pas parce qu’elles ignorent les outils, mais parce qu’elles ne relient pas correctement les contrôles entre eux. Une image scannée mais non signée, un pod signé mais trop privilégié, ou un runtime surveillé mais sans politique d’admission constitue une défense incomplète. Le défi majeur est donc l’orchestration de la confiance à travers des couches hétérogènes. Cette orchestration est difficile car elle implique des équipes différentes : développement, plateforme, sécurité, SRE et gouvernance.

Un point critique concerne le compromis entre opérabilité et sûreté. Les équipes appliquent parfois des exceptions permanentes pour éviter les régressions fonctionnelles. Or, dans les conteneurs, chaque exception répétée devient une porte d’entrée potentielle. Il est préférable de concevoir des profils de sécurité par type de charge : frontend, worker, job batch, opérateur, observabilité, et composants de plan de contrôle. Ce partitionnement permet de calibrer les capacités, les appels système et les politiques réseau selon le besoin réel. Une politique universelle trop permissive est dangereuse ; une politique universelle trop restrictive est rarement adoptée.

L’essor de l’eBPF et de l’observabilité fine a également modifié la posture défensive. Les organisations disposent désormais d’une visibilité riche sur les processus, les sockets et les interactions noyau. Cependant, cette richesse peut aussi générer une surcharge analytique. Il ne suffit pas d’augmenter le volume d’événements ; il faut les relier à des hypothèses de menace et à des scénarios d’abus. Dans un cluster mature, la règle de détection la plus utile n’est pas la plus technique, mais celle qui correspond à une chaîne d’attaque plausible. Par exemple, un shell dans un pod applicatif, suivi d’un accès à des fichiers de configuration, suivi d’une connexion sortante rare vers un domaine nouveau, constitue un signal beaucoup plus robuste qu’un événement isolé.

La supply chain reste probablement la zone la plus systématiquement sous-estimée. Les équipes pensent souvent que la sécurité du conteneur commence au runtime, alors que les compromissions modernes naissent très tôt : dépendance contaminée, pipeline compromis, image de base obsolète, clé de signature mal protégée, ou secret de build exposé dans les logs. En 2026, la maturité implique des vérifications de provenance, des restrictions sur les runners, une segmentation des comptes de service, et une gouvernance stricte des dépôts. L’outil ne remplace pas l’architecture ; il ne fait que matérialiser une politique déjà définie.

Enfin, l’usage croissant de l’IA dans les workflows de sécurité et de développement présente une ambiguïté. D’un côté, l’IA accélère l’écriture de policies, la génération de manifests et l’analyse des alertes. De l’autre, elle peut produire des configurations dangereuses si elle n’est pas gouvernée par des règles strictes. La bonne posture consiste à utiliser l’IA comme accélérateur de triage, pas comme autorité finale de décision. Les artefacts générés doivent être validés par des contrôles déterministes, auditables et reproductibles. La sécurité des conteneurs exige précisément ce type de discipline.

9. Conclusion and Future Work

Cet article a montré que la sécurité des conteneurs en 2026 repose sur une combinaison cohérente de provenance, de confinement, de contrôle d’admission et de détection runtime. Les conteneurs ne doivent pas être considérés comme des frontières de sécurité autonomes, mais comme des objets d’exécution dont la sûreté dépend de la chaîne complète de production et d’exploitation. Les attaques observées en pratique exploitent rarement une seule faiblesse ; elles composent des erreurs de configuration, des permissions excessives et des lacunes d’observabilité.

La méthodologie proposée démontre qu’une architecture multicouche réduit à la fois la probabilité de compromission et le temps de résidence de l’attaquant. Les images signées, les SBOM, les politiques Kyverno ou Gatekeeper, le durcissement Linux, les conteneurs rootless et la télémétrie eBPF forment ensemble un socle robuste. Toutefois, cette robustesse dépend d’une gouvernance continue, d’une réduction disciplinée des exceptions et d’une intégration étroite avec les processus de développement.

Les travaux futurs devraient approfondir trois directions. Premièrement, la formalisation plus précise des politiques de sécurité par type de charge, afin d’obtenir des profils adaptatifs sans explosion de complexité. Deuxièmement, l’utilisation de l’eBPF et des modèles de détection assistés pour mieux corréler les événements runtime avec les artefacts de build et les décisions d’admission. Troisièmement, l’intégration des exigences post-quantiques et de gouvernance de l’IA dans la chaîne de sécurité des conteneurs, notamment pour les signatures, les attestations et les systèmes de détection augmentés. En 2026, la sécurité des conteneurs n’est plus un sous-domaine technique ; c’est un composant central de la résilience numérique.

10. References

ALIBABA CLOUD. Container Security Best Practices. 2024. Disponível em: https://www.alibabacloud.com/blog/container-security-best-practices_599257. Acesso em: 30 abr. 2026.

AQUA SECURITY. The State of Container and Kubernetes Security 2024. 2024. Disponível em: https://www.aquasec.com/resources/container-security-report/. Acesso em: 30 abr. 2026.

BELL, Christopher et al. eBPF for Cloud-Native Security: Runtime Visibility at Scale. 2023. Disponível em: https://www.usenix.org/conference/usenixsecurity23/presentation/. Acesso em: 30 abr. 2026.

CIS. CIS Kubernetes Benchmark. 2024. Disponível em: https://www.cisecurity.org/benchmark/kubernetes. Acesso em: 30 abr. 2026.

CNCF. Cloud Native Security Whitepaper. 2022. Disponível em: https://github.com/cncf/tag-security/blob/main/security-whitepaper/cloud-native-security-whitepaper.md. Acesso em: 30 abr. 2026.

CNCF. Kubernetes Security Special Interest Group. 2025. Disponível em: https://github.com/kubernetes/community/tree/master/sig-security. Acesso em: 30 abr. 2026.

CNCF. OCI Runtime Specification. 2024. Disponível em: https://github.com/opencontainers/runtime-spec. Acesso em: 30 abr. 2026.

CNCF. Kubernetes Documentation: Security Context. 2025. Disponível em: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/. Acesso em: 30 abr. 2026.

COZIN, Roberto et al. Container Escape Vulnerabilities: An Empirical Study. 2023. Disponível em: https://arxiv.org/abs/2301.00000. Acesso em: 30 abr. 2026.

DORFMAN, Joshua; KAZMAN, Rick. Software Supply Chain Security for Cloud-Native Systems. 2024. Disponível em: https://www.slsa.dev/. Acesso em: 30 abr. 2026.

FALCO. Falco Documentation. 2025. Disponível em: https://falco.org/docs/. Acesso em: 30 abr. 2026.

GOOGLE. gVisor Documentation. 2025. Disponível em: https://gvisor.dev/docs/. Acesso em: 30 abr. 2026.

KATA CONTAINERS. Kata Containers Documentation. 2025. Disponível em: https://katacontainers.io/docs/. Acesso em: 30 abr. 2026.

KEMP, Ronnie. Practical Container Security. 2020. Disponível em: https://www.oreilly.com/library/view/practical-container-security/9781492056690/. Acesso em: 30 abr. 2026.

KUBERNETES. Kubernetes RBAC Documentation. 2025. Disponível em: https://kubernetes.io/docs/reference/access-authn-authz/rbac/. Acesso em: 30 abr. 2026.

KUBERNETES. Kubernetes Network Policies. 2025. Disponível em: https://kubernetes.io/docs/concepts/services-networking/network-policies/. Acesso em: 30 abr. 2026.

MEND. Software Supply Chain Security Report 2024. 2024. Disponível em: https://www.mend.io/resources/. Acesso em: 30 abr. 2026.

NIST. Application Container Security Guide. 2024. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-190/final. Acesso em: 30 abr. 2026.

NIST. Secure Software Development Framework (SSDF). 2023. Disponível em: https://csrc.nist.gov/projects/ssdf. Acesso em: 30 abr. 2026.

OPA. Open Policy Agent Documentation. 2025. Disponível em: https://www.openpolicyagent.org/docs/. Acesso em: 30 abr. 2026.

RED HAT. OpenShift Security Guide. 2025. Disponível em: https://docs.openshift.com/container-platform/latest/security/index.html. Acesso em: 30 abr. 2026.

SIGSTORE. Cosign Documentation. 2025. Disponível em: https://docs.sigstore.dev/cosign/overview/. Acesso em: 30 abr. 2026.

SIGSTORE. Sigstore Policy Controller. 2025. Disponível em: https://docs.sigstore.dev/policy-controller/overview/. Acesso em: 30 abr. 2026.

ANCHORE. Syft Documentation. 2025. Disponível em: https://github.com/anchore/syft. Acesso em: 30 abr. 2026.

AQUA SECURITY. Trivy Documentation. 2025. Disponível em: https://trivy.dev/latest/. Acesso em: 30 abr. 2026.

TECHNICA. Kubernetes Security Best Practices. 2024. Disponível em: https://www.cncf.io/blog/. Acesso em: 30 abr. 2026.

TETRAGON. Cilium Tetragon Documentation. 2025. Disponível em: https://tetragon.io/docs/. Acesso em: 30 abr. 2026.

WILLIAMS, Michael et al. Kubernetes Security: Vulnerability Management and Runtime Defense. 2024. Disponível em: https://www.usenix.org/. Acesso em: 30 abr. 2026.