Sécurité des conteneurs : images, clusters, runtime

Vos conteneurs tournent en production, mais sont-ils vraiment sécurisés ? Ce guide vous explique les risques spécifiques aux conteneurs et comment les mitiger à chaque étape : build, deploy et runtime. Vous apprendrez à scanner vos images, durcir vos configurations Kubernetes et détecter les comportements anormaux. Résultat : une stratégie de sécurité conteneurs complète, de la CI/CD à la production.

Pourquoi les conteneurs sont-ils une cible ?

Les conteneurs ont révolutionné le déploiement d’applications, mais ils introduisent des surfaces d’attaque spécifiques que les approches de sécurité traditionnelles ne couvrent pas.

Le problème fondamental : les conteneurs partagent le noyau de l’hôte. Contrairement à une VM qui a son propre kernel, un conteneur n’est qu’un processus isolé. Si un attaquant exploite une vulnérabilité kernel depuis un conteneur, il peut potentiellement compromettre tout le nœud — et par extension, tous les autres conteneurs qui y tournent.

Incident réel : Tesla 2018

Des attaquants ont compromis un cluster Kubernetes de Tesla en exploitant une console d’administration non protégée. Ils ont utilisé les ressources pour miner des cryptomonnaies. L’accès au cluster a aussi exposé des données de télémétrie des véhicules.

Les 5 surfaces d’attaque principales

Comprendre où se situent les risques est la première étape pour les mitiger. Les conteneurs présentent des vulnérabilités à plusieurs niveaux :

Surface d’attaque	Risque	Exemple concret
Images vulnérables	CVE dans les dépendances, base image obsolète	Log4Shell présent dans une image Java non mise à jour
Configurations permissives	Conteneurs root, capabilities excessives	Un conteneur avec CAP_SYS_ADMIN peut modifier le système hôte
Secrets exposés	Variables d’environnement en clair, ConfigMaps accessibles	Mot de passe BDD visible via kubectl describe pod
Réseau ouvert	Absence de Network Policies, trafic est-ouest libre	Un pod compromis peut scanner tout le cluster
Supply chain	Images tierces non vérifiées, registres publics	Image Docker Hub contenant un cryptominer caché

Glissez pour voir

Ces risques ne sont pas théoriques. En 2023, plus de 1 500 images malveillantes ont été découvertes sur Docker Hub, certaines avec des millions de pulls.

Qui doit sécuriser quoi ?

La sécurité des conteneurs est une responsabilité partagée. Chaque profil a un rôle spécifique, et la collaboration est essentielle pour couvrir toutes les surfaces d’attaque.

Profil	Responsabilité principale	Actions concrètes
Développeur	Construire des images sécurisées	Utiliser des images de base minimales, ne pas embarquer de secrets, définir un USER non-root
Ops / SRE	Durcir l’infrastructure	Appliquer les Pod Security Standards, configurer les Network Policies, gérer les mises à jour
DevSecOps	Automatiser les contrôles	Intégrer Trivy dans la CI, bloquer les déploiements non conformes, alerter sur les dérives
RSSI / Compliance	Garantir la conformité	Auditer selon CIS Benchmarks, documenter les exceptions, préparer les certifications

Glissez pour voir

Shift-left security

Plus vous détectez un problème tôt dans le cycle de vie (développement), moins il coûte cher à corriger. Un scan d’image dans la CI prend 30 secondes. Corriger une vulnérabilité en production peut prendre des jours et impacter les utilisateurs.

La stratégie de défense en profondeur

La sécurité des conteneurs ne repose pas sur un seul outil ou une seule étape. Elle s’articule autour de trois phases qui se complètent : Build, Deploy et Runtime. Si une couche échoue, les autres limitent l’impact.

Phase 1 : Build — Sécuriser les images

C’est le moment le plus efficace pour détecter les problèmes. Une image vulnérable ne devrait jamais atteindre la production.

Bonnes pratiques :

• Images de base minimales : Préférez distroless ou alpine à ubuntu. Moins de paquets = moins de CVE potentielles. Une image distroless Python fait ~50 Mo contre ~900 Mo pour python:3.11.

• Scanner systématiquement : Intégrez un scanner (Trivy, Grype) dans votre CI. Bloquez le pipeline si une CVE critique est détectée.

• Ne jamais tourner en root : Ajoutez USER 1000 dans votre Dockerfile. Un conteneur root compromis peut modifier l’hôte.

• Signer vos images : Utilisez Cosign pour prouver l’origine et l’intégrité de vos images. Le cluster peut refuser les images non signées.

# Exemple de Dockerfile sécurisé
FROM python:3.11-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

FROM gcr.io/distroless/python3-debian11
WORKDIR /app
COPY --from=builder /app /app
COPY . .
USER 1000
CMD ["app.py"]

Phase 2 : Deploy — Durcir les configurations

Même une image sécurisée peut être déployée de manière dangereuse. Kubernetes offre de nombreuses options de sécurité, mais elles sont souvent désactivées par défaut.

Bonnes pratiques :

• Pod Security Standards : Appliquez le niveau restricted (ou au minimum baseline) sur vos namespaces. Cela interdit les conteneurs root, les capabilities dangereuses et les montages de volumes sensibles.

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

• Network Policies : Par défaut, tous les pods peuvent communiquer entre eux. Définissez des règles explicites pour n’autoriser que le trafic nécessaire.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

• ResourceQuota et LimitRange : Empêchez un pod compromis de consommer toutes les ressources du nœud (déni de service).

• RBAC strict : Appliquez le principe du moindre privilège. Un ServiceAccount ne devrait avoir que les permissions strictement nécessaires.

Phase 3 : Runtime — Détecter et bloquer

Les phases Build et Deploy ne suffisent pas. De nouvelles CVE sont découvertes quotidiennement, et un attaquant peut exploiter une faille zero-day. La protection runtime surveille les conteneurs en cours d’exécution.

Ce que surveille une solution runtime :

Signal	Ce qu’il détecte	Outil
Syscalls anormaux	Exécution de shell dans un conteneur, modification de fichiers système	Falco
Connexions réseau	Trafic vers des IPs suspectes, scan de ports	NeuVector, Cilium
Processus inattendus	Cryptominer, reverse shell	Falco, Sysdig
Dérive de configuration	Modification des fichiers par rapport à l’image d’origine	NeuVector

Glissez pour voir

Ne pas se reposer uniquement sur le runtime

La détection runtime arrive après l’intrusion. Elle limite les dégâts mais ne les empêche pas. Les phases Build et Deploy restent votre première ligne de défense.

Scénario : intégrer la sécurité dans votre pipeline

Voyons comment une équipe DevSecOps intègre ces trois phases dans un pipeline CI/CD réel. L’objectif : qu’aucune image vulnérable ou mal configurée n’atteigne la production.

1. Build : scanner l’image

   Dans la CI (GitLab CI, GitHub Actions, Jenkins), Trivy analyse l’image après le build. Si une CVE critique (score CVSS ≥ 9) est détectée, le pipeline échoue.

   .gitlab-ci.yml

   scan-image:
     stage: test
     script:
       - trivy image --exit-code 1 --severity CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

2. Registry : signer l’image

   Avant de pousser l’image vers le registre, elle est signée avec Cosign. La signature prouve qu’elle vient bien de votre CI et n’a pas été modifiée.

   cosign sign --key cosign.key $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

3. Admission : valider les manifests

   Au moment du déploiement, un admission controller (Kyverno, OPA Gatekeeper) vérifie que les manifests respectent les politiques de sécurité : pas de conteneur root, ressources définies, etc.

   # Politique Kyverno : interdire les conteneurs root
   apiVersion: kyverno.io/v1
   kind: ClusterPolicy
   metadata:
     name: require-non-root
   spec:
     rules:
       - name: check-runAsNonRoot
         match:
           resources:
             kinds:
               - Pod
         validate:
           message: "Les conteneurs doivent tourner en non-root"
           pattern:
             spec:
               containers:
                 - securityContext:
                     runAsNonRoot: true

4. Runtime : surveiller en production

   NeuVector ou Falco surveille les conteneurs déployés. Une alerte est déclenchée si un comportement anormal est détecté (shell interactif, connexion sortante suspecte).

Résultat : une vulnérabilité Log4Shell est détectée dans une dépendance Java lors du scan CI. Le pipeline échoue, le développeur est notifié, et l’image n’atteint jamais la production. Temps de détection : 45 secondes au lieu de plusieurs jours (ou jamais) sans scan.

Pièges courants à éviter

Même avec les bons outils, certaines erreurs reviennent fréquemment. Voici les pièges les plus courants et comment les éviter :

Erreurs fréquentes

Scanner uniquement au build — Les CVE sont découvertes en continu. Une image propre aujourd’hui peut être vulnérable demain. Scannez aussi les images en production régulièrement.

Désactiver les Pod Security Standards “pour que ça marche” — C’est la porte ouverte aux compromissions. Corrigez plutôt vos manifests pour qu’ils soient conformes.

Faire confiance aux images latest — Le tag latest peut pointer vers n’importe quoi. Utilisez des tags immuables (digest SHA256) pour garantir la reproductibilité.

Ignorer les Network Policies — Sans elles, un pod compromis peut scanner et attaquer tout le cluster. Le trafic est-ouest est souvent plus dangereux que le trafic nord-sud.

Stocker des secrets en variables d’environnement — Ils apparaissent dans les logs, les crashs dumps et kubectl describe. Utilisez des Secrets Kubernetes (ou mieux, un vault externe).

Outils recommandés

Voici les outils que nous recommandons pour chaque phase de la sécurité conteneurs :

Scanner de vulnérabilités

Outil	Forces	Quand l’utiliser
Trivy	Rapide, gratuit, multi-cibles (images, repos, IaC)	Premier choix pour la CI/CD
Grype	Léger, intégration Anchore	Alternative à Trivy
Snyk	Base de données CVE enrichie, remédiation guidée	Si vous avez un budget sécurité

Glissez pour voir

Conformité et audit

Outil	Forces	Quand l’utiliser
Kubescape	CIS Benchmarks, NSA guidelines, gratuit	Audit initial et continu
kube-bench	CIS Kubernetes Benchmark officiel	Audit de conformité formel
Polaris	Best practices Kubernetes, simple	Premiers pas en sécurité K8s

Glissez pour voir

Protection runtime

Outil	Forces	Quand l’utiliser
Falco	Open source, basé sur eBPF/syscalls	Détection d’intrusion
NeuVector	Protection complète (réseau + runtime), pare-feu L7	Sécurité enterprise
Sysdig Secure	Observabilité + sécurité intégrées	Si vous utilisez déjà Sysdig

Glissez pour voir

Guides détaillés

Kubescape Auditez votre cluster Kubernetes selon les CIS Benchmarks et les recommandations NSA. Détectez les mauvaises configurations avant qu'elles ne deviennent des vulnérabilités.

NeuVector Protection runtime complète : pare-feu réseau L7, détection de comportements anormaux et conformité continue pour Kubernetes.

Trivy Scanner de vulnérabilités multi-cibles : images conteneurs, dépendances, fichiers de configuration et code IaC.

Cosign Signez et vérifiez vos images conteneurs pour garantir leur intégrité et leur provenance dans la supply chain.

À retenir

1. Les conteneurs partagent le kernel — une vulnérabilité exploitée peut compromettre tout le nœud, pas juste le conteneur.

2. Défense en profondeur — Build (scan d’images) + Deploy (durcissement K8s) + Runtime (détection) = trois couches qui se complètent.

3. Shift-left — détectez les problèmes dans la CI, pas en production. Un scan prend 30 secondes, une remédiation d’incident prend des jours.

4. Pod Security Standards — appliquez au minimum le niveau baseline, visez restricted en production.

5. Network Policies obligatoires — sans elles, le trafic est-ouest est grand ouvert. Un pod compromis peut attaquer tout le cluster.

6. Scan continu — les CVE sont découvertes quotidiennement. Scannez aussi les images déjà déployées.

Checklist sécurité conteneurs

Build

• Images de base minimales (distroless, alpine)
• Scanner intégré dans la CI (Trivy, Grype)
• Pipeline bloqué si CVE critique détectée
• Pas de secrets dans les images
• Dockerfile avec USER non-root
• Images signées (Cosign)

Deploy

• Pod Security Standards appliqués (baseline ou restricted)
• Network Policies définies (deny by default)
• RBAC avec moindre privilège
• ResourceQuota et LimitRange configurés
• Secrets dans des Secret K8s (pas en variables d’environnement)

Runtime

• Outil de détection déployé (Falco, NeuVector)
• Alertes configurées pour les comportements anormaux
• Scan régulier des images en production
• Procédure de réponse aux incidents documentée

Prochaines étapes

Kubernetes Maîtrisez l'orchestrateur avant de le sécuriser. Comprendre son fonctionnement est essentiel pour identifier les risques.

Supply chain logicielle La sécurité des conteneurs commence avant le build : dépendances, images de base, provenance du code.

Gestion des secrets Comment stocker, distribuer et rotater les secrets de manière sécurisée dans Kubernetes.

Principe du moindre privilège Le concept fondamental qui sous-tend toutes les bonnes pratiques de sécurité conteneurs.

×

📖 Voir la documentation →