TL;DR
Kubernetes en production ne se résume pas à un cluster managé déployé via Terraform et un kubectl apply quotidien. Six piliers conditionnent la robustesse : hardening (CIS Kubernetes Benchmark, kube-bench), RBAC et gestion des secrets, sécurité du runtime container (scanning d’images, signatures, NetworkPolicy), supply chain logicielle (SBOM, attestations SLSA, contrôle d’admission), observabilité (Prometheus, OpenTelemetry, logs centralisés), continuité (Velero, plan de reprise multi-AZ ou multi-région testé). Le GitOps (ArgoCD, Flux) industrialise les déploiements et permet le rollback rapide. NIS2 et les recommandations ANSSI imposent des journaux 24/7 et une capacité de détection-réponse documentée. Les pièges les plus coûteux : pas de Resource Limits, single-cluster sans plan de bascule, Secrets en clair, oubli des Custom Resource Definitions lors des upgrades.
Kubernetes en prod : ce que personne ne dit en formation
Une formation Kubernetes apprend à déployer un Deployment, exposer un Service, gérer un Ingress. Elle apprend peu sur ce qui distingue un cluster de POC d’un cluster qui tient en production.
Ce qui manque, dans l’ordre d’apparition des incidents.
Les Resource Requests et Limits. Sans Requests, le scheduler place les pods n’importe où. Sans Limits, un pod en fuite mémoire dégrade tout le noeud. Les défauts d’usine n’imposent rien : c’est à l’équipe de définir une politique.
La saturation silencieuse. Un cluster peut fonctionner jusqu’à 80 % de pression CPU/mémoire avant que les symptômes deviennent visibles. Au-delà, la dégradation est non linéaire : evictions, throttling CPU, OOMKilled en cascade.
Les CRDs lors des upgrades. Une upgrade de version Kubernetes peut casser des Custom Resource Definitions fournis par des opérateurs (cert-manager, ingress-nginx, ArgoCD). Procédure d’upgrade documentée par chaque éditeur, à intégrer au plan.
Les secrets en clair. Un Secret Kubernetes est encodé en base64, pas chiffré. Sans chiffrement at-rest configuré sur etcd, le secret reste lisible par quiconque accède au backup etcd.
Ces angles morts conditionnent les six piliers qui suivent.
Pilier 1 : Hardening cluster
Le CIS Kubernetes Benchmark, maintenu par le Center for Internet Security, constitue la référence ouverte du hardening cluster [1]. Il couvre plus de 100 contrôles (configuration du kube-apiserver, etcd, kubelet, kube-controller-manager) avec un niveau Level 1 (par défaut acceptable en production) et Level 2 (renforcé, parfois contraignant).
kube-bench, outil open source d’Aqua Security, exécute le benchmark contre un cluster et produit un rapport ligne par ligne. À lancer en post-installation et en cycle régulier (mensuel minimum).
Les recommandations critiques à appliquer en priorité.
API server. Anonymous-auth désactivé, audit logs activés (--audit-log-path configuré), TLS forcé sur les communications cluster, ciphersuites restreintes.
etcd. Chiffrement at-rest activé (encryption-provider-config), TLS mutuel entre etcd et le control plane, sauvegardes régulières (voir Pilier 6).
Kubelet. --anonymous-auth=false, --authorization-mode=Webhook, désactivation du --read-only-port, restriction des privileged containers.
Réseau du control plane. API server non exposé publiquement (endpoint privé sur les clusters managés EKS, GKE, AKS quand possible), accès via bastion ou VPN.
NIST SP 800-190, “Application Container Security Guide”, reste la référence de fond sur la sécurité des conteneurs en général et de Kubernetes en particulier [2]. Lecture obligatoire pour un RSSI ou un lead plateforme.
Pilier 2 : RBAC et secrets
RBAC
Le RBAC Kubernetes (Role-Based Access Control) repose sur quatre objets : Role, ClusterRole, RoleBinding, ClusterRoleBinding [3]. Le principe du moindre privilège impose plusieurs règles.
Pas de cluster-admin par défaut. Le rôle cluster-admin accorde tous les droits sur toutes les ressources. À réserver aux comptes break-glass tracés, pas aux comptes nominatifs des équipes.
Roles namespaced. Une équipe produit dispose d’un Role limité à son namespace, jamais d’un ClusterRole couvrant tout le cluster.
ServiceAccounts dédiés. Chaque workload utilise un ServiceAccount spécifique, avec un Role minimal. Le ServiceAccount default n’est jamais utilisé en production.
Audit et revue. Les RoleBinding et ClusterRoleBinding sont revus trimestriellement. Un outil comme rbac-lookup ou kubectl-who-can permet d’auditer rapidement “qui peut faire quoi”.
Secrets
Les Secrets Kubernetes sont stockés en base64 dans etcd. Sans chiffrement at-rest configuré, ils sont lisibles par tout accès à etcd ou à un backup etcd. Trois niveaux de remédiation.
Niveau 1 : chiffrement at-rest etcd. Configuration EncryptionConfiguration au niveau du kube-apiserver, idéalement avec une clé gérée par un KMS externe (AWS KMS, Cloud KMS, Azure Key Vault).
Niveau 2 : External Secrets Operator. Au lieu de stocker les secrets dans Git (même chiffrés via sealed-secrets ou SOPS), l’opérateur synchronise les secrets depuis un coffre externe (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault). Les manifestes Kubernetes ne contiennent que les références.
Niveau 3 : rotation automatisée. Les secrets sensibles (clés API, mots de passe BDD) rotés sur cycle court (30 à 90 jours selon criticité), avec mécanisme de propagation aux workloads (rolling restart, reload chaud quand l’application le supporte).
La documentation Kubernetes officielle détaille les bonnes pratiques [4]. ConfigMap et Secret ne sont pas interchangeables : un ConfigMap n’a aucune protection, il est dédié aux valeurs non sensibles.
Pilier 3 : Sécurité du runtime container
Image scanning
Toute image qui entre en production passe par un scanner de vulnérabilités. Trois outils ouverts dominants.
Trivy (Aqua Security) : scan complet image plus IaC plus secrets, ligne de commande, intégration CI native [5].
Grype (Anchore) : scan d’images et de SBOM, base de données mise à jour fréquemment.
Clair (Red Hat) : utilisé par Harbor et Quay, plus orienté usage server.
Le scan se fait à deux moments : dans le pipeline CI (avant push registry) et en continu sur les images déjà en production (un CVE découvert aujourd’hui peut concerner une image stable depuis 6 mois). La politique de blocage doit être explicite : CVE Critical bloque le déploiement, CVE High alerte et impose un ticket de remédiation à 30 jours.
Signatures et provenance
Sigstore/Cosign signe les images container avec une clé OIDC, sans nécessiter un PKI maintenu en interne [6]. La vérification se fait au déploiement (par le contrôle d’admission, voir Pilier 4). Toute image non signée ou signée par une clé non autorisée est refusée.
SLSA (Supply chain Levels for Software Artifacts) est un framework qui définit quatre niveaux de garantie sur la provenance d’un artefact [7]. SLSA 3 implique un build reproductible et une attestation de provenance signée. Adopté par les projets CNCF et imposé progressivement par les exigences réglementaires (Cyber Resilience Act européen, Executive Order 14028 aux États-Unis).
Réseau et isolation
NetworkPolicy. Par défaut, tous les pods communiquent entre eux dans Kubernetes. Une politique par défaut “deny-all” suivie de NetworkPolicies explicites par namespace réduit drastiquement la surface d’attaque en cas de compromission d’un pod [8].
Pod Security Standards. Trois profils (privileged, baseline, restricted) remplacent les anciens PodSecurityPolicies. Le profil restricted s’applique à tous les namespaces de production : pas de containers privilégiés, pas d’accès au hostPath, runAsNonRoot, capabilities limitées.
Service mesh. Istio, Linkerd ou Cilium Service Mesh ajoutent un mTLS automatique entre tous les services, des politiques d’autorisation au niveau L7, et une observabilité de trafic. Indispensable au-delà d’une certaine taille de cluster, optionnel sur un cluster modeste.
Pilier 4 : Supply chain logicielle
La supply chain logicielle est devenue une cible d’attaque majeure (incidents documentés : SolarWinds, Log4Shell, attaques sur npm et PyPI). Quatre mesures concrètes en environnement Kubernetes.
SBOM (Software Bill of Materials). Inventaire de tous les composants d’une image : OS de base, librairies, dépendances applicatives. Formats standards : CycloneDX, SPDX. Généré au build (par Trivy, syft, ou directement dans Docker buildx), stocké à côté de l’image dans le registry.
Attestations SLSA. Documents signés décrivant le contexte du build (qui, quand, depuis quel code source, avec quels outils). Vérifiables au déploiement.
Registries privées. Hébergement des images applicatives dans une registry contrôlée (ECR, Artifact Registry, Azure Container Registry, Harbor self-hosted), avec scan automatique, signature et politique de rétention. Pull-through cache vers Docker Hub ou autres registres publics pour éviter les rate-limits et les disparitions d’images.
Contrôle d’admission. Avant qu’un pod ne soit créé, un webhook valide la conformité. Deux outils dominants.
Kyverno [9] : politique écrite en YAML, intégration native Kubernetes, courbe d’apprentissage faible. Adapté à 80 % des cas (vérification d’images signées, NetworkPolicy obligatoire, labels imposés, refus des images sans tag spécifique).
OPA Gatekeeper [10] : politique écrite en Rego (langage de OPA), plus puissant et plus expressif, courbe d’apprentissage plus raide. Adapté aux politiques complexes avec logique métier.
Une politique d’admission minimale en production : refus des images non signées, refus du tag latest, exigence de Resource Limits, exigence de runAsNonRoot, NetworkPolicy par défaut sur tout nouveau namespace.
Pilier 5 : Observabilité
L’observabilité Kubernetes s’articule sur les trois piliers classiques (métriques, traces, logs) plus la corrélation.
Métriques
Prometheus est le standard de facto [11]. Architecture pull, collecte via /metrics exposé par les workloads et les exporters (node-exporter, kube-state-metrics, blackbox-exporter). Storage local short-term, Thanos ou Cortex pour la rétention long-terme et le multi-cluster.
Métriques minimales à exposer : RED (Rate, Errors, Duration) au niveau service, USE (Utilization, Saturation, Errors) au niveau ressource (CPU, mémoire, disque, réseau). Les SLO/SLI s’appuient sur ces métriques.
Traces
OpenTelemetry unifie l’instrumentation traces, métriques et logs [12]. Le projet a absorbé OpenTracing et OpenCensus. SDK pour tous les langages mainstream, OpenTelemetry Collector pour l’agrégation et le routage vers les backends (Jaeger, Tempo, Datadog, AWS X-Ray, Cloud Trace).
L’instrumentation auto (Java, Python, Node.js) suffit pour démarrer. L’instrumentation manuelle ajoute les attributs métier (user_id, tenant_id, type de transaction) qui permettent les recherches avancées.
Logs
Loki (Grafana Labs) : approche label-based, intégration native avec Prometheus et Grafana, coût de stockage faible [13]. Adapté à un environnement Kubernetes où les workloads tournent dans des pods éphémères et où les labels Kubernetes (namespace, pod, app) suffisent à filtrer.
Fluent Bit ou Vector comme agent de collecte : léger, performant, parseurs natifs pour formats courants. Routage vers Loki, Elasticsearch, S3 archive, ou stack tiers.
Corrélation
Les trois piliers ne valent que corrélés. Le trace_id injecté dans les logs (via OpenTelemetry) permet de passer d’une trace ralentie à ses logs en un clic. Les labels Kubernetes (namespace, app, version) partagés entre métriques, traces et logs permettent les drill-down.
Grafana unifie l’affichage (Prometheus pour les métriques, Tempo pour les traces, Loki pour les logs) avec navigation croisée. Une stack Grafana managée (Grafana Cloud) ou self-hosted (Operator officiel) est devenue le pattern dominant.
Pilier 6 : Continuité et reprise
Sauvegardes
Velero [14] sauvegarde l’état Kubernetes (objets API) plus les Persistent Volumes (via snapshots natifs CSI ou via restic/kopia pour les PV non-CSI). Backup scheduled, restore granulaire (par namespace, par label, par ressource).
Trois cibles de sauvegarde minimum.
etcd. Sauvegardes régulières du stockage du control plane. Sur un cluster managé (EKS, GKE, AKS), c’est géré par le fournisseur. Sur un cluster self-managed, c’est à configurer.
Manifestes et Custom Resources. Velero capture les objets API. La source de vérité reste Git (GitOps), mais Velero protège contre les dérives non versionnées et accélère le restore.
Données applicatives (PV). Velero plus snapshots CSI quand le storage backend les supporte (EBS, GCE PD, Azure Disk, Ceph). Pour les bases de données, complémenter par une stratégie native (dump pg_basebackup, snapshot RDS) avec un RPO documenté.
Disaster recovery
Multi-AZ par défaut. Un cluster en production utilise au minimum trois Availability Zones avec topologySpreadConstraints sur les workloads critiques pour répartir les replicas.
Multi-région ou multi-cluster. Pour les charges à RTO faible (moins d’une heure), un second cluster en région distincte avec réplication des données et bascule DNS. La complexité de la fédération multi-cluster (Karmada, Cluster API + GitOps central) reste élevée, à n’engager que si le besoin est documenté.
Test régulier. Un plan de DR non testé est une fiction. Test annuel minimum, trimestriel idéalement. Procédure jouée en réel, RTO/RPO mesurés, écarts documentés.
GitOps : déployer en production sans drama
Le GitOps applique au déploiement Kubernetes les principes de Git : source de vérité versionnée, revue par pull request, audit complet, rollback par revert.
ArgoCD [15] et Flux [16] dominent. Deux modes principaux.
Pull-based. L’agent dans le cluster (ArgoCD ou Flux) lit le repo Git et applique les changements détectés. Pas de credentials cluster exposés à l’extérieur. Modèle recommandé.
Push-based. Un pipeline CI applique les manifestes au cluster. Plus simple mais nécessite que le CI ait des credentials Kubernetes valides en permanence.
Rollback automatique. ArgoCD et Flux détectent les Sync failures et peuvent rollback automatiquement vers le dernier état stable. Combiné aux health checks (readiness, liveness) et aux Argo Rollouts (canary, blue-green), permet des déploiements progressifs sans intervention manuelle.
Pas de kubectl apply direct en production. Tout passe par Git. Les modifications faites en direct (debug, fix urgent) sont reversées au prochain sync, sauf si le namespace est marqué hors-GitOps (à éviter).
Articulation NIS2 et exigences ANSSI
La directive NIS2, transposée en France par la loi du 24 avril 2024, impose aux entités essentielles et importantes plusieurs obligations qui touchent directement un cluster Kubernetes en production [17].
Journaux 24/7. Conservation des logs de sécurité pendant au moins 12 mois, accessibles pour investigation. Concrètement : agrégation des audit logs Kubernetes, logs applicatifs, logs réseau (NetworkPolicy events, service mesh access logs) dans une stack centralisée avec rétention conforme.
Détection et réponse. Capacité de détecter un incident de sécurité dans des délais documentés. Outils typiques : Falco (détection runtime des comportements anormaux), Tetragon (eBPF-based), intégration SIEM (Splunk, Wazuh, Elastic SIEM, équivalents souverains).
Notification à l’autorité. En cas d’incident significatif, notification à l’ANSSI dans les 24 heures (alerte précoce), puis 72 heures (notification d’incident), puis 1 mois (rapport final). Procédure documentée et testée.
L’ANSSI publie également des guides pratiques sur la sécurité Kubernetes via son portail [18] et CyberMaLveillance, alignés sur les standards CNCF et NIST.
Pièges fréquents
Pas de Resource Limits. Un pod sans Limits peut consommer toute la mémoire d’un noeud. Politique d’admission qui rejette tout Deployment sans Limits définis.
Single-cluster sans réplicas. Un cluster unique avec un master non haute-disponibilité est un SPOF. Cluster managé multi-master par défaut, multi-AZ obligatoire.
Secrets en clair. Voir Pilier 2.
Oubli des CRDs lors des upgrades. Une upgrade Kubernetes peut casser des opérateurs. Procédure : tester sur cluster pré-production avec les mêmes opérateurs, lire les release notes de chaque opérateur, vérifier la compatibilité des CRDs.
Helm releases orphelines. Un namespace supprimé sans helm uninstall laisse des release records inutiles. Audit régulier via helm list --all-namespaces.
Cluster autoscaler mal calibré. Sans limites supérieures, un cluster autoscaler peut provisionner des centaines de noeuds suite à un misconfig. Toujours définir un MaxNodes raisonnable par node group.
Pas de PodDisruptionBudget. Lors d’un drain de noeud (maintenance, upgrade), un workload sans PDB peut perdre tous ses pods simultanément. PDB obligatoire sur les services critiques.
À retenir
Un cluster Kubernetes en production repose sur six piliers cohérents : hardening (CIS Benchmark, kube-bench), RBAC plus secrets externes, sécurité du runtime container (scan, signatures, NetworkPolicy, Pod Security Standards), supply chain logicielle (SBOM, attestations SLSA, contrôle d’admission Kyverno ou OPA Gatekeeper), observabilité (Prometheus, OpenTelemetry, Loki, corrélation par labels et trace_id), continuité (Velero, multi-AZ, plan de DR testé). Le GitOps (ArgoCD, Flux) industrialise les déploiements et rend les rollbacks rapides et auditables. NIS2 et les recommandations ANSSI imposent journaux 24/7 et capacité de détection-réponse documentée. Les pièges fréquents (pas de Resource Limits, single-cluster sans bascule, Secrets en clair, oubli des CRDs lors d’upgrades) restent les premiers points à corriger avant tout exercice de maturité avancée.
[1] Center for Internet Security, CIS Kubernetes Benchmark, cisecurity.org/benchmark/kubernetes. [2] NIST SP 800-190, Application Container Security Guide, csrc.nist.gov/pubs/sp/800/190/final. [3] Kubernetes Documentation, RBAC Authorization, kubernetes.io/docs/reference/access-authn-authz/rbac/. [4] Kubernetes Documentation, Secrets, kubernetes.io/docs/concepts/configuration/secret/. [5] Trivy, documentation officielle, aquasec.com/products/trivy/. [6] Sigstore, sigstore.dev. [7] SLSA Framework, slsa.dev/spec/v1.0/. [8] Kubernetes Documentation, Network Policies, kubernetes.io/docs/concepts/services-networking/network-policies/. [9] Kyverno, kyverno.io/docs/. [10] OPA Gatekeeper, open-policy-agent.github.io/gatekeeper/website/docs/. [11] Prometheus, documentation officielle, prometheus.io/docs/introduction/overview/. [12] OpenTelemetry, documentation officielle, opentelemetry.io/docs/. [13] Grafana Loki, documentation officielle, grafana.com/docs/loki/latest/. [14] Velero, documentation officielle, velero.io/docs/. [15] Argo CD, documentation officielle, argo-cd.readthedocs.io. [16] Flux CD, documentation officielle, fluxcd.io/flux/. [17] Directive (UE) 2022/2555 (NIS2), transposée en France par la loi du 24 avril 2024. [18] ANSSI, cyber.gouv.fr.