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

Les clusters Kubernetes exposent plusieurs surfaces de contrôle : accès à l'API, permissions des workloads, configuration des conteneurs, chemins réseau, images et secrets. Une faiblesse dans une couche peut affecter les workloads ou l'infrastructure plus large. La sécurité part donc du modèle de menace du cluster, pas d'un pourcentage sectoriel d'incidents.

Ce guide organise les contrôles qu'une équipe de production doit évaluer. Leur liste et leur ordre de déploiement dépendent du cluster, des workloads et du risque.

La sécurité Kubernetes couvre l'accès à l'API, l'isolation des workloads, les images, les secrets, les réseaux, l'admission et la surveillance à l'exécution. Utilisez la checklist officielle comme référence, puis hiérarchisez les contrôles selon le modèle de menace du cluster. Un calendrier fixe par semaine reste un simple exemple de planification.

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 contrôles de ressources. Définissez les requêtes et évaluez des limites adaptées à chaque workload. La checklist Kubernetes recommande une limite mémoire inférieure ou égale à la requête et indique que des limites CPU peuvent convenir aux workloads sensibles :

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. Configurez les événements requis par le modèle de menace, protégez les journaux contre les accès généraux et transmettez-les au système d'analyse approuvé.

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 exige une maintenance continue. Commencez par les lacunes d'identité, de workload et de chaîne d'approvisionnement qui présentent le plus grand risque, puis ajoutez les contrôles justifiés par le modèle de menace. Réexaminez-les lorsque les charges, les dépendances ou les menaces évoluent. Besoin d'aide pour sécuriser vos clusters Kubernetes ? Parlons-en.

Sources primaires

• Checklist de sécurité Kubernetes, consultée le 27 août 2026
• Standards de sécurité des pods Kubernetes, consultés le 27 août 2026