Sécurité des environnements cloud-native et Zero Trust

Extrait du mémoire de Master 2 Cybersécurité et Cloud de Holali David GAVI — Partie 4/6.

4.1 Modèle Zero Trust et périmètre logiciel

Le modèle de sécurité traditionnel repose sur la notion de périmètre : un firewall sépare le réseau interne (de confiance) du réseau externe (hostile). Tout ce qui se trouve à l’intérieur du périmètre est implicitement autorisé. Ce modèle, qualifié de « castle-and-moat » par Kindervag (2010), s’est révélé inadapté aux architectures cloud-native pour une raison fondamentale : le périmètre n’existe plus.

Dans un cluster Kubernetes, des centaines de Pods communiquent entre eux via un réseau plat (flat network). Un attaquant ayant compromis un seul Pod peut potentiellement atteindre tous les autres services du cluster — c’est le problème du mouvement latéral (lateral movement). Le rapport Mandiant (2023) indique que 67% des intrusions cloud exploitent ce vecteur après la compromission initiale.

Le Zero Trust, formalisé par le NIST dans sa publication SP 800-207 (Rose et al., 2020), repose sur un principe simple : « Never trust, always verify ». Chaque requête, qu’elle provienne de l’intérieur ou de l’extérieur du réseau, doit être authentifiée, autorisée et chiffrée. Les principes fondamentaux sont :

• Vérification explicite — Authentification et autorisation à chaque requête, basées sur l’identité, le contexte (IP, device, heure) et le comportement
• Moindre privilège (Least Privilege) — Chaque composant ne reçoit que les permissions strictement nécessaires, avec accès just-in-time et just-enough
• Hypothèse de brèche (Assume Breach) — Le système est conçu en supposant qu’un attaquant est déjà à l’intérieur. La segmentation, le chiffrement et la détection sont déployés en profondeur

Dans Kubernetes, le Zero Trust se traduit par une combinaison de Service Mesh (Istio, Linkerd) pour le chiffrement mTLS automatique entre services, de Network Policies pour la micro-segmentation réseau, et de RBAC pour le contrôle d’accès granulaire. Le concept de Software-Defined Perimeter (SDP), proposé par la Cloud Security Alliance (2014), matérialise cette approche en créant des périmètres dynamiques autour de chaque workload.

4.2 Gestion des secrets

Les secrets — mots de passe de bases de données, clés API, certificats TLS, tokens d’accès — constituent le maillon le plus critique de la chaîne de sécurité. Le rapport GitGuardian (2024) révèle que plus de 12,8 millions de secrets ont été exposés dans des dépôts publics GitHub en 2023, une augmentation de 28% par rapport à l’année précédente.

Les Secrets natifs de Kubernetes sont encodés en Base64, pas chiffrés. Ils sont stockés en clair dans etcd par défaut. Cette limitation fondamentale nécessite des solutions complémentaires :

HashiCorp Vault — Solution de référence pour la gestion centralisée des secrets (Brikman, 2024). Vault offre le chiffrement at-rest et in-transit, le contrôle d’accès par politiques (ACL), la rotation automatique des secrets, et les secrets dynamiques — des credentials générés à la demande avec une durée de vie limitée (lease). Par exemple, Vault peut générer des credentials PostgreSQL uniques pour chaque Pod, avec révocation automatique à l’expiration du lease. L’intégration Kubernetes se fait via le Vault Agent Injector (sidecar) ou le Vault CSI Provider.

Sealed Secrets (Bitnami) — Permet de stocker des secrets chiffrés dans Git. Un contrôleur Kubernetes détient la clé privée et déchiffre les SealedSecrets en Secrets Kubernetes standard au déploiement. Seul le contrôleur peut déchiffrer — même le développeur qui a chiffré le secret ne peut pas le lire une fois scellé. C’est la solution de référence pour le GitOps (Prodan, 2023).

SOPS (Mozilla) — Chiffre sélectivement les valeurs dans des fichiers YAML/JSON, en laissant les clés en clair pour faciliter les diffs Git. Supporte AWS KMS, GCP KMS, Azure Key Vault et PGP comme backends de chiffrement. Compatible avec Flux et ArgoCD via les plugins de décryptage.

External Secrets Operator (ESO) — Synchronise les secrets depuis des sources externes (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault) vers des Secrets Kubernetes natifs. L’opérateur interroge périodiquement la source et met à jour le Secret Kubernetes, garantissant la cohérence sans intervention manuelle.

4.3 RBAC et Network Policies dans Kubernetes

Le Role-Based Access Control (RBAC) de Kubernetes, stabilisé depuis la version 1.8, implémente un modèle d’autorisation granulaire basé sur quatre objets (Kubernetes Documentation, 2024) :

• Role — Définit un ensemble de permissions (verbs: get, list, watch, create, update, delete) sur des ressources (pods, services, deployments) dans un namespace spécifique
• ClusterRole — Comme un Role, mais applicable à l’ensemble du cluster (ressources non namespacées comme les nodes, les PersistentVolumes)
• RoleBinding — Associe un Role à un sujet (user, group, ServiceAccount) dans un namespace
• ClusterRoleBinding — Associe un ClusterRole à un sujet pour l’ensemble du cluster

Le principe de moindre privilège impose que chaque ServiceAccount ne dispose que des permissions strictement nécessaires. La pratique recommandée par le CIS Kubernetes Benchmark (Center for Internet Security, 2024) est de désactiver l’auto-montage du token ServiceAccount (automountServiceAccountToken: false) et de créer des ServiceAccounts dédiés pour chaque workload, plutôt que d’utiliser le ServiceAccount default.

Les Network Policies, implémentées par le CNI (Calico, Cilium, Weave Net), définissent des règles de firewall au niveau des Pods. Par défaut, Kubernetes autorise toute communication entre Pods — un modèle « allow all » dangereux. Une Network Policy de type default-deny bloque tout trafic non explicitement autorisé :

Cilium, basé sur eBPF, étend les Network Policies avec des capacités L7 (HTTP, gRPC, Kafka) : il est possible de restreindre un Pod à n’accéder qu’aux méthodes GET sur un chemin spécifique d’un autre service. Cette granularité, impossible avec les Network Policies standard (L3/L4), renforce considérablement la posture de sécurité (Isovalent, 2024).

4.4 Sécurité de la supply chain logicielle

Les attaques de supply chain ciblent les composants logiciels en amont de l’application : dépendances, images de base, outils de build, pipelines CI/CD. L’attaque SolarWinds (2020) et la vulnérabilité Log4Shell (2021) ont démontré l’impact catastrophique de ces vecteurs. L’Executive Order 14028 du gouvernement américain (2021) a imposé la production de SBOM (Software Bill of Materials) pour tout logiciel fourni au gouvernement fédéral.

Le framework SLSA (Supply-chain Levels for Software Artifacts), développé par Google, définit quatre niveaux de maturité pour sécuriser la chaîne de production logicielle :

• SLSA 1 — Documentation du processus de build
• SLSA 2 — Build automatisé avec traçabilité (provenance)
• SLSA 3 — Build sur infrastructure durcie, vérification de la source
• SLSA 4 — Revue à deux personnes, build hermétique et reproductible

Sigstore (Linux Foundation) fournit une infrastructure de signature cryptographique gratuite pour les artefacts logiciels. Cosign signe les images de conteneurs, Rekor fournit un log de transparence immuable, et Fulcio émet des certificats éphémères basés sur l’identité OIDC. Depuis Kubernetes 1.26, la vérification de signature des images peut être imposée via des admission controllers (Kyverno, OPA/Gatekeeper) (Lorenc & Meadows, 2022).

Les SBOM, générés au format SPDX ou CycloneDX, inventorient exhaustivement les composants d’un logiciel (bibliothèques, versions, licences). Des outils comme Syft (Anchore) génèrent automatiquement les SBOM à partir des images de conteneurs, tandis que Grype les analyse pour détecter les vulnérabilités connues (CVE).

4.5 Scanning de vulnérabilités et conformité

Le scanning de vulnérabilités dans un environnement cloud-native opère à plusieurs niveaux, chacun couvert par des outils spécialisés :

Scanning d’images de conteneurs — Trivy (Aqua Security), outil open source le plus adopté, analyse les images Docker, les fichiers IaC (Terraform, CloudFormation), les configurations Kubernetes et les systèmes de fichiers. Il détecte les CVE dans les packages OS et les dépendances applicatives (npm, pip, Maven). Docker Scout offre une analyse continue : les images déjà déployées sont réévaluées quand de nouvelles CVE sont publiées.

Conformité de la configuration Kubernetes — OPA (Open Policy Agent) avec Gatekeeper implémente le pattern « Policy as Code » : les politiques de sécurité sont définies en langage Rego et appliquées comme admission controllers. Exemples de politiques courantes : interdire les conteneurs en mode privileged, exiger des resource limits, bloquer les images provenant de registres non approuvés, imposer des labels obligatoires (OPA Documentation, 2024).

Kyverno, alternative à OPA native Kubernetes, utilise des politiques écrites en YAML plutôt qu’en Rego, réduisant la courbe d’apprentissage. Kyverno peut valider, muter et générer des ressources Kubernetes. Par exemple, une politique peut automatiquement ajouter un label team à tout Deployment qui en est dépourvu.

Runtime security — Falco (Sysdig, CNCF) détecte les comportements anormaux au runtime en analysant les appels système (syscalls) via eBPF. Exemples de détections : exécution d’un shell dans un conteneur, lecture de fichiers sensibles (/etc/shadow), connexion réseau sortante inattendue. Les alertes Falco alimentent les systèmes de réponse automatique (SOAR) ou les SIEM pour corrélation (Sysdig, 2024).

4.6 Audit et traçabilité

L’audit trail constitue un pilier de la gouvernance de sécurité et une exigence réglementaire (ISO 27001:2022, SOC 2 Type II, RGPD). Dans Kubernetes, l’audit opère à plusieurs niveaux :

Kubernetes Audit Logs — L’API server enregistre chaque requête API avec les métadonnées (utilisateur, verb, ressource, timestamp, résultat). Quatre niveaux de verbosité sont disponibles : None, Metadata, Request, RequestResponse. La politique d’audit (audit policy) définit quels événements sont enregistrés et à quel niveau de détail. Les logs sont exportés vers un backend de stockage (Elasticsearch, Loki, Cloud Logging) pour analyse et rétention (Kubernetes Documentation, 2024).

Git comme journal d’audit — Dans une approche GitOps, chaque changement d’infrastructure ou de configuration est un commit Git avec auteur, timestamp, message et diff. Ce log immuable (protégé par signature GPG/SSH) constitue un audit trail naturel répondant aux exigences de traçabilité. Les Pull Requests ajoutent une couche de revue et d’approbation documentée (Limoncelli et al., 2020).

Cloud Trail / Activity Logs — Les fournisseurs cloud (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) enregistrent toutes les actions sur les ressources cloud. La corrélation entre les logs Kubernetes et les logs cloud permet de reconstituer la chaîne complète d’événements lors d’un incident — depuis l’action utilisateur jusqu’à l’impact sur l’infrastructure.

La rétention des logs d’audit doit respecter les exigences réglementaires : 1 an minimum pour SOC 2, 3 à 5 ans pour certaines réglementations financières (PCI DSS). L’utilisation de stockage objet (S3, GCS) avec des politiques de lifecycle (transition vers cold storage, puis suppression) optimise les coûts tout en garantissant la conformité.

Références

• Brikman, Y. (2024). Terraform: Up & Running, 3rd Edition. O’Reilly Media.
• Center for Internet Security (2024). CIS Kubernetes Benchmark v1.9. cisecurity.org.
• Cloud Security Alliance (2014). « Software Defined Perimeter ». cloudsecurityalliance.org.
• GitGuardian (2024). State of Secrets Sprawl 2024. gitguardian.com.
• Isovalent (2024). « Cilium Network Policies ». docs.cilium.io.
• Kindervag, J. (2010). « No More Chewy Centers: Introducing the Zero Trust Model ». Forrester Research.
• Kubernetes Documentation (2024). « RBAC Authorization » et « Network Policies ». kubernetes.io.
• Limoncelli, T. A., Chalup, S. R. & Hogan, C. J. (2020). The Practice of Cloud System Administration, 2nd Edition. Addison-Wesley.
• Lorenc, D. & Meadows, S. (2022). « Sigstore: Software Signing for Everybody ». sigstore.dev.
• Mandiant (2023). M-Trends 2023 — Special Report. mandiant.com.
• OPA Documentation (2024). « Policy Language — Rego ». openpolicyagent.org.
• Prodan, S. (2023). « Sealed Secrets for Kubernetes ». fluxcd.io.
• Rose, S., Borchert, O., Mitchell, S. & Connelly, S. (2020). « Zero Trust Architecture ». NIST SP 800-207.
• Sysdig (2024). « Runtime Security with Falco ». sysdig.com.