Skip to content
Kubernetes Forensics
Blog

Cet outil n'est ni affilié à The Linux Foundation, à la Cloud Native Computing Foundation (CNCF) ou au projet Kubernetes, ni approuvé ni sponsorisé par eux. Kubernetes et K8s sont des marques déposées de The Linux Foundation. EKS, GKE, AKS et les autres noms sont des marques de leurs propriétaires respectifs.

Analyseur de logs d'audit de l'API server

Notre cluster Kubernetes a-t-il été compromis ?

Déposez vos logs d'audit de l'API server — exports self-managed, EKS, GKE ou AKS — et obtenez un verdict, les constats, une chronologie d'attaque et les prochaines étapes. Analysé dans votre navigateur avec WebAssembly : rien n'est envoyé sur un serveur.

  • MITRE ATT&CK for Containers
  • Self-managed, EKS, GKE, AKS
  • Exécution locale en WebAssembly

Retracé étape par étape dans l'incident d'exemple

  1. 01Jeton exposé
  2. 02Reconnaissance auth can-i
  3. 03Secrets listés
  4. 04DaemonSet privilégié
  5. 05chroot /host
  6. 06Binding cluster-admin
  7. 07CronJob de minage

Déposez ici les logs d'audit Kubernetes

audit.log de l'API server (lignes JSON), exports EKS CloudWatch, JSON Cloud Logging GKE, logs de diagnostic AKS ou JSON Log Analytics — bruts, en .gz, dossiers entiers ou archives ZIP. Les alertes JSON Falco peuvent être ajoutées pour corrélation. Les exports de plusieurs Go sont traités en flux.

Cet exemple est un incident fictif : un token de dashboard exposé transformé en cluster-admin, puis en crypto-mineur.

Comment obtenir ces journaux

Tout s'exécute dans cet onglet de navigateur. Vos logs ne sont jamais envoyés sur un serveur.

Comment récupérer vos journaux d'audit

Choisissez où tourne le cluster. Le premier onglet est la voie la plus rapide : une commande, un fichier à déposer ici.

  1. 1. Collecterune commande ou un export
  2. 2. Déposer icifichier, dossier ou ZIP (.gz accepté)
  3. 3. Reste dans votre navigateurrien n'est envoyé

Où tourne le cluster ?

Avant de commencer : un shell sur chaque nœud du control plane avec sudo, et l'audit activé avec --audit-log-path (kubeadm, RKE2, la plupart des installations on-prem). Pour k3s, voir « Où se trouvent-ils ».

1. Sur le nœud du control plane : lisez le chemin du journal d'audit dans l'API server en cours d'exécution (processus hôte ou static pod) et copiez le journal et ses fichiers rotés dans ~/k8s-audit.

shell
PID=$(pgrep -o -f -- '--audit-log-path='); P=$(tr '\0' '\n' < /proc/$PID/cmdline | sed -n 's/^--audit-log-path=//p'); echo "$P"
mkdir -p ~/k8s-audit && sudo find "/proc/$PID/root$(dirname "$P")" -maxdepth 1 -type f -name "$(basename "${P%.*}")*" -exec cp -p {} ~/k8s-audit/ \;
sudo chown -R "$(id -u):$(id -g)" ~/k8s-audit && ls -lh ~/k8s-audit

2. Depuis votre poste : récupérez le dossier, une fois par nœud du control plane, puis déposez ici les dossiers k8s-audit-*.

shell
scp -r <user>@<control-plane-node>:k8s-audit ./k8s-audit-<node>

Pièges

  • Les journaux d'audit n'existent qu'à partir de l'activation de la journalisation, et seulement pendant la durée de rétention (fichiers rotés, rétention du groupe de journaux CloudWatch, 30 jours par défaut pour les Data Access GKE). Collectez maintenant, avant qu'ils ne disparaissent.
  • Exportez en JSON, jamais en CSV : les fichiers CSV sont refusés. Les résultats de requête sont plafonnés en taille : découpez les longues périodes en plusieurs fichiers et déposez-les ensemble.
  • Autogéré : le journal d'audit n'est lisible que par root, et chaque API server ne journalise que les requêtes qu'il a traitées. Utilisez sudo et collectez sur chaque nœud du control plane. Les horodatages sont en UTC.
Guide détaillé d'export EKS, GKE et AKS

Ce que le log d'audit Kubernetes vous apprend

Chaque requête vers l'API server Kubernetes — venant de kubectl, de contrôleurs, de kubelets ou d'un token volé — peut être enregistrée comme un événement d'audit : qui (utilisateur, groupes, compte de service), depuis où (IP sources, user agent), quoi (verbe, ressource, namespace, nom, subresource), si elle a été autorisée et pourquoi (le binding RBAC), et aux niveaux supérieurs le corps de la requête lui-même.

Cela en fait la preuve principale pour répondre à « notre cluster a-t-il été compromis ? » : un token de compte de service volé, un pod privilégié montant le nœud, un nouveau binding cluster-admin ou un CronJob de crypto-minage laissent tous des appels API, même quand les workloads eux-mêmes ont disparu.

Ce que cet outil détecte

  • Exécution : pods/exec et pods/attach (en particulier par des comptes de service), port-forward, accès kubelet via nodes/proxy.
  • Accès aux identifiants : secrets listés sur tous les namespaces, rafales de lectures de secrets, tokens de compte de service émis avec TokenRequest.
  • Élévation de privilèges et évasion de conteneur : conteneurs privilégiés, hostPID/hostNetwork/hostIPC, montages hostPath de / ou de sockets runtime, DaemonSets dans kube-system.
  • Abus RBAC : nouveaux bindings vers cluster-admin, rôles avec escalate/bind/impersonate ou wildcards, impersonation, accès accordé à des utilisateurs anonymes.
  • Reconnaissance : rafales de kubectl auth can-i (SelfSubjectAccessReviews / RulesReviews), rafales de 403, tokens de compte de service utilisés avec kubectl ou curl ou depuis des IP publiques, user agents d'outils d'attaque connus.
  • Impact et persistance : images et commandes de crypto-minage, images issues de registries inhabituels, CronJobs, événements Kubernetes supprimés. Des alertes Falco optionnelles sont corrélées sur la même chronologie.
  • Les détections sont des données : un fichier de règles JSON revu (conditions de type Sigma) cartographié sur la matrice MITRE ATT&CK Containers, afin d'être lisible, auditable et réutilisable.

Comment exporter les logs d'audit Kubernetes

La journalisation d'audit doit être activée avant un incident pour être utile. Exportez toute la période concernée (idéalement quelques jours avant le premier événement suspect) en JSON ; gzip et ZIP conviennent.

Self-managed (kubeadm, k3s, RKE2, on-prem)

  1. L'API server écrit des événements d'audit lorsqu'il est démarré avec --audit-policy-file et --audit-log-path (par exemple /var/log/kubernetes/audit/audit.log).
  2. Sur chaque nœud control-plane, copiez l'audit.log actuel et ses fichiers de rotation (audit-*.log, éventuellement .gz).
  3. Si vous transmettez les événements d'audit via un backend webhook (Fluent Bit, Vector, un SIEM), exportez-les depuis cet outil en lignes JSON.
  4. Déposez ici les fichiers ou le dossier entier.

Amazon EKS

  1. La journalisation du control plane doit inclure le type de log « audit » (console EKS → cluster → Observability → Control plane logging).
  2. Les événements se trouvent dans CloudWatch Logs, groupe de logs /aws/eks/<cluster>/cluster, flux kube-apiserver-audit-*.
  3. Petites périodes : aws logs filter-log-events --log-group-name /aws/eks/<cluster>/cluster --log-stream-name-prefix kube-apiserver-audit --start-time <ms> --end-time <ms> > eks-audit.json
  4. Grandes périodes : créez une tâche d'export vers S3 (aws logs create-export-task), téléchargez les fichiers .gz et déposez le dossier. Les résultats CloudWatch Logs Insights exportés en JSON fonctionnent aussi.

Google GKE

  1. Les logs d'audit Admin Activity sont toujours actifs ; les logs Data Access (get/list, lectures de secrets) doivent être activés pour l'API Kubernetes Engine dans IAM → Audit Logs.
  2. Exportez avec gcloud : gcloud logging read 'resource.type="k8s_cluster" AND logName:"cloudaudit.googleapis.com"' --project=<project> --freshness=30d --format=json > gke-audit.json
  3. Ou téléchargez les résultats depuis Logs Explorer en JSON, ou utilisez un sink de logs vers Cloud Storage / BigQuery pour de longues périodes (exportez les lignes BigQuery en JSON ou JSON délimité par des sauts de ligne).
  4. Déposez ici les fichiers JSON ; les entrées d'autres services sont ignorées.

Azure AKS

  1. Créez un diagnostic setting sur le cluster avec la catégorie kube-audit (ou kube-audit-admin, qui exclut get/list).
  2. Destination compte de stockage : téléchargez les blobs PT1H.json sous insights-logs-kube-audit/… et déposez le dossier.
  3. Destination Log Analytics : interrogez AKSAudit (ou AzureDiagnostics | where Category startswith "kube-audit") et exportez les résultats en JSON, pas en CSV.
  4. Les exports Event Hubs ({"records": […]}) sont également pris en charge.

Assurez-vous que la preuve existe

  • Journalisez au minimum Metadata pour tout, et Request ou RequestResponse pour les objets RBAC, les pods, les workloads, pods/exec et serviceaccounts/token : sans le corps des requêtes, les pods privilégiés et les bindings cluster-admin ne peuvent pas être reconnus.
  • Ne journalisez jamais le corps des secrets, configmaps ou tokenreviews (Metadata uniquement) : le log deviendrait un magasin d'identifiants.
  • Conservez les logs d'audit en dehors du cluster, pendant au moins 90 jours : un attaquant disposant de cluster-admin peut altérer tout ce qui se trouve à l'intérieur.

Limites

  • Le log d'audit ne voit que l'API server : l'activité à l'intérieur d'un conteneur ou sur un nœud (un reverse shell, un mineur lancé à la main) est invisible sans outils runtime tels que Falco.
  • Ce qui est détecté dépend de votre politique d'audit : au niveau Metadata, le corps des requêtes (flags privileged, images, roleRef) est absent et plusieurs détections ne peuvent pas se déclencher.
  • Les règles signalent des schémas, pas des intentions : des admins légitimes exécutent aussi kubectl exec, et des opérateurs créent des DaemonSets. Chaque constat nécessite une revue humaine.
  • Seuls les exports JSON sont lus (les exports CSV ne sont pas encore pris en charge). Les noms de comptes de service de vos propres composants de plateforme peuvent devoir être ajoutés aux listes d'exclusion des règles.

FAQ

Mes logs d'audit sont-ils envoyés quelque part ?

Non. L'analyseur est écrit en Rust, compilé en WebAssembly, et s'exécute dans un Web Worker de votre navigateur ; les fichiers sont lus depuis votre disque par flux, en morceaux. Il n'y a aucun point de terminaison d'envoi.

Quelle taille d'export peut-il traiter ?

Les fichiers sont lus et décompressés en flux, donc la taille est surtout limitée par le temps : comptez de quelques dizaines à quelques centaines de Mo par minute selon votre machine. Les petits exports gardent chaque événement consultable ; au-delà de 50 000 événements, seuls les événements signalés sont conservés, tandis que les compteurs, entités et constats couvrent toujours l'ensemble.

Quels formats sont pris en charge ?

JSON brut audit.k8s.io/v1 en lignes, exports EKS CloudWatch (filter-log-events, JSON Logs Insights, fichiers d'export S3), JSON Cloud Logging GKE (gcloud logging read, téléchargements Logs Explorer, sinks), logs de diagnostic AKS (compte de stockage, Event Hubs, JSON AKSAudit / AzureDiagnostics), gzip et ZIP, ainsi que les alertes JSON Falco.

Comment détecter kubectl exec dans les logs d'audit ?

kubectl exec crée une requête sur la subresource pods/exec (verbe create ou get, objectRef.subresource exec) ; la commande figure dans le requestURI en paramètres command=. Cet outil liste chaque exec, attach et port-forward, et augmente la sévérité lorsqu'un compte de service en est à l'origine.

« Aucun signe de compromission » signifie-t-il que nous sommes en sécurité ?

Non. Cela signifie qu'aucune règle ne s'est déclenchée dans les logs fournis. Des lacunes dans la politique d'audit, des périodes manquantes et une activité à l'intérieur des conteneurs peuvent toutes masquer une intrusion. Si vous avez d'autres raisons de vous inquiéter, obtenez une revue d'expert.

Puis-je voir ou réutiliser les règles de détection ?

Oui. Ce sont des fichiers JSON dans le dépôt ouvert (crates/k8s-audit-wasm/rules), avec conditions, seuils, identifiants de technique MITRE ATT&CK et étapes de remédiation, afin d'être revus et réutilisés dans d'autres outils.

Ce que les logs d'audit Kubernetes ne montrent pas
Angles morts des logs d'audit Kubernetes : activité dans les conteneurs, kubelet et etcd, trous de politique, champs falsifiables, et preuves complémentaires.
audit-logsincident-responseaudit-policydetection
Attaque Kubernetes pas à pas : un incident fictif
Incident Kubernetes fictif pas à pas dans le log d'audit : token de dashboard exposé, recon can-i, vol de secrets, DaemonSet privilégié, cluster-admin, XMRig.
incident-responseaudit-logsdetectiontutorial
Crypto-minage dans Kubernetes : le détecter dans les logs
Détecter le crypto-minage dans Kubernetes via les logs d'audit : images et arguments de mineurs, registries inhabituels, persistance CronJob et DaemonSet.
detectioncryptominingaudit-logsmitre-attack

Cet outil n'est ni affilié à The Linux Foundation, à la Cloud Native Computing Foundation (CNCF) ou au projet Kubernetes, ni approuvé ni sponsorisé par eux. Kubernetes et K8s sont des marques déposées de The Linux Foundation. EKS, GKE, AKS et les autres noms sont des marques de leurs propriétaires respectifs.