TL;DR. Exportez les logs d'audit de votre API server en JSON, déposez-les (fichiers, dossiers, ZIP ou .gz) sur l'analyseur de logs d'audit Kubernetes, puis lisez la page de haut en bas : fichiers lus, verdict, constats, chronologie, entités, checklist de remédiation, table des événements. Tout tourne localement dans un Web Worker compilé de Rust vers WebAssembly ; rien n'est envoyé. Traitez chaque constat comme une piste à confirmer avec les propriétaires de l'identité, pas comme une conclusion.

Ce guide déroule une vraie séance de tri avec l'outil, panneau par panneau, et explique les choix de conception à connaître pour interpréter le résultat.

Avant de commencer : obtenir le bon export

L'analyseur ne lit que du JSON. Entrées prises en charge :

Source	Formats
Autogéré (kubeadm, k3s, RKE2…)	Lignes JSON `audit.log` et fichiers rotés, exports webhook ou d'agent d'expédition en lignes JSON
Amazon EKS	Sortie de `aws logs filter-log-events`, JSON de Logs Insights, fichiers d'export CloudWatch vers S3, `logEvents` Firehose
Google GKE	`gcloud logging read --format=json`, téléchargements JSON de l'Explorateur de journaux, fichiers de sink
Azure AKS	Blobs `PT1H.json` de compte de stockage, `records` Event Hubs, lignes `AKSAudit` / `AzureDiagnostics` exportées en JSON
Runtime (optionnel)	Alertes Falco en JSON, pour la corrélation sur la même chronologie

Gzip et ZIP (y compris imbriqués) sont lus en flux : les exports de plusieurs gigaoctets fonctionnent, la limite est le temps, pas la mémoire. Les exports CSV de Log Analytics ou de Logs Insights ne sont pas encore pris en charge : exportez en JSON. Le guide d'export EKS, GKE et AKS donne les commandes.

Pour vous entraîner d'abord, cliquez sur Essayer un exemple. Cela charge un incident fictif clairement signalé comme tel, décrit en détail dans le déroulé de l'incident fictif.

Étape 1 : charger les fichiers

Déposez des fichiers ou un dossier entier sur la zone de dépôt, ou utilisez Choisir des fichiers / Choisir un dossier. Une ligne de progression indique le fichier en cours, les octets traités et le nombre d'événements. Vous pouvez annuler à tout moment.

En coulisse, un découpeur JSON en flux lit les enregistrements un par un, que le fichier soit en lignes JSON, un grand tableau ou une enveloppe cloud, et chaque enregistrement est normalisé dans un modèle d'événement unique. Les stages d'une même requête sont regroupés en un seul événement : un kubectl exec n'est compté qu'une fois, même quand la politique journalise à la fois ResponseStarted et ResponseComplete.

Étape 2 : vérifier ce qui a réellement été lu

Avant de faire confiance à un verdict, descendez jusqu'à Fichiers lus et Fichiers ignorés :

Chaque fichier ignoré est accompagné d'une raison : vide, uniquement des zéros (copie incomplète), export CSV, pas du JSON, gzip ou ZIP endommagé.
Chaque fichier affiche ses enregistrements, ses événements, et des notes pour les enregistrements malformés, tronqués ou non reconnus.
Les statistiques en haut donnent les horodatages De et À et les sources détectées (log d'audit, EKS, GKE, AKS, Falco).

Si la plage horaire ne couvre pas la période qui vous intéresse, arrêtez-vous et exportez davantage. Si un fichier ne contient que « d'autres types de logs », vous avez probablement exporté le mauvais flux CloudWatch ou la mauvaise table Log Analytics.

Étape 3 : lire le verdict

Le verdict est l'un des suivants :

Compromission probable : au moins une détection critique, ou trois détections élevées différentes.
Activité suspecte : au moins une détection élevée, ou deux détections moyennes différentes.
Aucun signe de compromission : rien au-dessus de ce seuil.
Aucun événement d'audit trouvé : les fichiers ne contenaient pas d'événements d'audit Kubernetes.

La ligne Pourquoi liste les détections qui ont déterminé le verdict. Les seuils sont volontairement simples, pour que vous puissiez les expliquer dans un rapport. « Aucun signe de compromission » signifie seulement qu'aucune règle n'a matché dans les données fournies : l'article sur les limites explique ce qui peut se cacher dans les angles morts.

Étape 4 : examiner chaque constat

Chaque constat est une règle de détection qui a matché, regroupée par identité ou par objet (par exemple, un constat par compte de service pour l'exec, un par image pour les mineurs). Un constat affiche :

le titre de la règle, la sévérité, la tactique ATT&CK et les identifiants de technique ;
la première et la dernière occurrence, et le nombre d'événements ;
les objets et IP sources concernés ;
pour les règles à seuil (rafales de lectures de secrets, auth can-i, 403), le seuil déclenché, par exemple « 10 ou plus en 10 min ».

Cliquez sur Afficher les événements pour ouvrir la table des événements filtrée. Posez ensuite la question implicite de chaque règle : existe-t-il une explication légitime ? Un admin qui lance kubectl exec pendant une panne connue, c'est normal ; le même admin à 3 heures du matin depuis un nouveau pays, non. Les règles sont des données, dans un fichier JSON relu du dépôt du projet, et les articles de détection expliquent chaque famille.

Étape 5 : suivre la chronologie

La Chronologie de l'incident liste les événements signalés dans l'ordre chronologique. Les lignes en gras marquent la première fois qu'une détection se déclenche : dans une vraie intrusion, elles se lisent comme les chapitres de l'attaque (accès, reconnaissance, vol d'identifiants, élévation, persistance, impact). Cochez Inclure les événements de faible sévérité pour ajouter du contexte, comme les nouveaux ClusterRoleBindings ou les images issues de registries inhabituels.

Basculez entre UTC et Local avec le sélecteur de fuseau horaire. Restez en UTC pour tout ce que vous consignez.

Étape 6 : pivoter sur les entités

Le panneau Entités répond à « qui a fait quoi, d'où » :

Utilisateurs & comptes de service, avec le nombre d'événements, de signalés et de refusés, première et dernière apparition ;
IP sources, avec un badge publique pour les adresses Internet ;
Namespaces, Pods (avec le nombre de sessions exec), Images et User agents.

Cliquez sur une valeur pour filtrer la table des événements. Le pivot classique : du compte de service signalé vers ses IP sources, puis de ces IP vers toutes les autres identités qu'elles ont utilisées. Une IP qui s'est authentifiée avec deux comptes de service différents dans la même minute, c'est une personne qui détient deux tokens volés.

Étape 7 : creuser les événements

La table des événements se filtre par détection, sévérité minimale, signalés uniquement et texte libre (utilisateur, IP, objet, commande). Cliquez sur une ligne pour la fiche détaillée : utilisateur et groupes, utilisateur usurpé, IP sources, user agent, verbe et objet, URI de requête, commande exec, images, code de réponse, décision et raison d'autorisation, stage et niveau, audit ID, fichier source et, s'il est journalisé, le corps de la requête.

Jusqu'à 50 000 événements, tout reste consultable. Au-delà, la table ne garde que les événements signalés, tandis que les compteurs, les entités et les constats couvrent toujours l'ensemble des données.

Étape 8 : exporter et remédier

CSV exporte les événements filtrés (les cellules qui pourraient être interprétées comme des formules de tableur sont neutralisées).
Rapport JSON exporte le verdict, les constats, les entités et la liste de remédiation pour votre dossier.

La Checklist de remédiation est construite à partir des constats et ordonnée par urgence : préserver les preuves et délimiter d'abord, puis révoquer les tokens, supprimer les bindings, supprimer les workloads malveillants, reconstruire les nœuds, faire tourner les secrets et durcir. Cocher un élément ne sauvegarde rien : recopiez la liste dans votre outil de tickets. Le bloc Que faire ensuite ne renvoie qu'à des recommandations officielles de kubernetes.io et des fournisseurs cloud.

Pièges fréquents

Les logs d'un seul nœud du plan de contrôle. Chaque instance d'API server journalise ce qu'elle a servi. Collectez-les toutes.
Politique en Metadata uniquement. Les pods privilégiés et les bindings cluster-admin ne sont reconnus qu'avec les corps de requête ; voir le guide de la politique d'audit.
Composants de plateforme signalés. Les règles excluent les contrôleurs Kubernetes et les agents cloud courants ; vos propres opérateurs (GitOps, sauvegarde, service mesh) peuvent encore déclencher des constats d'exec ou de DaemonSet. Vérifiez, puis notez-les comme légitimes.
Plage horaire trop courte. Si le premier événement signalé est au tout début de l'export, exportez des données plus anciennes.

Analyser des logs d'audit Kubernetes dans le navigateur