~10 minutes
Cet article fait partie de la série Sécurité Kubernetes. Si vous cherchez l’introduction et le sommaire complet, commencez par là.
Suite à la publication du podcast NoLimitSecu sur l’outil OSAKA de l’ANSSI, j’ai voulu creuser un peu plus pour comprendre comment cet outil peut m’aider à visualiser les chemins d’attaque dans des environnements Kubernetes complexes.
Pourquoi un outil dédié aux chemins d’attaque K8s ?
Dans le cadre de l’audit de sécurité des infrastructures Cloud, la complexité des configurations Kubernetes rend souvent difficile l’identification des risques de mouvements latéraux. Les méthodologies classiques comme STRIDE ou PASTA sont excellentes pour identifier des menaces générales, mais j’ai constaté qu’elles montrent leurs limites lorsqu’il s’agit de modéliser des environnements Kubernetes complexes.
La nature dynamique et distribuée de Kubernetes, avec ses nombreux objets interconnectés (Pods, Services, ConfigMaps, Secrets, RBAC…), rend difficile la capture complète des interactions potentielles entre ces composants. Dans les audits, il faut souvent passer des heures à retracer manuellement les relations entre les objets K8s.
Le constat : kubectl et les manifestes YAML ne permettent pas de visualiser les relations transitives entre objets. Un ServiceAccount qui peut lister les Secrets d’un namespace, lui-même lié à un Pod exposé publiquement : ce chemin d’attaque est invisible sans modélisation en graphe.
OSAKA comble cette lacune en offrant une approche basée sur les graphes, permettant de visualiser les relations spécifiques entre les objets Kubernetes et d’identifier les chemins d’attaque possibles en tenant compte des configurations réelles.
Qu’est-ce que OSAKA ?
OSAKA (Outil de Sécurité des Architectures Kubernetes Avancées) est un outil open source conçu par l’ANSSI pour aider les auditeurs et experts en sécurité à reconstruire des chemins d’attaque complexes dans des clusters Kubernetes. En s’appuyant sur une base de données orientée graphes, il permet de visualiser comment un attaquant pourrait progresser au sein d’un cluster.
La stack technique
OSAKA repose sur trois composants complémentaires :
| Composant | Rôle |
|---|---|
| Neo4j | Moteur de base de données pour stocker les objets K8s et leurs relations |
| Cypher | Langage de requête pour interroger le graphe et identifier les vulnérabilités |
| NeoDash | Interface de visualisation pour créer des dashboards de sécurité |
Scénarios d’utilisation
J’ai identifié trois contextes où OSAKA brille particulièrement :
1. Audit “White Box”
Identifier rapidement des vulnérabilités de conception en croisant les fichiers YAML de configuration.Utiliser OSAKA systématiquement dans des missions d’audit pour gagner un temps précieux. L’outil permet de charger l’ensemble des manifestes d’un cluster et de visualiser immédiatement les relations à risque.
2. Durcissement (Hardening)
Pour les équipes DevSecOps souhaitant appliquer le principe du moindre privilège sur le RBAC. C’est l’outil parfait pour visualiser les permissions excessives : un simple parcours du graphe révèle quels ServiceAccounts disposent de droits trop larges et quels Pods en héritent.
3. Réponse aux incidents
Cartographier le périmètre d’action d’un pod compromis pour évaluer l’étendue d’une fuite de données. L’utilisation d’OSAKA lors d’une réponse à incident réelle, permet de comprendre en quelques minutes ce qui aurait pris des heures avec kubectl.
Conseil pratique : Je recommande de lancer OSAKA dès le début d’un audit K8s, même avant d’avoir identifié des vulnérabilités spécifiques. La visualisation globale aide à prioriser les zones à investiguer en profondeur.
Exemples de chemins d’attaque détectés
Grâce à la visualisation en graphes, OSAKA permet de mettre en lumière des scénarios critiques.
Escalade via les Secrets
Un pod exposé sur Internet possède un ServiceAccount avec le droit de lister les secrets du namespace. OSAKA affiche visuellement le lien direct entre ce pod et les jetons d’administration du cluster. Le chemin d’attaque est immédiat : compromission du pod → accès au ServiceAccount → lecture des secrets → escalade vers cluster-admin.
Échappement de conteneur via hostPath
Si un pod a accès au socket Docker ou au système de fichiers de l’hôte via un volume hostPath, OSAKA trace la route potentielle d’un attaquant passant du conteneur au nœud physique. Ce type de configuration, souvent laissé par erreur dans des déploiements de monitoring, représente un risque critique d’échappement de conteneur.
RBAC transitif et permissions cachées
Le scénario le plus insidieux : un pod dispose d’un ServiceAccount ayant le droit de créer des RoleBindings. En théorie, il ne peut rien faire de critique. En pratique, il peut se donner n’importe quelle permission en créant un binding vers un ClusterRole existant. OSAKA détecte ces chemins transitifs que l’analyse manuelle manque systématiquement.
Mise en œuvre rapide
L’utilisation d’OSAKA se décompose en deux phases simples.
Phase 1 : Collecte des données
L’ANSSI fournit un script de collecte qui extrait l’ensemble des objets Kubernetes pertinents (Pods, Services, ServiceAccounts, Roles, Bindings, ConfigMaps, Secrets, Volumes…) et les exporte dans un fichier ZIP. Ce script doit être exécuté depuis un environnement ayant accès à l’API Kubernetes du cluster cible.
La collecte ne nécessite pas de droits administrateur sur le cluster. Des permissions en lecture seule suffisent, ce qui est un point fort pour les audits où l’accès est restreint.
Phase 2 : Analyse et Visualisation
Après avoir déployé OSAKA via Docker Compose, le fichier ZIP est importé dans l’osaka-loader. Le graphe est alors construit automatiquement et l’interface NeoDash permet de naviguer visuellement dans les relations entre objets.
Les requêtes Cypher prédéfinies par l’ANSSI couvrent les scénarios d’attaque les plus courants : escalade de privilèges, accès aux secrets, échappement de conteneur, mouvements latéraux via le réseau. Il est également possible d’écrire ses propres requêtes pour des analyses ciblées.
⚠️ Avertissement de sécurité
L’ANSSI précise que cet outil n’a pas été conçu selon un modèle de développement sécurisé. Il doit impérativement être déployé dans un environnement isolé et contrôlé, idéalement derrière un reverse proxy HTTPS.
Quelques références pour aller plus loin
- ✓ OSAKA est un outil gratuit de l'ANSSI qui transforme les configurations Kubernetes en graphes de relations exploitables pour identifier les chemins d'attaque.
- ✓ La stack Neo4j + Cypher + NeoDash permet de visualiser et interroger les relations complexes entre objets K8s (Pods, Secrets, ServiceAccounts, RBAC, etc.).
- ✓ Trois cas d'usage principaux : audits sécurité white-box, durcissement DevSecOps, et réponse aux incidents pour cartographier l'impact d'une compromission.
- ✓ Automatise l'analyse fastidieuse des permissions et relations K8s qui prendrait des heures manuellement, et détecte les chemins transitifs invisibles à l'œil nu.
- ✓ Déployer OSAKA dans un environnement isolé : l'outil n'a pas été conçu avec un modèle de développement sécurisé et ne doit jamais être exposé publiquement.