Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Pentest Kubernetes — Simulation d'Attaque Réaliste

Nous attaquons votre cluster Kubernetes comme le ferait un adversaire réel. Container escape, mouvement latéral, escalade de privilèges, vol de secrets — pour découvrir vos vulnérabilités avant qu'un attaquant ne les exploite.

En savoir plus
OSCP

Offensive Security Certified

CKS

Certified Kubernetes Security

+40

Clusters pentestés

Qu'est-ce qu'un pentest Kubernetes ?

Un pentest Kubernetes (test d'intrusion) est une simulation d'attaque réaliste contre votre infrastructure de conteneurs orchestrée par Kubernetes. Contrairement à un audit de conformité qui vérifie des configurations par rapport à un référentiel, le pentest adopte la perspective d'un attaquant réel qui cherche à compromettre votre cluster.

L'objectif est de répondre à la question : « Que peut faire un attaquant qui obtient un accès initial à un pod, un ServiceAccount compromis ou un accès au réseau du cluster ? » Nous simulons les techniques réelles utilisées par les groupes d'attaque ciblant Kubernetes : container escape, vol de tokens ServiceAccount, exploitation de l'API Server, mouvement latéral entre pods, escalade de privilèges RBAC et exfiltration de données.

Notre méthodologie est alignée sur le framework MITRE ATT&CK for Containers, qui catalogue les tactiques, techniques et procédures (TTP) observées dans les compromissions réelles d'environnements Kubernetes. Chaque technique utilisée pendant le pentest est mappée sur ce framework pour une traçabilité complète.

Le pentest Kubernetes se distingue d'un pentest applicatif classique par la profondeur de la chaîne d'attaque. L'accès initial à un pod n'est que le point de départ : la véritable valeur réside dans la capacité à pivoter depuis ce pod vers d'autres workloads, le node sous-jacent, l'API Server et finalement les secrets et données sensibles du cluster entier.

60%

Des pentests K8s aboutissent à un contrôle total du cluster

4h

Temps médian pour un container escape réussi

89%

Des clusters permettent le mouvement latéral

MITRE

ATT&CK for Containers comme référence

Pentest vs Audit — deux approches complémentaires

Pentest Kubernetes

  • Perspective attaquant — simulation adversaire réaliste
  • Exploitation réelle — preuves de compromission (container escape, tokens volés)
  • Impact démontré — qu'est-ce qu'un attaquant peut réellement faire
  • MITRE ATT&CK — mapping sur les TTP réels
  • Black/Gray-box — information limitée au départ

Audit Kubernetes

  • Perspective conformité — vérification systématique
  • Contrôles de configuration — CIS Benchmark, NSA/CISA
  • Couverture exhaustive — 250+ points de contrôle
  • Score de maturité — pourcentage de conformité
  • White-box — accès complet à la configuration

MITRE ATT&CK for Containers — notre référence

TA01

Initial Access

Exploitation d'applications exposées, credentials compromis, supply chain attack, ingress controller vulnérable.

TA02

Execution

Exec dans un container, déploiement de pods malveillants, exploitation de CronJobs, kubectl exec.

TA03

Persistence

Backdoor via DaemonSet, mutation webhook, CronJob malveillant, ServiceAccount supplémentaire.

TA04

Privilege Escalation

Container escape, RBAC abuse, privileged pods, hostPath mount, node shell access.

TA05

Defense Evasion

Pod anonyme, suppression des logs, modification des admission policies, namespace squatting.

TA06

Credential Access

Vol de ServiceAccount tokens, secrets Kubernetes, etcd dump, environment variables, ConfigMaps.

TA07

Lateral Movement

Pivot inter-pod, exploitation de services internes, abus de Network Policies manquantes, DNS poisoning.

TA08

Impact / Exfiltration

Exfiltration de secrets, accès aux bases de données, déni de service, cryptomining, ransomware.

Vecteurs d'attaque testés

Chaque vecteur d'attaque est testé méthodiquement. Voici les 8 catégories principales que nous explorons pendant le pentest, des plus fréquents aux plus avancés.

Container Escape

Techniques pour s'échapper du container vers le node hôte.

  • • Privileged container breakout
  • • hostPID/hostNetwork abuse
  • • /proc/1/root escape
  • • CVE kernel exploitation
  • • Docker socket mount

Escalade RBAC

Abus des permissions pour obtenir des privilèges supérieurs.

  • • Token theft (ServiceAccount)
  • • Impersonation abuse
  • • Privilege escalation via bind
  • • Wildcard exploitation
  • • CSR signing abuse

Mouvement Latéral

Pivoter d'un pod compromis vers d'autres ressources.

  • • Pod-to-pod sans Network Policy
  • • Service exploitation interne
  • • DNS-based service discovery
  • • Cross-namespace access
  • • Cloud metadata API (169.254.169.254)

Vol de Secrets

Extraction de credentials et données sensibles.

  • • Kubernetes Secrets enumeration
  • • Environment variables dump
  • • ConfigMap sensitive data
  • • etcd direct access
  • • Volume mount exploitation

API Server Exploitation

Attaque du point central de contrôle du cluster.

  • • Anonymous authentication abuse
  • • Insecure API endpoint
  • • SSRF via webhooks
  • • Token brute-force
  • • Admission controller bypass

Supply Chain Attack

Compromission via la chaîne d'approvisionnement.

  • • Malicious image injection
  • • Registry poisoning
  • • Dependency confusion
  • • Helm chart backdoor
  • • CI/CD pipeline compromise

Node Exploitation

Compromission des nodes worker et control plane.

  • • Kubelet API exploitation
  • • Node shell via container escape
  • • Cloud metadata IMDS abuse
  • • SSH key extraction
  • • Node-to-control-plane pivot

Persistance

Techniques pour maintenir l'accès après la compromission initiale.

  • • DaemonSet backdoor
  • • CronJob malveillant
  • • Mutation webhook implant
  • • Static pod injection
  • • Token long-lived creation

Qui est concerné par un pentest Kubernetes ?

Le pentest Kubernetes s'adresse aux organisations qui exploitent déjà des clusters en production et souhaitent valider leur résistance face à une attaque réelle. Il est particulièrement pertinent pour :

  • Après un audit K8s — valider que les remédiations résistent à une attaque
  • Avant une mise en production critique — application sensible, migration
  • Exigence réglementaire — PCI-DSS, DORA, NIS2 imposent des tests d'intrusion
  • Multi-tenant SaaS — isolation entre tenants sur K8s
  • Red Team / Purple Team — intégrer K8s dans les exercices offensifs
  • Détection & réponse — tester vos capacités de détection (Falco, SIEM)
  • Post-incident — reproduire le chemin d'attaque d'un incident réel
  • Due diligence M&A — évaluer le risque technique d'une acquisition

Le saviez-vous ?

Selon le rapport CNCF 2025, 60% des pentests Kubernetes aboutissent à un contrôle total du cluster (cluster-admin) en partant d'un simple pod compromis. La chaîne d'attaque typique — token theft → RBAC escalation → secrets dump — prend en moyenne moins de 4 heures. La prévention passe par des contrôles en profondeur, pas une simple barrière périmétrique.

Méthodologie de pentest détaillée

Notre pentest Kubernetes suit la kill chain adaptée aux environnements conteneurisés. 7 phases, de la reconnaissance initiale à l'exfiltration de données, mappées sur le framework MITRE ATT&CK for Containers.

1

Reconnaissance externe

Jour 1-2

Phase d'OSINT et de reconnaissance active pour identifier la surface d'attaque exposée du cluster Kubernetes. Nous recherchons les endpoints API, les dashboards, les services exposés (NodePort, LoadBalancer, Ingress) et les fuites d'information (kubeconfig dans des repos Git, tokens dans des logs, etc.).

Activités

  • • Scan de ports sur les ranges du cluster
  • • Recherche de l'API Server exposé
  • • Détection de dashboards (K8s, Grafana, ArgoCD)
  • • OSINT sur les registries d'images
  • • Recherche de kubeconfig leakés
  • • Identification de l'Ingress Controller

Outils

  • • nmap (port scanning)
  • • kube-hunter (external scan)
  • • Shodan / Censys
  • • GitHub dorking (kubeconfig)
  • • nuclei (vuln templates K8s)
  • • curl / httpie (API probing)

Résultat

  • • Surface d'attaque externe mappée
  • • Services exposés identifiés
  • • Vecteurs d'accès initial listés
  • • Fuites d'information répertoriées
  • • Plan d'attaque initial établi
  • • Priorisation des cibles
2

Accès initial & foothold

Jour 2-4

Exploitation des vulnérabilités identifiées pour obtenir un accès initial dans le cluster. Cela peut être l'exploitation d'une application web vulnérable hébergée sur K8s, l'abus d'un endpoint API non protégé, l'utilisation d'un token compromis ou l'exploitation d'un service exposé par erreur.

Activités

  • • Exploitation d'applications web (RCE, SSRF)
  • • Abus de l'API Server (anonymous auth)
  • • Utilisation de credentials compromis
  • • Exploitation d'Ingress Controller
  • • Accès via CI/CD pipeline
  • • Exploitation du Kubelet API

Outils

  • • peirates (K8s pentest toolkit)
  • • kubectl (avec token volé)
  • • Burp Suite (webapp exploitation)
  • • kdigger (in-cluster recon)
  • • CDK (container exploitation)
  • • nuclei (targeted exploitation)

Résultat

  • • Shell dans un pod du cluster
  • • Accès API avec token valide
  • • Foothold établi et stable
  • • Reconnaissance interne initiale
  • • Vecteur d'accès documenté
  • • Sévérité de l'accès initial évaluée
3

Container breakout & escalade

Jour 4-7

Depuis le pod compromis, nous tentons de nous échapper du container vers le node hôte et d'escalader nos privilèges. C'est la phase la plus critique du pentest : elle démontre si vos défenses en profondeur (Pod Security Standards, seccomp, AppArmor) sont efficaces face à une exploitation réelle.

Activités

  • • Test d'évasion container (privileged, hostPID)
  • • Exploitation des capabilities dangereuses
  • • Montage hostPath / Docker socket
  • • Exploitation de CVE kernel (Dirty Pipe, etc.)
  • • Accès au kubelet via node compromise
  • • RBAC privilege escalation chains

Outils

  • • BOtB (Break out the Box)
  • • CDK (Container pentest toolkit)
  • • deepce (Docker escape detection)
  • • amicontained (container info)
  • • nsenter (namespace escape)
  • • Kernel exploit PoCs

Résultat

  • • Shell root sur le node (si possible)
  • • Preuves de container escape
  • • Chemins d'escalade documentés
  • • Efficacité des défenses évaluée
  • • Accès au kubelet démontré
  • • Score de résistance à l'escalade
4

Mouvement latéral & pivoting

Jour 7-10

Depuis notre position (pod compromis ou node), nous pivotons vers d'autres ressources du cluster : autres namespaces, services internes, bases de données, API internes. L'objectif est de démontrer l'absence d'isolation réseau et la possibilité de se déplacer latéralement dans le cluster sans être détecté.

Activités

  • • Scan réseau interne (service discovery)
  • • Accès inter-namespaces
  • • Exploitation de services internes
  • • Accès au cloud metadata (169.254.169.254)
  • • Pivot depuis le node vers d'autres nodes
  • • DNS-based enumeration

Outils

  • • peirates (K8s lateral movement)
  • • kubectl (cross-namespace enum)
  • • nmap (internal network scan)
  • • curl (cloud metadata probe)
  • • dig / nslookup (DNS enum K8s)
  • • chisel / socat (tunneling)

Résultat

  • • Carte des mouvements latéraux possibles
  • • Services internes compromis
  • • Isolation réseau évaluée
  • • Credentials cloud récupérés
  • • Chemins d'attaque complètes documentés
  • • Détection (ou non) par le SOC
5

Persistance & évasion

Jour 10-12

Nous démontrons comment un attaquant pourrait maintenir son accès au cluster de manière persistante, même après un redéploiement des pods compromis. Nous testons également les capacités de détection de votre infrastructure : Falco, audit logs, SIEM sont-ils capables de nous détecter ?

Activités

  • • Création de backdoor DaemonSet
  • • CronJob malveillant persistant
  • • Mutation webhook implant
  • • Création de ServiceAccount caché
  • • Test d'évasion des détections Falco
  • • Analyse des audit logs générés

Outils

  • • kubectl (resource creation)
  • • peirates (persistence modules)
  • • Custom YAML payloads
  • • Webhook injection scripts
  • • Log analysis tools
  • • Falco rule testing

Résultat

  • • Mécanismes de persistance démontrés
  • • Capacités de détection évaluées
  • • Blind spots identifiés
  • • Règles Falco manquantes listées
  • • Couverture audit logging évaluée
  • • Temps de détection mesuré
6

Exfiltration de données

Jour 12-14

Phase finale de l'attaque : nous démontrons la capacité à exfiltrer des données sensibles depuis le cluster. Secrets Kubernetes, données de bases de données, configurations, certificats TLS — tout ce qu'un attaquant pourrait extraire pour un impact maximum (vol de données, ransomware, espionnage).

Activités

  • • Dump de tous les Secrets Kubernetes accessibles
  • • Accès aux bases de données internes
  • • Extraction de certificats TLS
  • • Accès aux volumes persistants
  • • Récupération des credentials cloud (IRSA, Workload Identity)
  • • Simulation d'exfiltration par canal caché

Outils

  • • kubectl get secrets
  • • peirates (secrets enumeration)
  • • etcdctl (direct etcd access)
  • • Database clients (mysql, psql, redis-cli)
  • • AWS CLI / gcloud / az (cloud creds)
  • • DNS/HTTP exfiltration tools

Résultat

  • • Liste des données exfiltrables
  • • Secrets critiques compromis
  • • Données métier accessibles
  • • Impact business démontré
  • • Canaux d'exfiltration documentés
  • • Score de sévérité global
7

Rapport & debriefing

Jour 14-17

Rédaction du rapport d'intrusion complet, présentation des findings avec preuves d'exploitation, kill chain complète et recommandations de remédiation. Chaque finding est mappé sur le framework MITRE ATT&CK pour une traçabilité maximale.

Activités

  • • Rédaction du rapport d'intrusion
  • • Documentation des preuves (screenshots, logs)
  • • Mapping MITRE ATT&CK
  • • Présentation technique détaillée
  • • Executive summary pour la direction
  • • Atelier de remédiation

Livrables

  • • Rapport d'intrusion (60-100 pages)
  • • Executive summary (3-5 pages)
  • • Kill chain diagram complet
  • • Mapping MITRE ATT&CK
  • • Recommandations de remédiation priorisées
  • • Règles de détection (Falco, SIEM)

Résultat

  • • Vision claire du risque réel
  • • Kill chain complète documentée
  • • Preuves exploitables pour la direction
  • • Plan de remédiation priorisé
  • • Amélioration des détections
  • • Base pour le prochain pentest

Prestation clé en main — tout est inclus

Un pentest Kubernetes complet qui couvre toute la kill chain : de l'accès initial à l'exfiltration. Outils offensifs spécialisés, preuves d'exploitation, mapping MITRE et plans de remédiation.

Arsenal offensif spécialisé K8s

Nous utilisons les mêmes outils que les groupes d'attaque ciblant Kubernetes. Pas d'outils génériques : un arsenal spécifiquement conçu pour l'exploitation de clusters.

  • peirates (K8s attack framework)
  • BOtB (Break out the Box)
  • CDK (Container exploitation toolkit)
  • deepce (Docker/container escape)
  • kdigger (container introspection)
  • Outils custom développés en interne

Livrables offensifs

Des preuves d'exploitation concrètes, pas des théories. Chaque vulnérabilité est exploitée et documentée avec des captures d'écran, des logs et la chaîne d'attaque complète.

  • Rapport d'intrusion détaillé (60-100 pages)
  • Kill chain diagram (Attack Path)
  • Mapping MITRE ATT&CK complet
  • Preuves d'exploitation (screenshots, logs)
  • Recommandations de remédiation
  • Règles de détection Falco / SIEM

Test des détections

Le pentest ne teste pas seulement vos vulnérabilités : il évalue également vos capacités de détection et de réponse aux incidents.

  • Évaluation des règles Falco
  • Test de l'audit logging API Server
  • Mesure du temps de détection
  • Blind spots identifiés et documentés
  • Règles de détection recommandées
  • Alerting prioritaire défini

Accompagnement post-pentest

Le pentest ne s'arrête pas au rapport. Nous accompagnons vos équipes dans la compréhension et la remédiation des vulnérabilités découvertes.

  • Présentation technique détaillée
  • Atelier de remédiation (1 jour)
  • Support 30 jours post-pentest
  • Contre-pentest post-remédiation
  • Formation offensive/défensive (en option)
  • Exercice Purple Team K8s (en option)

Double expertise : offensive K8s + défense

Notre équipe combine l'expertise offensive (pentest, red team) et défensive (hardening, détection) pour un pentest qui ne se contente pas de trouver des vulnérabilités, mais propose également les défenses adéquates.

Volet offensif

  • Container escape — breakout via privileged, hostPID, Docker socket, CVE kernel
  • RBAC exploitation — escalade via token theft, impersonation, wildcard abuse
  • Mouvement latéral — pivot inter-pod, cross-namespace, cloud metadata
  • Persistance — DaemonSet backdoor, CronJob, webhook implant
  • Exfiltration — secrets dump, database access, cloud credentials
  • Supply chain — image poisoning, registry compromise

Volet défensif

  • Pod Security Standards — recommandations Restricted/Baseline par workload
  • Network Policies — deny-by-default, micro-segmentation, Service Mesh
  • RBAC hardening — moindre privilège, SA dédiés, token rotation
  • Règles de détection — Falco rules custom, audit log alerting
  • Admission controllers — OPA/Gatekeeper/Kyverno policies
  • Runtime security — seccomp, AppArmor, read-only rootfs

Votre cluster résisterait-il à une attaque réelle ?

60% des pentests K8s aboutissent à un contrôle total du cluster. Ne découvrez pas vos vulnérabilités le jour d'un incident. Testez-les maintenant, en conditions contrôlées.

Modes de pentest Kubernetes

Trois scénarios d'attaque pour des objectifs différents. Choisissez celui qui correspond à votre modèle de menace.

Critère Black-box Gray-box Assumed Breach
Accès initial Aucun — attaquant externe Credentials d'un développeur Shell dans un pod (simulé)
Scénario Attaquant externe sans information Insider menace / compte compromis Application web compromis → container
Focus Surface d'attaque externe Escalade de privilèges interne Container escape + mouvement latéral
Durée typique 15 à 20 jours 12 à 17 jours 10 à 15 jours
Profondeur Large, surface Moyenne, ciblée Profonde, kill chain complète
Le plus demandé Validation périmétrique Après audit de conformité Red Team / Purple Team
Recommandé pour Primo-pentest K8s Sécurité mature, compliance Clusters critiques (fintech, santé)

Notre recommandation

Pour la plupart des organisations, le mode Assumed Breach offre le meilleur rapport couverture/investissement. Il simule le scénario le plus probable : un attaquant qui a compromis une application web et se retrouve dans un container. C'est à partir de là que la sécurité Kubernetes est véritablement testée.

Techniques d'attaque en détail

Voici les principales techniques que nous utilisons pendant un pentest Kubernetes, avec les conditions d'exploitation et les défenses associées.

Container Escape — 5 techniques principales

Privileged Container

Sévérité : Critique

Un container avec privileged: true a accès à tous les devices du node. L'évasion est triviale via mount du filesystem hôte ou chroot.

Défense : Pod Security Standards Restricted, OPA deny privileged

hostPID / hostNetwork

Sévérité : Critique

L'accès au PID namespace ou au réseau du node permet de voir/interagir avec tous les processus ou services du node hôte.

Défense : Interdire hostPID/hostNetwork dans les policies

Docker Socket Mount

Sévérité : Critique

Le montage de /var/run/docker.sock donne le contrôle total du runtime. On peut créer des containers privilégiés à volonté.

Défense : Interdire les montages hostPath sensibles

CVE Kernel

Sévérité : Haute

Exploitation de vulnérabilités kernel (Dirty Pipe CVE-2022-0847, runc CVE-2024-21626) pour échapper au container malgré les restrictions.

Défense : Patch kernel, seccomp strict, minimal capabilities

SYS_PTRACE + /proc

Sévérité : Haute

La capability SYS_PTRACE permet de s'attacher aux processus du node via /proc. Combine avec hostPID pour un escape complet.

Défense : drop ALL capabilities, add only needed

Escalade RBAC — 4 techniques principales

Token Theft via Projected Volume

Chaque pod monte automatiquement un token ServiceAccount. Si le SA a des permissions excessives, le vol du token donne un accès élargi au cluster. L'auto-mount doit être désactivé quand le pod n'a pas besoin d'accéder à l'API.

Escalade via bind/escalate

Un utilisateur avec les permissions bind ou escalate sur les RoleBindings peut s'octroyer des privilèges supérieurs en créant de nouveaux bindings vers des Roles plus puissants.

Impersonation Abuse

La permission impersonate permet d'agir en tant qu'un autre utilisateur ou ServiceAccount. Si mal configurée, elle donne un accès cluster-admin en une seule commande kubectl.

CSR Signing Abuse

L'accès aux CertificateSigningRequests permet de générer des certificats clients pour n'importe quel utilisateur ou groupe, contournant l'authentification standard du cluster.

Cas client — SaaS multi-tenant, cluster-admin en 3h

Retour d'expérience anonymisé d'un pentest Kubernetes pour un éditeur SaaS européen hébergeant des données de santé sur GKE.

Contexte

  • Secteur : Éditeur SaaS santé, 80 collaborateurs, données HDS
  • Infra : 3 clusters GKE, architecture multi-tenant (1 namespace / client)
  • Enjeu : Prouver l'isolation entre tenants pour la certification HDS
  • Mode : Assumed Breach — shell initial dans un pod tenant A

Résultats

3h

Pour obtenir cluster-admin

23

Findings critiques / hauts

0

Détections par Falco

100%

Des tenants accessibles

Kill Chain complète

T+0h

Shell dans un pod

Accès initial simulé dans un pod du tenant A. Reconnaissance interne : ServiceAccount avec token auto-monté, permissions get/list sur les secrets du namespace.

T+1h30

Cross-tenant access

Absence de Network Policies : accès direct aux pods de tous les tenants. Dump des bases de données de 3 tenants différents via le réseau interne.

T+2h30

Container escape

Pod de monitoring avec hostPID: true et SYS_PTRACE. Escape vers le node via nsenter, accès root au worker node. Récupération du kubeconfig admin.

T+3h

Cluster-admin obtenu

Accès cluster-admin via le kubelet du node. Dump de l'ensemble des secrets, accès au compte GCP via Workload Identity. Aucune alerte générée.

Répartition des findings

8

Critiques

15

Hautes

22

Moyennes

11

Basses

6

Info

Nos engagements contractuels

Des engagements concrets, inscrits au contrat. Transparence, maîtrise du risque et résultats garantis.

Pentester certifié

OSCP + CKS. Pas de junior, pas de sous-traitance. Un expert offensif spécialisé Kubernetes dédié à votre mission.

Alerte en temps réel

Toute vulnérabilité critique est signalée immédiatement par téléphone, sans attendre la fin du pentest. Procédure d'escalade définie au contrat.

Maîtrise du risque

Procédure de rollback pour chaque action. Aucune modification persistante sans validation. Nettoyage complet en fin de mission.

Contre-pentest inclus

Un contre-pentest ciblé est inclus 30 à 60 jours après la livraison pour vérifier la correction des vulnérabilités critiques.

Questions fréquentes sur le pentest Kubernetes

Le risque est contrôlé et minimisé. Chaque action est réfléchie et réversible. Nous ne détruisons jamais de données et ne provoquons pas de déni de service volontairement. Les exploitations lourdes (container escape, kernel exploit) sont effectuées dans des conditions contrôlées, idéalement sur un namespace dédié ou un cluster de staging. Pour les clusters critiques, nous pouvons effectuer le pentest sur un clone iso-production. Tout est défini dans les règles d'engagement signées avant le démarrage.

Un pentest applicatif se concentre sur les vulnérabilités web (OWASP Top 10 : injection, XSS, IDOR). Un pentest Kubernetes va beaucoup plus loin : il teste l'ensemble de la chaîne d'exploitation post-compromission. L'application web n'est que le vecteur d'accès initial. La valeur réside dans ce qui se passe après : le container escape, le mouvement latéral entre pods, l'escalade RBAC, l'accès aux secrets de tout le cluster. C'est un pentest d'infrastructure conteneurisée, pas un simple pentest web.

En mode Assumed Breach (le plus courant), comptez 10 à 15 jours ouvrés pour un cluster de taille moyenne. En mode Gray-box avec accès développeur, 12 à 17 jours. En mode Black-box complet, 15 à 20 jours. Le rapport est livré dans les 5 jours ouvrés suivant la fin des tests. Les findings critiques sont signalés immédiatement. Le planning est défini précisément lors de la phase de cadrage.

Ce n'est pas obligatoire mais c'est fortement recommandé. L'audit de conformité (CIS Benchmark) identifie et corrige les misconfigurations évidentes. Le pentest effectué ensuite se concentre sur les vulnérabilités plus subtiles et les chaînes d'exploitation complexes. Si vous pentestez un cluster mal configuré, vous obtiendrez rapidement un cluster-admin (en quelques heures), ce qui est certes impressionnant mais moins utile qu'un pentest sur un cluster déjà hardened qui révèle des failles plus profondes.

Absolument. La frontière entre Kubernetes et le cloud est poreuse. Un container escape sur un node EKS donne accès à l'IMDS (Instance Metadata Service), ce qui peut révéler des credentials IAM avec des permissions excessives. De même, l'abus de Workload Identity (GKE) ou IRSA (EKS) peut donner accès à des ressources cloud (S3 buckets, bases de données RDS, Key Vault). Le pentest K8s teste naturellement ces frontières cloud/K8s.

Vous recevez : (1) un rapport d'intrusion détaillé de 60 à 100 pages avec chaque vulnérabilité classée par CVSS, (2) un executive summary de 3-5 pages pour la direction, (3) le diagramme de la kill chain complète, (4) un mapping MITRE ATT&CK de chaque technique utilisée, (5) des captures d'écran et logs prouvant chaque exploitation, (6) des recommandations de remédiation priorisées et (7) des règles de détection Falco/SIEM pour les techniques utilisées.

Nous recommandons un pentest K8s annuel au minimum, complété par un contre-pentest à 6 mois. Pour les environnements critiques (fintech, santé, défense), deux pentests complets par an sont préférables. Tout changement majeur (upgrade K8s, nouveau CNI, migration cloud, ajout de cluster) devrait déclencher un pentest ciblé. PCI-DSS impose des tests d'intrusion au minimum annuels sur les environnements traitant des données de carte.

Oui. Un exercice Purple Team K8s combine notre expertise offensive avec votre équipe défensive (SOC, DevSecOps). Nous exécutons des techniques d'attaque en temps réel pendant que votre équipe tente de détecter et de répondre. C'est le meilleur moyen d'améliorer vos règles Falco, vos alertes SIEM et vos procédures de réponse aux incidents spécifiques à Kubernetes. Le Purple Team est proposé en option après un pentest initial.

Pourquoi nous choisir ?

Spécialistes K8s offensif

Pas de pentesters généralistes : nos experts sont spécialisés en sécurité offensive Kubernetes. OSCP + CKS + expérience CTF containers.

MITRE ATT&CK mappé

Chaque technique utilisée est mappée sur le framework MITRE ATT&CK for Containers. Vos équipes défensives obtiennent un référentiel clair.

Test des détections

Le pentest évalue aussi vos capacités de détection (Falco, SIEM, alerting). Nous fournissons les règles manquantes pour chaque technique exploitée.

Kill chain complète

Pas seulement un scan de vulnérabilités : nous exécutons la kill chain complète, du premier accès à l'exfiltration de données. Impact business démontré.

+40 clusters pentestés

Plus de 40 clusters pentestés en production. EKS, AKS, GKE, OpenShift, k3s. Nous connaissons les faiblesses spécifiques de chaque plateforme.

Contre-pentest inclus

Un contre-pentest ciblé est inclus dans la prestation pour vérifier que les vulnérabilités critiques ont été correctement corrigées.

Testez la résistance de votre cluster Kubernetes

60% des pentests K8s aboutissent à un contrôle total du cluster. Ne découvrez pas cette réalité lors d'un incident. Simulez l'attaque maintenant, en conditions contrôlées, avec des experts offensifs spécialisés.

Réponse sous 24h — Échange initial gratuit et sans engagement

15+
ans d'expertise cyber & IA
100+
missions réalisées
ISO 27001
Lead Implementer & Auditor
24h
réponse devis
Réponse sous 24h ouvrées

Discutons de votre projet Pentest Kubernetes

Échange découverte gratuit de 30 minutes. Devis personnalisé sous 24h ouvrées. Aucun engagement, aucune obligation.

Réserver un échange 30 min
Sans engagement 30 min offerts Conseil pro immédiat NDA possible

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis