How to Analyze Kubernetes Audit Logs in Your Browser

TL;DR. Export your API server audit logs as JSON, drop them (files, folders, ZIP or .gz) on the Kubernetes audit log analyzer, and read the page from top to bottom: files read, verdict, findings, timeline, entities, remediation checklist, events table. Everything runs locally in a Web Worker compiled from Rust to WebAssembly; nothing is uploaded. Treat each finding as a lead to confirm with the people who own the identity, not as a conclusion.

This guide walks through a real triage session with the tool, panel by panel, and explains the design choices you should know about when you interpret the output.

Before you start: get the right export

The analyzer reads JSON only. Supported inputs:

Gzip and ZIP (including nested ZIPs) are read as streams, so multi-gigabyte exports work; time is the limit, not memory. CSV exports from Log Analytics or Logs Insights are not supported yet: export as JSON. The EKS, GKE and AKS export guide has the commands.

If you want to practise first, click Try a sample. It loads a clearly labelled fictional incident, walked through in detail in the fictional incident walkthrough.

Step 1: load the files

Drop files or a whole folder on the drop zone, or use Choose files / Choose a folder. A progress line shows the file being read, the bytes processed and the number of events. You can cancel at any time.

Behind the scenes, a streaming JSON splitter reads records one by one, whether the file is JSON lines, one big array or a cloud envelope, and each record is normalised into a single event model. Stages of the same request are folded into one event, so a kubectl exec is counted once even when the policy logs both ResponseStarted and ResponseComplete.

Step 2: check what was actually read

Before trusting any verdict, scroll to Files read and Skipped files:

• Every skipped file comes with a reason: empty, zeros only (incomplete copy), CSV export, not JSON, damaged gzip or ZIP.
• Each file shows records, events, and notes for malformed, truncated or unrecognised records.
• The stats at the top give the From and To timestamps and the detected sources (Audit log, EKS, GKE, AKS, Falco).

If the time range does not cover the period you care about, stop and export more. If a file shows only "other log types", you probably exported the wrong CloudWatch stream or Log Analytics table.

Step 3: read the verdict

The verdict is one of:

• Likely compromised: at least one critical detection, or three different high-severity detections.
• Suspicious activity: at least one high detection, or two different medium detections.
• No sign of compromise: nothing above that bar.
• No audit events found: the files did not contain Kubernetes audit events.

The Why line lists the detections that drove the verdict. The thresholds are deliberately simple so you can explain them in a report. "No sign of compromise" only means none of the rules matched the data you provided: the limitations article explains what can hide in the gaps.

Step 4: review each finding

Each finding is a detection rule that matched, grouped by the identity or object involved (for example, one finding per service account for exec, one per image for miners). A finding shows:

• the rule title, severity, ATT&CK tactic and technique IDs;
• the first and last time it matched and the number of events;
• the objects and source IPs involved;
• for threshold rules (bursts of secret reads, auth can-i, 403s), the threshold that fired, such as "10 or more within 10 min".

Click Show the events to jump to the filtered events table. Then ask the question every rule implies: is there a legitimate explanation? An admin running kubectl exec during a known outage is fine; the same admin at 3 a.m. from a new country is not. The rules are data, in a reviewed JSON file in the project repository, and the detection articles explain each family.

Step 5: follow the timeline

The Incident timeline lists flagged events in chronological order. Lines in bold are where a detection fires for the first time: in a real intrusion they usually read like the attack's chapters (access, recon, credential theft, escalation, persistence, impact). Tick Include low-severity events to add context such as new ClusterRoleBindings or images from unusual registries.

Switch between UTC and Local time with the time-zone toggle. Keep UTC for anything you write down.

Step 6: pivot on entities

The Entities panel answers "who did what, from where":

• Users & service accounts, with event, flagged and denied counts, first and last seen;
• Source IPs, with a public badge for internet addresses;
• Namespaces, Pods (with the number of exec sessions), Images and User agents.

Click any value to filter the events table to it. The classic pivot: from the flagged service account to its source IPs, then from those IPs to every other identity they used. An IP that authenticated as two different service accounts in the same minute is one person holding two stolen tokens.

Step 7: dig into the events

The events table filters by detection, minimum severity, flagged only and free text (user, IP, object, command). Click a row for the detail sheet: user and groups, impersonated user, source IPs, user agent, verb and object, request URI, the exec command, images, response code, authorization decision and reason, stage and level, audit ID, source file and, when logged, the request body.

For exports up to 50,000 events, every event stays browsable. Above that, the table keeps only flagged events, while counts, entities and findings still cover the whole input.

Step 8: export and remediate

• CSV exports the filtered events (cells that could be read as spreadsheet formulas are neutralised).
• JSON report exports the verdict, findings, entities and remediation list for your case file.

The Remediation checklist is built from the findings and ordered by urgency: preserve evidence and scope first, then revoke tokens, remove bindings, delete malicious workloads, rebuild nodes, rotate secrets, and harden. Nothing is saved when you tick items, so copy it into your ticketing system. The What to do next block links only to official guidance from kubernetes.io and the cloud providers.

Common pitfalls

• Only one control-plane node's logs. Each API server instance logs what it served. Collect all of them.
• Metadata-only policy. Privileged pods and cluster-admin bindings need request bodies to be recognised; see the audit policy guide.
• Platform components flagged. The rules allow-list Kubernetes controllers and common cloud agents; your own operators (GitOps, backup, service mesh) may still trigger exec or DaemonSet findings. Verify, then note them as known-good.
• Time range too short. If the first flagged event is at the very start of your export, export earlier data.

Related articles

• Kubernetes incident response with audit logs
• Fictional incident walkthrough: from dashboard token to crypto-miner
• EKS, GKE and AKS audit logs: enable and export