7 min de lecture - Sécurité Kubernetes : le guide pratique de la défense en profondeur

Kubernetes a gagné la guerre de l'orchestration de conteneurs, mais cette adoption massive s'accompagne de risques. Un simple pod mal configuré peut exposer des données sensibles. Un cluster compromis peut devenir un point de départ pour des attaques plus larges sur l'infrastructure. 94 % des organisations déclarent avoir subi au moins un incident de sécurité dans leurs environnements Kubernetes.

Bonne nouvelle : les organisations qui mettent en œuvre une sécurité en profondeur (defense-in-depth) obtiennent des résultats nettement meilleurs. Ce guide présente les couches de sécurité concrètes dont a besoin tout cluster Kubernetes en production.

Ce que vous allez apprendre

• Les défis de sécurité propres à Kubernetes
• La stratégie de défense en profondeur : sécurité du cluster, des images et de l'exécution (runtime)
• La configuration RBAC et les politiques réseau, avec des exemples concrets
• Le scan d'images, la signature et la sécurité de la chaîne d'approvisionnement (supply chain)
• La gestion des secrets avec intégration d'un coffre-fort externe (vault)
• Une feuille de route de mise en œuvre par phases (semaines 1 à 12)

L'essentiel

La sécurité Kubernetes exige une défense en profondeur sur trois couches : le cluster (RBAC, politiques réseau, pod security standards), l'image et la chaîne d'approvisionnement (scan de vulnérabilités, signature d'images, durcissement des images de base), et l'exécution (contrôleurs d'admission, limites de ressources, contextes de sécurité). Commencez par le RBAC et la journalisation d'audit en semaine 1, ajoutez les politiques réseau en semaine 2, déployez le scan d'images en semaine 3, puis intégrez progressivement la surveillance runtime et la sécurité du service mesh.

Le défi de la sécurité Kubernetes

Kubernetes introduit des défis de sécurité qui n'existent pas dans les infrastructures traditionnelles :

Une surface d'attaque distribuée. Au lieu de sécuriser une poignée de serveurs, vous devez protéger des centaines, voire des milliers de conteneurs éphémères répartis sur plusieurs nœuds, chacun disposant de sa propre connectivité réseau.

Un environnement dynamique. Les conteneurs sont créés et détruits en permanence, ce qui rend inefficaces les configurations de sécurité statiques.

Une architecture réseau complexe. Les communications pod à pod, les service meshes et les contrôleurs d'ingress créent des topologies réseau complexes, difficiles à sécuriser et à surveiller.

Des responsabilités partagées. La sécurité couvre l'image du conteneur, le runtime, l'orchestrateur et l'infrastructure sous-jacente — ce qui exige une coordination entre plusieurs équipes.

Stratégie de défense en profondeur

Couche 1 : la sécurité au niveau du cluster

RBAC (contrôle d'accès basé sur les rôles). Mettez en place des permissions granulaires suivant le principe du moindre privilège. Créez des comptes de service pour vos applications et limitez leurs permissions au strict nécessaire :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: app-reader
rules:
  - apiGroups: ['']
    resources: ['pods', 'services']
    verbs: ['get', 'list', 'watch']
  - apiGroups: ['apps']
    resources: ['deployments']
    verbs: ['get', 'list']

Les politiques réseau (Network Policies). Contrôlez le trafic entre les pods. Commencez par une politique de refus par défaut (default-deny), puis autorisez explicitement uniquement les communications nécessaires :

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

Les Pod Security Standards. Imposez des contextes de sécurité qui empêchent les conteneurs de s'exécuter en tant que root, désactivent l'escalade de privilèges et restreignent l'accès à l'hôte.

Couche 2 : la sécurité des images et de la chaîne d'approvisionnement

Le scan des images de conteneurs. Automatisez le scan de vulnérabilités pour toutes vos images. Utilisez Trivy, Clair ou Anchore pour détecter les vulnérabilités connues avant le déploiement.

La signature et la vérification des images. Utilisez Sigstore et des contrôleurs d'admission pour garantir que seules des images fiables et signées sont déployées sur vos clusters.

Le durcissement des images de base. Utilisez des images de base minimalistes (Alpine, Distroless) pour réduire la surface d'attaque. Mettez régulièrement à jour vos images de base pour corriger les vulnérabilités.

Couche 3 : la sécurité de l'exécution (runtime)

Les contrôleurs d'admission. Déployez OPA Gatekeeper ou Kyverno pour appliquer des politiques au moment du déploiement. Bloquez les workloads non conformes avant leur exécution.

Les limites de ressources. Définissez des limites de CPU et de mémoire pour tous les conteneurs afin de prévenir les attaques par épuisement des ressources :

resources:
  limits:
    cpu: '500m'
    memory: '256Mi'
  requests:
    cpu: '100m'
    memory: '128Mi'

Les contextes de sécurité (security contexts). Supprimez les capacités Linux inutiles, utilisez des systèmes de fichiers en lecture seule et exécutez les conteneurs en tant que non-root :

securityContext:
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ['ALL']

Modèles de sécurité avancés

La sécurité du service mesh

Déployez Istio ou Linkerd pour bénéficier de :

• Le mTLS (mutual TLS) — chiffrement et authentification automatiques pour toutes les communications pod à pod
• Les politiques de trafic — un contrôle granulaire des accès service à service
• L'observabilité — des métriques et journaux détaillés pour la surveillance de sécurité

Le réseau zero trust

Concevez votre cluster selon les principes du zero trust :

• Authentifiez et autorisez chaque connexion
• Chiffrez toutes les communications (mTLS partout)
• Mettez en place une micro-segmentation via les politiques réseau
• Surveillez et validez en continu les hypothèses de confiance

La gestion des secrets

Ne stockez jamais de secrets dans les images de conteneurs ni dans des variables d'environnement en clair :

• Utilisez les Kubernetes Secrets avec chiffrement au repos
• Intégrez HashiCorp Vault ou AWS Secrets Manager pour une gestion externe des secrets
• Mettez en place la rotation des secrets et la gestion de leur cycle de vie
• Utilisez le workload identity dès que possible pour éviter les identifiants statiques

Surveillance et réponse aux incidents

La surveillance de sécurité

La journalisation d'audit. Activez la journalisation d'audit Kubernetes pour tracer toutes les requêtes adressées au serveur API. Transmettez les journaux à un SIEM pour analyse.

La surveillance runtime. Utilisez Falco pour détecter les comportements anormaux : connexions réseau inattendues, modifications du système de fichiers, escalades de privilèges.

Le scan de conformité. Analysez régulièrement vos clusters au regard du CIS Kubernetes Benchmark ou du NSA/CISA Kubernetes Hardening Guide.

La réponse aux incidents

Préparez-vous aux incidents de sécurité grâce à :

• Des playbooks de réponse automatisée pour les scénarios courants
• Des capacités d'isolation réseau pour les workloads compromis
• Des procédures de collecte de données forensiques
• Des processus clairs d'escalade et de communication

Conformité et gouvernance

Le Policy as Code

Mettez en œuvre vos politiques de sécurité sous forme de code grâce à :

• OPA Gatekeeper — applique les politiques de l'organisation via le contrôle d'admission
• Kyverno — un moteur de politiques natif Kubernetes, à la syntaxe plus simple
• GitOps — versionne et audite tous les changements de politiques de sécurité

Cette approche garantit des politiques reproductibles, auditables et testables.

Feuille de route de mise en œuvre

La sécurité est une pratique continue

La sécurité Kubernetes n'est pas une configuration ponctuelle — c'est une pratique continue. Commencez par les fondamentaux à fort impact (RBAC, politiques réseau, scan d'images), construisez progressivement vers des modèles avancés (service mesh, zero trust), et adaptez-vous en continu aux nouvelles menaces. Les organisations qui font de la sécurité un enjeu de premier plan dans leur stratégie Kubernetes seront celles qui pourront en exploiter tout le potentiel en toute confiance. Besoin d'aide pour sécuriser vos clusters Kubernetes ? Parlons-en.