Sécurité Kubernetes

Un cluster Kubernetes installé avec ses réglages par défaut est ouvert : tout pod parle à tout pod, l'API server expose une surface large, et une seule autorisation mal posée suffit à donner les clés du control plane. Sécuriser Kubernetes n'est pas un produit qu'on achète, c'est une discipline qui se déroule sur tout le cycle de vie. Ce guide traduit chaque mesure technique en risque, coût et délai, pour que DSI, RSSI et dirigeants décident en connaissance de cause.

Qu'est-ce que la sécurité Kubernetes et pourquoi elle est critique

La sécurité Kubernetes désigne l'ensemble des contrôles techniques et organisationnels qui protègent un cluster (son plan de contrôle, ses nœuds, ses charges applicatives conteneurisées et les données qu'elles manipulent) contre l'accès non autorisé, la compromission et la fuite d'information. Elle couvre la configuration du cluster, la maîtrise des identités, l'isolation réseau, la chaîne d'approvisionnement des images et la détection à l'exécution.

Trois caractéristiques rendent ce sujet plus exigeant qu'une infrastructure classique.

Une surface d'attaque distribuée. Kubernetes orchestre des dizaines à des milliers de conteneurs éphémères répartis sur plusieurs nœuds, joignables par un réseau interne souvent plat. Chaque pod, chaque ServiceAccount, chaque secret, chaque point d'entrée d'API devient une cible potentielle. Là où un serveur monolithique présentait une poignée de portes, un cluster en présente des centaines, qui apparaissent et disparaissent au fil des déploiements.

Une configuration par défaut permissive. Kubernetes a été conçu pour fonctionner, pas pour être verrouillé. Par défaut : aucune Network Policy (donc trafic est-ouest totalement libre), des conteneurs qui peuvent tourner en root, des ServiceAccounts montés automatiquement dans chaque pod, et un standard de sécurité de pod minimal. La sécurité est opt-in : ce qui n'est pas explicitement restreint est autorisé.

Un rythme de changement élevé. Avec le GitOps et le CI/CD, des dizaines de déploiements par jour modifient en continu ce qui tourne dans le cluster. Une posture sécurisée le lundi peut dériver le vendredi. La sécurité Kubernetes est donc autant une affaire d'automatisation et de garde-fous que de configuration initiale.

En clair pour un comité de direction : Kubernetes ne tombe pas en panne « tout seul » pour cause de sécurité. Il s'ouvre tout seul, par défaut. Le travail de durcissement consiste à refermer méthodiquement ce qui est ouvert, sans casser les applications.

Cette page fait partie de notre pilier sécurisation d'infrastructure cloud. Elle s'articule avec nos approches de la conformité cloud (RGPD, ISO, HDS) et du DevSecOps cloud.

Le modèle des 4C : sécuriser sur tout le cycle de vie

Le modèle des 4C est la colonne vertébrale de toute stratégie Kubernetes. Il représente quatre couches concentriques, chacune reposant sur la précédente : on ne peut pas sécuriser une couche si celle qui la porte est faible.

| Couche | Périmètre | Exemples de contrôles | |---|---|---| | Cloud (ou data center) | Le socle d'hébergement : réseau, IAM du fournisseur, comptes, VPC/VNet | Cloisonnement réseau, IAM du fournisseur, chiffrement géré, journalisation du plan cloud | | Cluster | Le plan de contrôle et la configuration Kubernetes | RBAC, Network Policies, Pod Security, admission control, chiffrement etcd | | Conteneur | L'image et son exécution | Scan de vulnérabilités, images minimales, runAsNonRoot, Seccomp/AppArmor | | Code | L'application elle-même | Dépendances saines, gestion des secrets applicatifs, validation des entrées, mTLS |

La logique est imparable : un code parfait dans une image durcie ne sert à rien si le cluster autorise n'importe quel pod à lire tous les secrets ; et un cluster verrouillé ne protège pas si le compte cloud sous-jacent est compromis par une clé IAM exposée.

À ces quatre couches s'ajoute la dimension temporelle du cycle de vie, qui se découpe en trois phases :

• Build : ce qui se passe avant le déploiement, scan d'images, signature, génération de SBOM, contrôles dans la chaîne CI/CD.
• Deploy : le moment où une charge entre dans le cluster, admission control, validation des politiques (policy-as-code), application des standards de sécurité de pod.
• Runtime : la vie de la charge dans le cluster, détection comportementale, isolation réseau, audit, réponse à incident.

Une stratégie qui ne traite que le runtime (en achetant un outil de détection) laisse passer les vulnérabilités à la construction ; une stratégie qui ne traite que le build (scanner les images) ne voit pas une intrusion en cours. La maturité consiste à couvrir les trois phases.

Architecture Kubernetes : les composants à sécuriser

Pour décider où investir, il faut connaître l'anatomie d'un cluster. Kubernetes se divise en plan de contrôle (control plane) et nœuds de travail (worker nodes).

Le plan de contrôle

C'est le cerveau du cluster. Sa compromission équivaut à la prise de contrôle totale.

• kube-apiserver : le point d'entrée unique de toute opération. Toute commande kubectl, tout contrôleur, tout composant passe par lui. Il doit être protégé par TLS, une authentification forte, l'autorisation RBAC et l'audit logging. Une API server exposée publiquement sans contrôle d'accès est l'une des fautes les plus graves et les plus fréquentes.
• etcd : la base de données clé-valeur qui contient tout l'état du cluster, y compris les Secrets en clair si le chiffrement at-rest n'est pas activé. Un accès direct à etcd contourne entièrement le RBAC. Il doit être chiffré au repos, isolé sur le réseau et accessible uniquement par l'API server via TLS mutuel.
• kube-scheduler : décide sur quel nœud placer chaque pod. Compromis, il peut orienter des charges vers des nœuds contrôlés par un attaquant.
• kube-controller-manager : exécute les boucles de réconciliation (réplicas, ServiceAccounts, tokens). Il détient des privilèges élevés et doit être protégé en conséquence.

Les nœuds de travail

Ils exécutent les charges applicatives.

• kubelet : l'agent présent sur chaque nœud qui pilote les conteneurs. Son API, si elle autorise l'accès anonyme ou non chiffré, permet d'exécuter des commandes dans les pods et de lire des logs, un vecteur d'attaque classique. Elle doit exiger authentification et autorisation.
• kube-proxy et le runtime de conteneurs (containerd, CRI-O) complètent la chaîne et doivent être tenus à jour.

Dans un cluster managé (EKS, AKS, GKE), le fournisseur opère et durcit le plan de contrôle pour vous, c'est précisément l'objet du modèle de responsabilité partagée détaillé plus bas. Dans un cluster auto-hébergé, etcd, l'API server et le kubelet sont votre responsabilité pleine et entière.

Les cinq piliers techniques de la sécurité d'un cluster

Pilier 1 : RBAC et le principe du moindre privilège

Le RBAC (Role-Based Access Control) gouverne qui peut faire quoi dans le cluster. C'est la première ligne de défense contre l'escalade de privilèges et le mouvement latéral. Quatre objets le composent :

• Role : un ensemble d'autorisations (verbes × ressources) valable dans un namespace.
• ClusterRole : le même principe, mais à l'échelle de tout le cluster.
• RoleBinding : associe un Role (ou un ClusterRole) à des sujets (utilisateurs, groupes, ServiceAccounts) dans un namespace.
• ClusterRoleBinding : associe un ClusterRole à des sujets sur l'ensemble du cluster.

Les ServiceAccounts sont les identités des charges applicatives elles-mêmes. Par défaut, un pod reçoit le ServiceAccount default de son namespace, dont le token est monté automatiquement. Si ce ServiceAccount est trop permissif, tout pod compromis hérite de ses droits.

Le principe du moindre privilège (PoLP) consiste à n'accorder que les autorisations strictement nécessaires. Trois verbes sont particulièrement dangereux et doivent être audités spécifiquement :

• escalate : permet de créer un Role plus puissant que ses propres droits, une porte ouverte à l'auto-promotion.
• bind : permet de lier un Role existant à un sujet, donc d'accorder des droits à autrui.
• impersonate : permet d'agir au nom d'un autre utilisateur, groupe ou ServiceAccount, contournement total de l'identité.

Un Role minimal, lisible et déployable ressemble à ceci :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: prod-paiement
  name: lecture-pods
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]   # aucun create/delete/exec

Lecture décisionnelle. Ce Role n'accorde que la lecture des pods et de leurs logs, dans un seul namespace. Pas d'exec, pas de suppression, pas d'accès aux secrets. Pour un DSI, la règle de gouvernance à retenir est simple : interdire par défaut les ClusterRoleBindings vers cluster-admin, désactiver le montage automatique du token (automountServiceAccountToken: false) là où le pod n'appelle pas l'API, et auditer trimestriellement les verbes dangereux. Ces décisions s'inscrivent dans une démarche plus large de gouvernance cloud.

Pilier 2 : Network Policies et l'isolation pod-à-pod

Par défaut, tout pod peut joindre tout autre pod, dans n'importe quel namespace. C'est le défaut le plus dangereux de Kubernetes : un pod compromis peut alors balayer le réseau interne et se déplacer latéralement sans entrave.

Les Network Policies sont l'incarnation Kubernetes de la microsegmentation à l'échelle des pods. La bonne pratique fondatrice est le default deny-all : on bloque tout le trafic, puis on n'autorise que les flux légitimes. C'est l'application concrète, au niveau du cluster, du principe Zero Trust : le principe général de Zero Trust et de segmentation réseau cloud (au-delà du seul cluster) est traité dans notre pilier sécurisation d'infrastructure cloud ; cette page se concentre sur sa traduction en objets Kubernetes. Une politique de refus par défaut sur ingress et egress :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: prod-paiement
spec:
  podSelector: {}            # s'applique à tous les pods du namespace
  policyTypes:
    - Ingress
    - Egress                 # bloque aussi les sorties (exfiltration)

Lecture décisionnelle. Cette politique seule coupe tout trafic ; il faut ensuite ajouter des politiques d'autorisation ciblées (par exemple : le pod frontend peut joindre le pod api sur le port 8080, et rien d'autre). Bloquer l'egress est souvent négligé alors qu'il limite l'exfiltration de données et l'appel vers des serveurs de commande externes.

Point d'attention majeur : Kubernetes ne fait pas respecter les Network Policies tout seul. Cette application dépend du CNI (Container Network Interface) installé. Les principaux :

• Calico : performant, riche en politiques (y compris au-delà de la spec native), très répandu.
• Cilium : fondé sur eBPF, offre visibilité fine, politiques de niveau 7 (HTTP) et de bonnes performances ; de plus en plus le choix par défaut sur les déploiements exigeants.
• Flannel : simple, mais ne fait pas respecter les Network Policies seul, un piège classique.
• WeaveNet : historiquement courant, dont le support a évolué ; à vérifier selon la version.

Choisir un CNI qui n'applique pas les politiques, c'est croire isoler son réseau alors qu'il reste plat.

Pilier 3 (Pod Security) : standards, admission et SecurityContext

Cette couche encadre ce qu'un pod a le droit de faire au niveau du système. Un changement structurant doit être connu de toute équipe : les Pod Security Policies (PSP) ont été dépréciées en v1.21 et supprimées en v1.25 de Kubernetes. Elles ne reviendront pas. Leur remplacement standard est le Pod Security Admission (PSA), qui applique les Pod Security Standards (PSS).

Les Pod Security Standards définissent trois niveaux :

• Privileged : sans restriction (à réserver à des charges système).
• Baseline : interdit les configurations notoirement dangereuses (conteneurs privilégiés, hostNetwork, etc.), tout en restant compatible avec la plupart des applications.
• Restricted : le plus strict, aligné sur les bonnes pratiques de durcissement (runAsNonRoot obligatoire, capacités Linux réduites, profil Seccomp imposé).

Le PSA s'active simplement par des labels sur le namespace, avec trois modes (enforce, audit, warn) :

apiVersion: v1
kind: Namespace
metadata:
  name: prod-paiement
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Au niveau du pod, le SecurityContext durcit l'exécution :

securityContext:
  runAsNonRoot: true            # interdit l'exécution en root
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true  # système de fichiers en lecture seule
  capabilities:
    drop: ["ALL"]               # retire toutes les capacités Linux
  seccompProfile:
    type: RuntimeDefault        # filtre les appels système dangereux

Lecture décisionnelle. Le PSA natif est simple mais grossier (trois niveaux). Pour des règles plus fines ou des exceptions maîtrisées, on passe à l'admission control programmable (pilier 5). La roadmap réaliste consiste à appliquer baseline partout en enforce, puis à viser restricted sur les namespaces sensibles, en commençant par le mode audit/warn pour mesurer l'impact avant de bloquer.

Pilier 4 : Gestion des secrets et chiffrement d'etcd

Les Secrets Kubernetes ne sont, par défaut, pas chiffrés : ils sont encodés en base64 (ce qui n'est pas du chiffrement) et stockés dans etcd. Quiconque accède à etcd ou dispose des droits de lecture des secrets les récupère en clair.

Trois mesures s'imposent, par ordre de priorité :

1. Chiffrement at-rest d'etcd. Activer le chiffrement des Secrets dans etcd via un EncryptionConfiguration (idéalement adossé à un KMS du fournisseur cloud, qui gère les clés et leur rotation). C'est le minimum vital.
2. RBAC strict sur les secrets. Restreindre le verbe get/list sur la ressource secrets aux seuls ServiceAccounts qui en ont besoin.
3. Externalisation des secrets. Sortir les secrets sensibles de Kubernetes vers un coffre dédié, HashiCorp Vault ou un secrets manager cloud (AWS Secrets Manager, Azure Key Vault), avec injection à l'exécution et rotation automatique. Le secret n'est alors jamais stocké durablement dans le cluster.

Pour un RSSI : la question n'est pas seulement « les secrets sont-ils chiffrés ? » mais « combien de temps un secret reste-t-il valide, et qui peut le lire ? ». La rotation et la traçabilité comptent autant que le chiffrement. Ces exigences rejoignent directement les obligations de la conformité cloud.

Pilier 5 : Admission control et policy-as-code

L'admission control intercepte chaque requête à l'API server avant qu'elle ne soit persistée, après authentification et autorisation. Deux familles :

• Validating admission controllers : acceptent ou refusent une requête (ex. : « refuser tout pod tournant en root »).
• Mutating admission controllers : modifient la requête (ex. : « ajouter automatiquement un label de sécurité »).

C'est le levier du policy-as-code : des règles de sécurité versionnées, testables et appliquées automatiquement. Deux moteurs dominent :

• OPA Gatekeeper : fondé sur Open Policy Agent et le langage Rego. Puissant et générique, mais Rego a une courbe d'apprentissage.
• Kyverno : politiques écrites en YAML (pas de nouveau langage), pensé spécifiquement pour Kubernetes. Plus accessible aux équipes plateforme.

Exemple Kyverno qui interdit les conteneurs privilégiés :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: interdire-conteneurs-privilegies
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-privileged
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Les conteneurs privilégiés sont interdits."
        pattern:
          spec:
            containers:
              - =(securityContext):
                  =(privileged): "false"

Lecture décisionnelle. Le policy-as-code transforme la sécurité d'un contrôle ponctuel en garde-fou permanent : impossible de déployer une charge non conforme, même par erreur. Pour une équipe qui débute, Kyverno offre l'un des meilleurs rapports effort/résultat. Cette logique se prolonge dans une démarche DevSecOps cloud où les politiques sont validées dès le pipeline.

Supply chain, images et sécurité à l'exécution

Du build au cluster : ce que Kubernetes contrôle à l'admission

Une part importante des compromissions n'exploite pas le cluster mais ce qu'on y déploie. La construction sécurisée des images en amont, scan de vulnérabilités bloquant (Trivy, Clair), génération de SBOM, niveaux de provenance SLSA, signature cosign/Sigstore dans le pipeline, relève de l'industrialisation du pipeline CI/CD : elle est détaillée dans notre approche du DevSecOps cloud, qui en est le propriétaire.

Ce qui appartient en propre à la sécurité Kubernetes, c'est la façon dont le cluster ferme la boucle à l'admission :

• Images minimales et durcies : exiger des images distroless ou minimales (sans shell ni outils superflus) réduit la surface d'attaque et le nombre de CVE exécutées dans vos pods. Une politique d'admission peut rejeter toute image non conforme.
• Vérification de signature à l'admission : via un contrôleur d'admission (Kyverno verifyImages ou Sigstore policy-controller), le cluster n'accepte que les images signées par une clé de confiance et refuse les images altérées ou substituées, c'est le maillon Kubernetes de la chaîne de confiance, indépendant du build.
• Provenance vérifiée au déploiement : l'admission control peut contraindre l'origine des images (registre approuvé, attestation SLSA présente), de sorte que seul ce qui sort de votre pipeline de confiance entre en production.

Détection à l'exécution, audit et monitoring

Aucune prévention n'est parfaite. La détection runtime repère ce qui a franchi les barrières.

• Audit logs de l'API : Kubernetes peut journaliser chaque requête à l'API server (qui, quoi, quand, résultat). C'est la source de vérité forensique. La politique d'audit et la rétention des logs sont des décisions de conformité, pas seulement techniques.
• Falco : le standard open source de détection comportementale au runtime (CNCF). Il alerte sur des comportements suspects : un shell ouvert dans un conteneur de production, une lecture de fichier sensible, une connexion réseau inattendue.
• eBPF / Tetragon : observabilité profonde du noyau avec un faible surcoût, pour une détection fine et de l'application de politiques runtime.
• Sysdig : solution commerciale couvrant détection, conformité et investigation.

Le couplage audit logs (qui a fait quoi) + détection runtime (qu'est-ce qui se passe d'anormal) est la base d'une capacité de réponse à incident, traitée plus loin. La supervision continue relève de notre infogérance cloud entreprise.

Menaces et vecteurs d'attaque réels

Comprendre comment un attaquant procède oriente les priorités. Voici les vecteurs les plus exploités, cartographiés par le référentiel MITRE ATT&CK for Kubernetes et l'OWASP.

| Vecteur | Mécanisme | Contre-mesure principale | |---|---|---| | Misconfigurations | Réglages par défaut permissifs (RBAC large, pas de Network Policy, pod en root) | Hardening CIS, PSA, policy-as-code | | Escalade de privilèges | Abus des verbes escalate/bind, ServiceAccount trop puissant | RBAC moindre privilège, audit des verbes dangereux | | Container escape | Évasion du conteneur vers le nœud hôte (conteneur privilégié, faille noyau) | runAsNonRoot, Seccomp, isolation forte (gVisor/Kata) | | Mouvement latéral | Déplacement de pod en pod sur un réseau plat | Network Policies default-deny, microsegmentation | | API server exposée | API joignable sans contrôle d'accès suffisant | TLS, authentification forte, RBAC, restriction réseau | | Attaque des métadonnées cloud | Pod appelant 169.254.169.254 pour voler des credentials IAM du nœud | Restreindre l'accès au service de métadonnées, IAM par pod (IRSA / Workload Identity) |

Le dernier vecteur mérite une insistance particulière. Le service de métadonnées de l'instance (l'adresse 169.254.169.254) expose, sur un nœud mal configuré, les credentials IAM rattachés à la machine. Un pod compromis qui interroge cette adresse peut hériter des droits cloud du nœud entier, souvent bien plus larges que ce dont l'application a besoin. La parade : forcer l'identité au niveau du pod (IRSA sur AWS, Workload Identity sur Azure et GKE) et bloquer l'accès direct au service de métadonnées depuis les charges applicatives.

La logique de l'attaquant est toujours la même : entrer par un point faible (image vulnérable, API exposée), puis monter en privilèges et se déplacer latéralement. Chaque pilier de ce guide casse un maillon de cette chaîne. La défense en profondeur fonctionne précisément parce qu'aucune barrière isolée n'est suffisante.

Hardening et audit : CIS Benchmark et outils

Le CIS Kubernetes Benchmark est le référentiel de durcissement de référence : une liste détaillée et consensuelle de réglages recommandés pour le plan de contrôle, etcd, le kubelet et les politiques. C'est la base objective d'un audit de configuration.

Plusieurs outils automatisent cette évaluation :

• kube-bench : vérifie la conformité d'un cluster au CIS Benchmark, contrôle par contrôle.
• kube-hunter : adopte le point de vue de l'attaquant et recherche activement les faiblesses exploitables.
• Kubescape : scanne le cluster contre plusieurs référentiels (CIS, NSA/CISA, MITRE) et fournit un score de posture.
• Polaris : audite les bonnes pratiques de configuration des charges (limites de ressources, SecurityContext, sondes).

Au-delà des outils ponctuels, le KSPM (Kubernetes Security Posture Management) est la brique spécifiquement Kubernetes : il consolide en continu la posture de vos clusters (dérive RBAC, Network Policies manquantes, charges non conformes au CIS) et devient indispensable au-delà de quelques clusters. Le KSPM s'intègre généralement dans une plateforme CNAPP plus large. La taxonomie complète CSPM / CWPP / CASB / CNAPP / CIEM et le choix d'outillage de posture sont définis dans notre pilier sécurisation d'infrastructure cloud. Ces audits s'inscrivent dans une démarche plus large d'audit infrastructure cloud.

Conformité réglementaire française et européenne

C'est ici que la sécurité Kubernetes cesse d'être un sujet d'ingénieur pour devenir un sujet de direction. Cette page ne redéfinit pas les cadres réglementaires : les définitions complètes de l'ANSSI, de NIS2, de DORA, du RGPD (art. 28/32), de l'ISO 27001 et de la HDS, ainsi que la matrice de conformité auditable et la roadmap par phases, sont détaillées dans notre page dédiée à la conformité cloud (RGPD, ISO, HDS). Ce qui relève en propre de cette page, c'est une seule question opérationnelle : quel contrôle technique du cluster sert de preuve à quelle exigence ?

C'est l'angle le plus utile pour un RSSI, car les mesures de durcissement décrites plus haut produisent, sans double travail, les éléments de preuve attendus par les auditeurs.

| Exigence (cadre) | Contrôle Kubernetes qui en fait la preuve | |---|---| | Gestion des risques documentée (NIS2) | Audit logging de l'API, hardening CIS mesuré (kube-bench/Kubescape), policy-as-code versionné | | Durcissement & conteneurisation (ANSSI, BP-28) | SecurityContext restricted, Pod Security Admission, images minimales, isolation runtime | | Résilience opérationnelle & réversibilité (DORA) | PRA/PCA avec RTO/RPO définis, GitOps comme source de vérité, manifestes versionnés dans vos dépôts | | Minimisation des accès & traçabilité (RGPD art. 32) | RBAC au moindre privilège, chiffrement etcd, audit logs conservés | | Sécurité du sous-traitant (RGPD art. 28) | Matrice de responsabilité partagée formalisée par fournisseur | | Données de santé (HDS) | Déploiement chez un partenaire certifié HDS + isolation/chiffrement/accès maîtrisés côté cluster |

Deux points appellent une vigilance particulière. Pour la HDS, la réassurance est simple : Architecte Cloud oriente vers des architectures Kubernetes déployées chez un partenaire certifié HDS. Le mécanisme de certification, qui vise l'hébergeur et non votre configuration, est expliqué côté conformité cloud (RGPD, ISO, HDS), avec l'accompagnement dédié du secteur de la santé. Pour DORA, l'exigence de réversibilité (stratégie de sortie crédible vis-à-vis du fournisseur cloud) concerne directement nos clients du secteur financier et se traduit, côté cluster, par des manifestes portables et une indépendance d'outillage.

Enfin, Architecte Cloud inscrit ses missions dans une démarche ISO 27001, en veillant à ce que les prestataires alignent les contrôles techniques Kubernetes sur des objectifs de sécurité documentés.

Pour une direction générale : la conformité n'est pas une couche qu'on ajoute après. Le RBAC, le chiffrement et l'audit logging sont simultanément des mesures de sécurité et des preuves de conformité. Bien menés, ils servent les deux objectifs sans double travail.

Clusters managés : EKS, AKS, GKE et responsabilité partagée

La majorité des clusters en production reposent sur des services managés. Comprendre qui sécurise quoi est la décision de cadrage la plus importante, et la plus souvent négligée.

La matrice de responsabilité partagée

Dans un cluster managé, le fournisseur opère et durcit le plan de contrôle (API server, etcd, scheduler), mais vous restez responsable de tout ce que vous déployez et configurez. Voici la répartition, exploitable par un DSI :

| Élément | Cluster managé (EKS/AKS/GKE) | Cluster auto-hébergé | |---|---|---| | Plan de contrôle (API server, scheduler) | Fournisseur | Vous | | etcd (patch, disponibilité) | Fournisseur | Vous | | Chiffrement at-rest d'etcd | Vous l'activez (KMS) | Vous | | Système d'exploitation des nœuds | Partagé (vous patchez selon le mode) | Vous | | RBAC et configuration cluster | Vous | Vous | | Network Policies / CNI | Vous | Vous | | Pod Security / SecurityContext | Vous | Vous | | Gestion des secrets applicatifs | Vous | Vous | | Images et code applicatif | Vous | Vous | | Configuration IAM cloud | Vous | Vous |

La leçon : le managé vous décharge de l'exploitation du plan de contrôle, pas de la sécurité applicative et de la configuration. La grande majorité des incidents relèvent de la part « Vous » du tableau.

Comparatif de sécurité par défaut

Les trois grands fournisseurs diffèrent sur des points concrets, notamment le mapping d'identité entre les pods et l'IAM cloud (le mécanisme qui remplace le vol de credentials via les métadonnées) :

| Critère | Amazon EKS | Azure AKS | Google GKE | |---|---|---|---| | Identité pod → IAM cloud | IRSA (IAM Roles for Service Accounts) / EKS Pod Identity | Microsoft Entra ID Workload Identity | GKE Workload Identity | | Chiffrement etcd des secrets | Via KMS (à activer) | Géré par la plateforme + option KMS | Géré, option avec Cloud KMS | | CNI / Network Policy | VPC CNI ; politiques via Calico/Cilium | Azure CNI ; Network Policy (Calico/Cilium) | CNI natif ; Network Policy intégrée | | Posture & détection intégrée | Outils AWS + écosystème | Microsoft Defender for Cloud + Azure Policy | Security Posture / écosystème Google | | Gouvernance multi-comptes | AWS Control Tower | Management groups + Azure Policy | Organisation / policies |

Lecture décisionnelle. Aucun fournisseur n'est « plus sûr » dans l'absolu : la sécurité dépend de votre configuration de la part « Vous ». Le bon choix se fait selon votre écosystème existant, vos compétences internes et vos contraintes de conformité, un arbitrage que nous menons sans parti pris dans nos missions d'architecte Azure et d'architecture AWS, conformément à notre principe d'indépendance.

Modèle de maturité et roadmap de sécurisation 0→90 jours

Sécuriser un cluster ne se fait pas en un sprint. Voici un modèle de maturité en cinq niveaux, avec une séquence de mise en œuvre priorisée par les quick-wins à plus fort impact.

• Niveau 0 (Défaut) : cluster managé installé, réglages par défaut. Réseau plat, pas de Network Policy, RBAC large. Posture critique.
• Niveau 1 (Hygiène de base) : RBAC moindre privilège, chiffrement etcd activé, PSA baseline, scan d'images dans le CI.
• Niveau 2 (Isolation) : Network Policies default-deny, namespaces cloisonnés, secrets externalisés, audit logging activé.
• Niveau 3 (Automatisation) : policy-as-code (Kyverno/OPA), signature d'images, détection runtime (Falco), conformité CIS mesurée en continu.
• Niveau 4 (Résilience) : isolation forte multitenant, plan de réponse à incident testé, PRA/PCA validés, posture KSPM consolidée et réversibilité documentée.

Une séquence réaliste sur trois mois :

| Période | Actions prioritaires | Bénéfice | |---|---|---| | Jours 0–30 | Audit CIS (kube-bench/Kubescape), chiffrement etcd, désactivation des ServiceAccounts trop permissifs, scan d'images bloquant | Élimination des fautes critiques | | Jours 30–60 | Network Policies default-deny par namespace, PSA baseline→restricted, externalisation des secrets, activation des audit logs | Fin du réseau plat, traçabilité | | Jours 60–90 | Kyverno/OPA en enforce, Falco, signature d'images, plan de réponse à incident, revue de la posture | Sécurité automatisée et durable |

Les quick-wins des 30 premiers jours (chiffrement etcd, RBAC, scan d'images) sont peu coûteux et neutralisent les vecteurs les plus exploités. Commencer par eux, c'est réduire l'essentiel du risque avant même d'investir dans des outils avancés.

Combien coûte la sécurité Kubernetes ? Durée, budget et livrables

La sécurité Kubernetes a un coût réel, rarement chiffré par les ressources techniques. Le traiter en amont évite les mauvaises surprises et permet un arbitrage FinOps sain.

Les postes de coût à anticiper

• Surcoût d'exécution : un agent de détection runtime comme Falco se déploie en DaemonSet (un pod par nœud), ce qui consomme CPU/mémoire sur chaque nœud. À grande échelle, ce overhead se chiffre.
• Rétention des logs d'audit : les audit logs de l'API et les journaux de détection génèrent un volume important. Leur stockage et leur durée de conservation (souvent dictée par la conformité) constituent un poste récurrent non négligeable.
• Licences d'outils : Trivy, Falco, Kyverno, kube-bench sont open source. Les plateformes CNAPP/KSPM commerciales (Sysdig et équivalents) impliquent des licences à l'usage ou par nœud.
• Coffre à secrets : HashiCorp Vault ou un secrets manager cloud ajoute un coût de service et d'exploitation.
• ETP (équivalents temps plein) : le poste le plus important. Maintenir la posture, traiter les alertes et faire évoluer les politiques demande des compétences plateforme/sécurité dédiées.

L'arbitrage clé pour un DAF : open source ne veut pas dire gratuit. Le coût se déplace de la licence vers l'ingénierie. Externaliser l'exploitation de la sécurité peut s'avérer plus économique que recruter et fidéliser ces compétences rares. C'est une décision qui se chiffre, et qui relève de notre approche d'optimisation des coûts cloud.

Durée, budget et livrables d'une mission de sécurisation

Une mission de durcissement d'un cluster Kubernetes mobilise typiquement 2 à 7 jours selon le périmètre (nombre de clusters, niveau de maturité de départ, contraintes de conformité). Le budget indicatif se situe entre 5 000 et 12 000 €, présenté en fourchette et établi sur devis selon le périmètre. Un cluster de pré-production à durcir et un environnement multi-clusters soumis à HDS ou DORA n'appellent pas le même effort.

Livrables types d'une telle mission :

• Rapport d'audit de posture (CIS Benchmark, RBAC, Network Policies, secrets, images) avec criticité priorisée.
• Manifestes et politiques versionnés dans VOS dépôts (Network Policies default-deny, Roles minimaux, labels PSA, politiques Kyverno).
• Configuration de chiffrement etcd et schéma de gestion des secrets.
• Roadmap de remédiation séquencée (0→90 jours) et matrice de responsabilité partagée propre à votre fournisseur.
• Transfert de compétences et documentation remise, pour votre autonomie.

Lancez votre diagnostic de sécurité Kubernetes ou contactez-nous, réponse sous 48 h ouvrées.

Réponse à incident Kubernetes : l'après-compromission

Presque aucune ressource ne traite ce qui se passe après une intrusion. C'est pourtant ce qui distingue une posture mature. Un plan de réponse à incident Kubernetes doit prévoir :

1. Détection et qualification : l'alerte (Falco, audit logs) déclenche une analyse pour confirmer la compromission et son périmètre.
2. Isolation du pod compromis : appliquer une Network Policy le coupant du reste du cluster, sans nécessairement le supprimer immédiatement (préservation des preuves).
3. Forensics : collecter logs, état du pod, image et empreintes avant toute remédiation destructive.
4. Rotation des secrets : considérer comme compromis tout secret accessible depuis le pod (tokens de ServiceAccount, credentials, clés). Les faire tourner sans délai, d'où l'intérêt d'une externalisation qui facilite la rotation.
5. Remédiation et reconstruction : redéployer depuis une source de confiance (GitOps), pas patcher un pod compromis.
6. PRA/PCA : en cas d'atteinte majeure, activer le plan de reprise/continuité, avec des objectifs RTO (durée de reprise) et RPO (perte de données tolérée) définis à l'avance. La méthode de sauvegarde durcie (règle 3-2-1, sauvegardes immuables résistantes au ransomware) qui sous-tend ces objectifs est traitée dans notre pilier sécurisation d'infrastructure cloud ; côté Kubernetes, la reprise s'appuie sur la reconstruction GitOps depuis une source de confiance et la sauvegarde de l'état du cluster (etcd, objets, volumes persistants via Velero).

La capacité à isoler, investiguer et reconstruire rapidement repose sur des fondations posées avant l'incident : audit logging actif, GitOps comme source de vérité, secrets externalisés et rotables. Pour les organisations sans équipe sécurité 24/7, cette capacité peut être déléguée via une infogérance cloud entreprise.

Multitenancy et isolation forte

Pour les éditeurs SaaS et scale-ups qui hébergent plusieurs clients ou équipes sur une infrastructure partagée, l'isolation est un sujet à part entière. Deux grandes approches :

• Isolation par namespace (soft multitenancy) : plusieurs locataires dans un même cluster, séparés par namespaces, RBAC et Network Policies. Économique, mais l'isolation reste logique : une faille noyau ou une évasion de conteneur peut la traverser.
• Clusters dédiés (hard multitenancy) : un cluster par locataire. Isolation maximale, coût et complexité d'exploitation plus élevés.
• Solutions intermédiaires : vCluster (clusters virtuels au sein d'un cluster physique) ; et pour l'isolation au runtime, les RuntimeClasses s'appuyant sur gVisor ou Kata Containers, qui ajoutent une frontière de sécurité (sandbox ou micro-VM) entre le conteneur et le noyau hôte, une parade efficace contre le container escape.

Le bon niveau d'isolation est un arbitrage entre risque, coût et complexité, dépendant de la sensibilité des données et du modèle commercial. Les éditeurs SaaS y trouvent un enjeu central de confiance client.

Sécurité de la chaîne CI/CD et GitOps

La sécurité du cluster commence en amont, dans le pipeline. L'industrialisation de cette sécurité, security gates bloquants, scan des manifestes, vérification des politiques (Kyverno en mode test) avant le merge, signature des artefacts et contrôle de provenance dans la chaîne, est le cœur du DevSecOps cloud, qui en détient la méthode complète. Cette page ne couvre que les deux points où le pipeline rencontre le cluster.

GitOps comme source de vérité du cluster. Une approche GitOps (avec ArgoCD ou Flux) fait du dépôt Git l'état désiré du cluster : aucun changement manuel via kubectl en production, tout passe par une pull request revue et tracée. Pour Kubernetes, c'est à la fois une mesure de sécurité (auditabilité native, dérive de configuration réduite) et le socle d'une reconstruction propre après incident.

L'admission control ferme la boucle. Quoi qu'il sorte du pipeline, c'est le cluster qui décide ce qu'il accepte : via Kyverno ou un policy-controller, il n'admet que les images signées issues du registre de confiance et conformes aux politiques de sécurité. C'est le dernier rempart, propre à Kubernetes, qui rend inopérante une image compromise même si un maillon amont a échoué.

Réversibilité, autonomie et indépendance

Sécuriser un cluster ne doit pas créer une nouvelle dépendance. C'est un principe que peu d'acteurs assument explicitement. Chez Architecte Cloud :

• Tout est versionné dans VOS dépôts. Les Network Policies, Roles RBAC, politiques Kyverno et configurations de durcissement sont du code Terraform/Bicep et des manifestes YAML qui vous appartiennent. Vous pouvez les relire, les modifier, les rejouer, y compris sans nous.
• Pas d'enfermement propriétaire. Nous privilégions les standards et l'open source (Kyverno, Falco, Trivy, CNI standards) plutôt que des outils qui rendraient votre sécurité captive d'un éditeur. La réversibilité est un objectif de conception, pas une promesse en l'air, et une exigence explicite de DORA pour le secteur financier.
• Gouvernance multi-cloud. Nos pratiques de sécurité s'appliquent sur Azure comme sur AWS, sans imposer un fournisseur. Le conseil reste indépendant.

Cette posture s'incarne dans notre méthode : des prestataires et experts qualifiés, disposant des certifications requises (CISSP, Azure Security Engineer), et une démarche ISO 27001 appliquée aux missions. Nous traduisons chaque mesure technique en coût, risque et délai pour que la décision reste entre vos mains. Notre approche d'intermédiaire indépendant détaille cette méthode.

FAQ : Sécurité Kubernetes

Qu'est-ce que la sécurité Kubernetes ?

C'est l'ensemble des contrôles techniques et organisationnels qui protègent un cluster Kubernetes (son plan de contrôle, ses nœuds, ses conteneurs et ses données) contre l'accès non autorisé et la compromission. Elle s'organise selon le modèle des 4C (Cloud, Cluster, Conteneur, Code) et couvre les trois phases du cycle de vie : build, deploy et runtime.

Comment sécuriser un cluster Kubernetes ?

En appliquant la défense en profondeur sur cinq piliers : RBAC au moindre privilège, Network Policies en default deny-all, Pod Security Standards via Pod Security Admission, gestion chiffrée et externalisée des secrets, et admission control par policy-as-code (Kyverno ou OPA Gatekeeper). On complète par le scan d'images, la détection runtime et un audit régulier contre le CIS Benchmark.

Quels sont les principaux risques de sécurité de Kubernetes ?

Les misconfigurations (réglages par défaut permissifs), l'escalade de privilèges via un RBAC trop large, le container escape vers le nœud hôte, le mouvement latéral sur un réseau plat sans Network Policy, l'exposition de l'API server, et le vol de credentials IAM via le service de métadonnées cloud (169.254.169.254).

Qu'est-ce que le RBAC dans Kubernetes et comment le configurer ?

Le RBAC contrôle qui peut faire quoi via quatre objets : Role et ClusterRole (les autorisations), RoleBinding et ClusterRoleBinding (les associations à des sujets). On le configure au moindre privilège : n'accorder que les verbes et ressources nécessaires, éviter cluster-admin, désactiver le montage automatique des tokens inutiles, et auditer les verbes dangereux (escalate, bind, impersonate).

Que sont les Network Policies et comment les mettre en place ?

Ce sont des règles qui contrôlent le trafic réseau entre pods (ingress et egress). La bonne pratique est de commencer par une politique default deny-all, puis d'autoriser explicitement les seuls flux légitimes. Attention : leur application dépend du CNI installé, Calico ou Cilium les font respecter, Flannel seul non.

Pourquoi les Pod Security Policies ont-elles été supprimées et par quoi les remplacer ?

Les Pod Security Policies (PSP) ont été dépréciées en v1.21 et supprimées en v1.25 de Kubernetes en raison de leur complexité et de leur ergonomie difficile. Elles sont remplacées par le Pod Security Admission (PSA), qui applique les Pod Security Standards (Privileged, Baseline, Restricted) via de simples labels de namespace. Pour des règles plus fines, on utilise Kyverno ou OPA Gatekeeper.

Qu'est-ce que le CIS Kubernetes Benchmark ?

C'est le référentiel de durcissement de référence pour Kubernetes : une liste consensuelle de réglages recommandés pour le plan de contrôle, etcd, le kubelet et les politiques. Des outils comme kube-bench et Kubescape évaluent automatiquement la conformité d'un cluster à ce benchmark.

Quels outils utiliser pour auditer la sécurité d'un cluster Kubernetes ?

kube-bench (conformité CIS), kube-hunter (point de vue attaquant), Kubescape (multi-référentiels avec score de posture), Polaris (bonnes pratiques de configuration), Trivy (scan de vulnérabilités d'images) et Falco (détection runtime). Au-delà de quelques clusters, une plateforme KSPM/CNAPP offre une vue continue consolidée.

Comment gérer les secrets de façon sécurisée dans Kubernetes ?

Les Secrets natifs sont encodés en base64, pas chiffrés. Trois mesures : activer le chiffrement at-rest d'etcd (idéalement via un KMS), restreindre strictement les droits RBAC sur la ressource secrets, et externaliser les secrets sensibles vers HashiCorp Vault ou un secrets manager cloud, avec rotation automatique.

Quelle est la différence de sécurité entre un cluster managé (EKS, AKS, GKE) et auto-hébergé ?

Dans un cluster managé, le fournisseur opère et durcit le plan de contrôle (API server, etcd, scheduler) ; vous restez responsable du RBAC, des Network Policies, du Pod Security, des secrets, des images et de la configuration IAM. En auto-hébergé, tout vous incombe, y compris la sécurité d'etcd et de l'API server. La plupart des incidents relèvent de la part client dans les deux cas.

Qu'est-ce que le modèle de responsabilité partagée pour Kubernetes ?

C'est la répartition des responsabilités de sécurité entre vous et le fournisseur cloud. Le fournisseur sécurise l'infrastructure et le plan de contrôle managé ; vous sécurisez ce que vous y déployez et configurez (identités, réseau, charges, secrets, code). Le formaliser en tableau évite les angles morts coûteux.

Comment Kubernetes se conforme-t-il au RGPD, à NIS2 ou aux recommandations de l'ANSSI ?

Kubernetes n'est pas « conforme » en soi : c'est votre configuration qui l'est. Le RBAC, le chiffrement et l'audit logging servent à la fois de mesures de sécurité et de preuves de conformité. L'ANSSI cadre le durcissement (BP-28, conteneurisation), NIS2 impose la gestion des risques et la notification d'incidents, DORA exige la résilience opérationnelle dans la finance, et le RGPD structure les responsabilités (responsable de traitement / sous-traitant art. 28).

Comment détecter une intrusion ou un comportement anormal dans un cluster Kubernetes ?

En combinant les audit logs de l'API server (qui a fait quoi) et la détection runtime comportementale avec Falco ou des outils eBPF/Tetragon (qu'est-ce qui se passe d'anormal). Ces sources alimentent à la fois l'alerte en temps réel et l'investigation forensique après incident.

Qu'est-ce qu'OPA Gatekeeper ou Kyverno et à quoi ça sert ?

Ce sont des moteurs d'admission control en policy-as-code : ils appliquent automatiquement des règles de sécurité à chaque déploiement (par exemple interdire les conteneurs privilégiés). OPA Gatekeeper utilise le langage Rego, puissant mais exigeant ; Kyverno utilise du YAML, plus accessible aux équipes Kubernetes. Ils empêchent de déployer une charge non conforme, même par erreur.

Combien coûte la sécurisation d'un cluster Kubernetes ?

Une mission de durcissement mobilise généralement 2 à 7 jours, pour un budget indicatif de 5 000 à 12 000 €, établi sur devis selon le périmètre. Au-delà de la mission, prévoir des coûts récurrents : surcoût d'exécution des agents (Falco en DaemonSet), rétention des logs d'audit, licences d'outils éventuelles, coffre à secrets et, surtout, le temps d'ingénierie pour maintenir la posture.