Kubernetes et cloud‑native : comment protéger les états critiques d’une infrastructure éphémère

Par Emmanuel Forgues - 20 octobre 2025

Chapô – Dans les architectures cloud‑native, l’évolutivité et la résilience reposent sur l’éphémérité des composants : pods qui naissent, se déplacent ou meurent en quelques secondes. Cette dynamique contredit le besoin de persistance pour les bases de données, les files d’attente ou tout autre état critique. Entre exigences de sécurité (confidentialité, intégrité, disponibilité), contraintes réglementaires et impératifs économiques, protéger ces états est un défi technique et organisationnel majeur. Ce texte analyse les mécanismes natifs de Kubernetes, les bonnes pratiques DevSecOps et les leviers de gouvernance permettant d’assurer une persistance fiable tout en conservant les bénéfices du cloud‑native.

Publié initialement le 20 octobre 2025.

Mis à jour le 14 mai 2026.

Migré vers StratoSentry le 16 mai 2026.

Introduction : l’incompatibilité apparente entre éphémérité et persistance

Imaginez le scénario suivant : une startup SaaS lance un service de traitement vidéo en temps réel. Chaque microservice tourne dans un pod Kubernetes, redéployé plusieurs fois par jour pour intégrer des correctifs ou répondre à la charge. Au même moment, les utilisateurs attendent que leurs fichiers soient stockés durablement et que leurs métadonnées restent accessibles malgré les mises à jour d’infrastructure.

Dans le modèle traditionnel (serveurs physiques ou VM), la persistance est assurée par un disque dédié ; la continuité des services repose sur la stabilité du serveur. En cloud‑native, l’infrastructure est volontairement volatile : les nœuds peuvent être remplacés, les pods redémarrés, les clusters migrés entre zones géographiques.

Le problème central : comment garantir que les états critiques (bases de données, files d’attente, caches, secrets) survivent à ces bouleversements sans perdre en sécurité ni en conformité ?

Ce document décrit d'abord les contraintes inhérentes à l’éphémérité, puis détaille les primitives Kubernetes et les pratiques DevSecOps qui assurent la protection des données. Il expose enfin les limites, les risques résiduels et les décisions concrètes que les organisations doivent prendre.

1. L’éphémérité du cloud‑native : sources de vulnérabilité

Ces comportements sont indispensables à la résilience (ex. : reprise après panne) mais introduisent deux classes de vulnérabilités :

• Volatilité du disque local – Le stockage éphémère (emptyDir, hostPath) disparaît avec le pod.
• Incohérence des métadonnées – Les objets Kubernetes (ConfigMap, Secret) peuvent être modifiés ou perdus si les contrôles d’accès ne sont pas stricts.

La nature dynamique du cloud‑native rend difficile l’application traditionnelle de politiques de sécurité basées sur l’adresse IP ou le serveur physique. La protection des états doit être repensée autour de concepts déclaratifs, centrés sur les API et indépendants du cycle de vie des pods.

2. Principes fondamentaux de la protection des états

Ces exigences s’appliquent à chaque couche : le stockage sous‑jacent (disques, services S3), la plateforme d’orchestration (API Server, etcd) et les applications elles‑mêmes (bases de données, caches).

3. Les primitives Kubernetes pour persister les états critiques

3.1 Volumes persistants (PV/PVC)

• PersistentVolume (PV) – Ressource représentant un dispositif de stockage fourni par l’administrateur (ex. : disque EBS, réseau NFS).
• PersistentVolumeClaim (PVC) – Demande d’un espace persistant faite par une application, décorrélée du PV réel grâce à la StorageClass.

Cette séparation permet aux développeurs de déclarer leurs besoins sans connaître le détail technique du stockage sous‑jacent. Le PVC reste attaché au pod même si celui‑ci est recréé, garantissant la continuité des données.

3.2 StorageClasses et CSI drivers

Les StorageClass définissent les paramètres (type de disque, IOPS, chiffrement). Les Container Storage Interface (CSI) drivers offrent une abstraction standardisée pour interagir avec les fournisseurs cloud (AWS EBS CSI, Azure Disk CSI, Ceph‑RBD CSI, etc.) et permettent des fonctionnalités avancées :

• Snapshots – Point‑in‑time copy exploitable pour la sauvegarde.
• Cloning – Création rapide d’un volume à partir d’un autre.
• Encryption at rest – Gérée par le driver ou le service de stockage.

3.3 StatefulSets et PodDisruptionBudgets

Pour les workloads qui requièrent un stable network identity (ex. : bases de données), Kubernetes propose StatefulSet :

• Nom d’hôte stable (pod-0, pod-1…)
• Ordonnancement du démarrage/arrêt, garantissant que chaque pod possède son PV dédié.

Le PodDisruptionBudget (PDB) définit le nombre minimal de pods qui doivent rester opérationnels pendant les opérations de maintenance, limitant ainsi la perte de disponibilité lors d’un node drain ou d’une mise à jour de version du cluster.

4. Sécurisation du stockage persistant

4.1 Chiffrement des données

Le chiffrement doit être déclaratif dans la StorageClass : parameters: encrypted=true. La clé de chiffrement doit être gérée par un Key Management Service (KMS) afin d’assurer l’auditabilité et la rotation automatisée.

4.2 Contrôles d’accès

• RBAC sur les PVC/PV – Utilisation de ResourceNames dans les Role/ClusterRole pour restreindre l’accès à des volumes spécifiques.
• IAM integration – Les drivers CSI peuvent fédérer les identités Kubernetes vers le cloud provider (ex. : IAM roles for service accounts sur AWS) afin que chaque pod ne possède que les permissions strictement nécessaires.
• Policies de réseau (NetworkPolicy) – Limiter la communication entre pods et services de stockage pour réduire la surface d’attaque.

4.3 Audits et journalisation

Kubernetes expose un audit log configurable (--audit-policy-file). Il faut inclure les opérations suivantes :

• create, delete sur les objets PersistentVolumeClaim, Snapshot, Secret.
• Accès aux endpoints d’API du CSI driver.

Ces logs doivent être agrégés (ex.<0xE2><0x80><0xAF>: Elastic Stack, Loki) et corrélés avec ceux des fournisseurs de stockage pour détecter toute activité suspecte.

5. Gestion des données sensibles : secrets, configmaps et vaults externes

5️⃣ Secrets natifs vs solutions tierces

Pour les workloads critiques, l'utilisation d'un vault externe couplé au CSI Secrets Store Driver permet aux pods de monter les secrets comme des volumes temporaires, tout en profitant du chiffrement «<0xE2><0x80><0xAF>in‑transit<0xE2><0x80><0xAF>» fourni par le driver.

5.6 Rotation et révocation

La rotation doit être automatisée via des CronJobs ou des pipelines CI/CD qui :

• Génèrent un nouveau secret dans le vault.
• Mettront à jour les SecretProviderClass correspondantes.
• Redéploieront (rolling update) les pods concernés.

Cette approche minimise la fenêtre d’exposition et assure la conformité aux exigences réglementaires (ex.<0xE2><0x80><0xAF>: GDPR art.<0xE2><0x80><0xAF>32, PCI‑DSS 3.2.1).

6. Opérations résilientes : sauvegarde, restauration et disaster recovery

6.1 Snapshots et clones

Les CSI drivers proposent des API VolumeSnapshot et VolumeClone. Un workflow typique<0xE2><0x80><0xAF>:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: db-snap-2024-07-01
spec:
  volumeSnapshotClassName: csi-aws-vsc
  source:
    persistentVolumeClaimName: pg-data-pvc

Les snapshots sont immutables et peuvent être conservés plusieurs jours, facilitant la restauration point‑in‑time.

6.2 Backup as a Service (BaaS)

Des solutions tierces (Velero, Kasten K10) offrent :

• Sauvegarde des ressources Kubernetes (ConfigMap, Secret, PVC) vers un stockage objet (S3, Azure Blob).
• Orchestration de la restauration multi‑cluster.

Ces outils s’intègrent aux politiques d’RTO/RPO<0xE2><0x80><0xAF>: par exemple, un RPO de 15<0xE2><0x80><0xAF>minutes pour les bases transactionnelles implique la prise de snapshots toutes les 10<0xE2><0x80><0xAF>minutes et leur réplication hors site.

6.3 Disaster Recovery inter‑zone / multi‑cloud

Pour les architectures géo‑redondantes :

• Replication Asynchronous – Le CSI driver réplique les volumes vers une zone secondaire (ex. : cross‑region replication d’AWS EBS).
• Failover automatisé – Un opérateur Kubernetes (ex. : Stork de Portworx) détecte la perte de zone et bascule le StatefulSet sur les PVC répliqués.

Ces mécanismes nécessitent une politique de gouvernance clairement définie (qui déclenche le failover, qui valide la cohérence des données).

7. Gouvernance, conformité et auditabilité dans un environnement éphémère

Un framework DevSecOps doit être mis en place<0xE2><0x80><0xAF>: chaque modification d’infrastructure (ex.<0xE2><0x80><0xAF>: création d’un PVC) passe par un pipeline CI/CD qui exécute des scans (kube‑score, kube‑audit) et vérifie la conformité aux politiques de chiffrement et d’accès.

8. Étude de cas – Plateforme SaaS de traitement vidéo en temps réel

Contexte

• Produit : Service de montage vidéo à la demande, stockant les fichiers source (10 Go‑100 Go) et les rendus finaux.
• Charge : Pic de 5 000 requêtes/s, utilisation de GPU via device plugins.
• Contraintes : Temps de latence < 2 s, conformité GDPR, sauvegarde RPO = 30 min.

Architecture cloud‑native

• Ingress expose l’API via TLS.
• PostgreSQL tourne dans un StatefulSet avec un PVC provisionné par la StorageClass gp2-encrypted.
• Les fichiers bruts sont stockés directement dans un bucket S3 chiffré (SSE‑KMS), référencés via des métadonnées dans PostgreSQL.
• Velero prend un snapshot de la base toutes les 15 minutes et réplique le bucket S3 vers une région secondaire.

Sécurité des états critiques

Résultats observés

La combinaison des primitives Kubernetes (PV/PVC, StatefulSet), des CSI drivers et d’outils DevSecOps (Velero, Vault, OPA) permet de concilier éphémérité du déploiement avec persistabilité sécurisée des données critiques.

9. Points de vigilance et limites

### Points de vigilance

• Dépendance au fournisseur de stockage : la perte d’un service cloud (ex. : AWS EBS outage) impacte directement les

Poursuivre le parcours : Résilience et protection des données S3 → Solution → Produit → Demander une démonstration

Retour au blog