Un cluster Kubernetes managé concentre une grande partie de la surface d'attaque
cloud : son plan de contrôle pilote tout, et un pod compromis peut chercher à s'en
évader. Cette famille durcit le cluster à chaque couche. Le serveur d'API n'est
pas exposé à Internet ; le plan de contrôle est en haute disponibilité et
maintenu à jour ; le RBAC applique le moindre privilège (pas de
cluster-admin distribué, pas de joker) ; les Pod Security Standards
interdisent conteneurs privilégiés, root et HostPath qui permettent l'évasion ; les
NetworkPolicy en refus par défaut cloisonnent les flux est-ouest ; les
secrets sont chiffrés dans etcd et gérés via un coffre externe ; et un
contrôle d'admission (OPA/Kyverno) n'autorise que des images signées d'un
registre approuvé.
Concrètement, ces exigences parent : l'API server exposé pris pour cible, l'évasion de pod vers le nœud, le mouvement latéral est-ouest faute de NetworkPolicy, les secrets etcd en clair, et le déploiement d'une image non signée. Des fondamentales (R1) aux renforcées (R2).
Un cluster mal configuré permet l'évasion de pod et le mouvement latéral cluster→cloud.
Les pièges à éviter
Section intitulée « Les pièges à éviter »Les erreurs les plus fréquentes sur ce périmètre :
Exigences
Section intitulée « Exigences »serveur d'API du cluster Kubernetes managé non exposé à Internet (liste d'autorisation restreinte).#
Le serveur d'API Kubernetes est le point de contrôle du cluster : exposé à Internet, il devient la cible numéro un. Le rendre non public (liste d'autorisation restreinte) retire cette surface : on ne peut pas attaquer le cerveau du cluster si l'on ne peut pas l'atteindre.
- Preuve attendue
- Liste d'autorisation de l'API server restreinte aux CIDR d'administration.
- Outillage
- kube-bench Kubescape
Correspondances & menaces parées 3 standards · 2 menaces
Un conteneur malveillant est déployé dans le cluster ou le service cloud pour exécuter du code dans le périmètre de confiance. Les droits de déploiement détournés introduisent la charge (ATT&CK T1610) ATT&CK T1610. L'attaquant utilise les API d'administration (kubectl exec, équivalents) pour exécuter des commandes dans des conteneurs en place. Les droits d'exec mal restreints donnent un accès direct aux charges (ATT&CK T1609) ATT&CK T1609.
secrets Kubernetes gérés via un coffre externe ; jamais en clair dans les manifests ou les variables d'environnement ; montés en fichiers et tournés.#
Un secret en clair dans un manifest ou une variable d'environnement fuit dans Git, les logs et les descriptions de pod. Les gérer via un coffre externe, montés en fichiers et tournés, sort les secrets des artefacts versionnés et réduit leur exposition à la durée et au périmètre strictement nécessaires.
- Preuve attendue
- Secrets via coffre externe (CSI/External Secrets) ; absence de secret en clair dans les manifests/env.
- Outillage
- kube-bench Kubescape
Correspondances & menaces parées 3 standards · 2 menaces
Les secrets stockés dans un coffre cloud (Secrets Manager, Key Vault) sont lus grâce à des droits excessifs ou un rôle compromis. Le coffre concentre la valeur : un accès indu y donne les clés du royaume (ATT&CK T1555.006) ATT&CK T1555.006. Depuis un cluster Kubernetes, l'attaquant pivote vers le plan cloud sous-jacent via l'IMDS ou des identités de nœud, étendant l'accès au tenant. La frontière cluster / cloud est un chemin d'escalade (OWASP K08, ATT&CK T1552.005) OWASP Kubernetes K08 ATT&CK T1552.005.
contrôleur de politiques d'admission au niveau cluster (OPA Gatekeeper / Kyverno) en mode bloquant, au-delà des Pod Security Standards.#
Les Pod Security Standards ne couvrent pas toutes les règles métier (registres, labels, limites). Un contrôleur de politiques (OPA Gatekeeper, Kyverno) en mode bloquant applique vos propres règles à l'admission : un déploiement non conforme est refusé avant de s'exécuter, pas corrigé après coup.
- Preuve attendue
- Contrôleur de politiques d'admission déployé en mode enforce ; politiques versionnées.
- Outillage
- kube-bench Kubescape
Correspondances & menaces parées 2 standards · 1 menace
Un conteneur malveillant est déployé dans le cluster ou le service cloud pour exécuter du code dans le périmètre de confiance. Les droits de déploiement détournés introduisent la charge (ATT&CK T1610) ATT&CK T1610.
identités des pods (IRSA / Workload Identity) scopées au strict nécessaire ; aucun accès cloud large ni accès aux métadonnées (IMDS) du nœud depuis un pod.#
Un pod qui accède à l'IMDS du nœud ou dispose d'une identité cloud large peut détourner les droits de l'hôte. Scoper les identités de pods (IRSA / Workload Identity) au strict nécessaire et couper l'accès à l'IMDS depuis les pods empêche une charge compromise d'escalader vers le cloud.
- Preuve attendue
- Rôles cloud liés aux pods au moindre privilège ; IMDS du nœud non joignable depuis les pods.
- Outillage
- kube-bench Kubescape
Correspondances & menaces parées 2 standards · 1 menace
Depuis un cluster Kubernetes, l'attaquant pivote vers le plan cloud sous-jacent via l'IMDS ou des identités de nœud, étendant l'accès au tenant. La frontière cluster / cloud est un chemin d'escalade (OWASP K08, ATT&CK T1552.005) OWASP Kubernetes K08 ATT&CK T1552.005.
plan de contrôle du cluster Kubernetes managé en haute disponibilité (multi-AZ / multi-master) pour résister à la perte d'une zone.#
Un plan de contrôle mono-zone tombe avec sa zone, et avec lui le pilotage du cluster. Le déployer en haute disponibilité multi-AZ garantit qu'il survit à la perte d'une zone : la disponibilité fait partie de la sécurité, un cluster qu'on ne peut plus piloter est un cluster qu'on ne peut plus défendre.
- Preuve attendue
- Plan de contrôle Kubernetes managé réparti sur plusieurs zones.
- Outillage
- kube-bench Kubescape
Correspondances & menaces parées 2 standards · 1 menace
Une charge détruit données, dépôts ou systèmes (wiper, suppression) pour saboter ou couvrir ses traces. La résilience (sauvegardes éprouvées, immuabilité) conditionne la capacité de reprise ATT&CK.
hygiène de cycle de vie du cluster Kubernetes managé : mises à jour/patches automatiques, version supportée, protection contre la suppression accidentelle.#
Un cluster sur une version non supportée accumule des CVE sans correctif. Mises à jour automatiques, version supportée et protection contre la suppression accidentelle maintiennent le cluster patché et résilient : on ne laisse pas l'orchestrateur dériver vers un état vulnérable et fragile.
- Preuve attendue
- Auto-upgrade activé, version supportée, protection de suppression en place.
- Outillage
- kube-bench Kubescape
Correspondances & menaces parées 3 standards · 1 menace
Un conteneur exploite une mauvaise configuration ou une faille pour s'échapper vers le nœud hôte du cluster et atteindre d'autres charges. Le cloisonnement du cluster est rompu (ATT&CK T1611) ATT&CK T1611.
RBAC Kubernetes au moindre privilège : rôle cluster-admin réservé au strict nécessaire, pas de joker dans les Roles/ClusterRoles, service accounts par défaut non utilisés, jetons de SA montés uniquement si nécessaire.#
Un cluster-admin distribué trop largement ou un joker dans un Role donne à un pod ou un compte bien plus de droits que nécessaire. Un RBAC au moindre privilège (pas de joker, service accounts par défaut inutilisés, jetons montés au besoin) limite ce qu'un composant compromis peut faire dans le cluster.
- Preuve attendue
- Revue RBAC du cluster : cluster-admin restreint, absence de joker, SA par défaut inutilisés.
- Outillage
- kube-bench Kubescape
Correspondances & menaces parées 4 standards · 2 menaces
Un conteneur malveillant est déployé dans le cluster ou le service cloud pour exécuter du code dans le périmètre de confiance. Les droits de déploiement détournés introduisent la charge (ATT&CK T1610) ATT&CK T1610. L'attaquant utilise les API d'administration (kubectl exec, équivalents) pour exécuter des commandes dans des conteneurs en place. Les droits d'exec mal restreints donnent un accès direct aux charges (ATT&CK T1609) ATT&CK T1609.
Pod Security Standards appliqués : pas de conteneur privilégié, pas d'élévation de privilèges, exécution non-root, pas de capacités ajoutées ni de volume HostPath ; profil seccomp RuntimeDefault et Security Context.#
Un conteneur privilégié, root ou avec un HostPath peut s'évader vers le nœud hôte et compromettre le cluster. Appliquer les Pod Security Standards (non-root, pas d'élévation, seccomp RuntimeDefault, pas de capacités ajoutées) ferme les chemins d'évasion les plus courants au niveau de chaque pod.
- Preuve attendue
- Contrôleur d'admission (Pod Security / politiques) imposant non-root, non-privilégié, seccomp RuntimeDefault.
- Outillage
- kube-bench Kubescape
Correspondances & menaces parées 6 standards · 2 menaces
Un conteneur malveillant est déployé dans le cluster ou le service cloud pour exécuter du code dans le périmètre de confiance. Les droits de déploiement détournés introduisent la charge (ATT&CK T1610) ATT&CK T1610. Un conteneur exploite une mauvaise configuration ou une faille pour s'échapper vers le nœud hôte du cluster et atteindre d'autres charges. Le cloisonnement du cluster est rompu (ATT&CK T1611) ATT&CK T1611.
politiques réseau (NetworkPolicy) définies sur toutes les namespaces (refus par défaut) ; CNI compatible.#
Par défaut, tous les pods d'un cluster communiquent librement : un pod compromis atteint tous les autres. Des NetworkPolicy en refus par défaut sur chaque namespace cloisonnent ces flux est-ouest, contenant un compromis à son périmètre au lieu de le laisser se propager à tout le cluster.
- Preuve attendue
- NetworkPolicies default-deny présentes sur chaque namespace.
- Outillage
- kube-bench Kubescape
Correspondances & menaces parées 3 standards · 1 menace
Depuis un cluster Kubernetes, l'attaquant pivote vers le plan cloud sous-jacent via l'IMDS ou des identités de nœud, étendant l'accès au tenant. La frontière cluster / cloud est un chemin d'escalade (OWASP K08, ATT&CK T1552.005) OWASP Kubernetes K08 ATT&CK T1552.005.
durcissement de l'API server Kubernetes : authentification anonyme désactivée, autorisation RBAC, journalisation d'audit activée.#
Un API server autorisant l'authentification anonyme ou sans audit est un point d'entrée et un angle mort. Désactiver l'anonyme, imposer l'autorisation RBAC et activer la journalisation d'audit durcit le point de contrôle et rend ses accès traçables, condition pour détecter un abus.
- Preuve attendue
- API server : anonymous-auth=false, authorization-mode RBAC, audit-log actif.
- Outillage
- kube-bench Kubescape
Correspondances & menaces parées 4 standards · 1 menace
L'attaquant utilise les API d'administration (kubectl exec, équivalents) pour exécuter des commandes dans des conteneurs en place. Les droits d'exec mal restreints donnent un accès direct aux charges (ATT&CK T1609) ATT&CK T1609.
chiffrement au repos des secrets dans etcd via un fournisseur de chiffrement (KMS).#
Par défaut, les secrets Kubernetes sont stockés en base64 (non chiffrés) dans etcd : un accès à la base les livre en clair. Les chiffrer au repos via un fournisseur KMS garantit qu'une copie d'etcd volée ne suffit pas à récupérer les secrets du cluster.
- Preuve attendue
- encryption-provider-config (KMS) activé pour les secrets etcd.
- Outillage
- kube-bench Kubescape
Correspondances & menaces parées 3 standards · 1 menace
Les secrets stockés dans un coffre cloud (Secrets Manager, Key Vault) sont lus grâce à des droits excessifs ou un rôle compromis. Le coffre concentre la valeur : un accès indu y donne les clés du royaume (ATT&CK T1555.006) ATT&CK T1555.006.
contrôle d'admission imposant des images signées et issues d'un registre autorisé ; déploiement d'images non conformes refusé.#
Sans contrôle, le cluster déploie n'importe quelle image, y compris piégée ou d'origine inconnue. Un contrôle d'admission exigeant des images signées issues d'un registre autorisé, refusant le reste, garantit que seul du code vérifié et de provenance connue s'exécute dans le cluster.
- Preuve attendue
- Contrôleur d'admission (provenance/signature, allowlist de registres) actif et bloquant.
- Outillage
- Kyverno cosign
Correspondances & menaces parées 2 standards · 1 menace
Un conteneur malveillant est déployé dans le cluster ou le service cloud pour exécuter du code dans le périmètre de confiance. Les droits de déploiement détournés introduisent la charge (ATT&CK T1610) ATT&CK T1610.