Skip to main content
The Audit Log is Ankra’s append-only record of every administrative change. Export takes that record out of the platform so you can retain it on your own terms, feed it to a SIEM, or attach it to an audit response. Exporting is the mechanism that turns the audit log from a troubleshooting view into compliance evidence, because evidence has to outlive the platform’s retention window and live somewhere your assessor can reach.

​
What the export contains

Each row is one audit entry, with the same fields the audit viewer shows: In CSV the details column holds a JSON document, so keep the file quoted and parse it with a real CSV reader rather than splitting on commas - the details routinely contain commas and newlines. Cell values that would otherwise be interpreted as formulas by a spreadsheet application are neutralised before they are written, so opening an export in a spreadsheet does not execute anything an actor put in a resource name.

​
Permissions

Export is gated by the same audit read permission as the audit viewer, held by owners and admins by default and available to custom roles. A caller without it receives a 403 naming the missing permission. Granting the audit read permission to a compliance or security function lets them pull evidence themselves without broader administrative access, which is usually what you want.

​
Exporting from the portal

1

Open the audit log

Go to Organisation → Settings → Audit Log.
2

Filter to the evidence you need

Narrow by user, action type, resource type and date range. The export follows the filters currently applied, so filter first.
3

Export

Choose the CSV or JSON export action. The file downloads with the organisation and date in its name, for example audit-log-<organisation-id>-2026-08-13.csv.

​
Exporting via the API

The same export is available to scripts and scheduled jobs, which is how most teams feed a SIEM. Authenticate with an API token belonging to a member who holds the audit read permission.
Supported query parameters mirror the viewer’s filters: Full request and response detail is in the API Reference tab.

​
Row cap and truncation

A single export returns at most 100,000 rows. When more rows match your filters, the export is truncated to the newest ones and says so:
  • CSV responses set the X-Ankra-Export-Truncated: true response header.
  • JSON responses carry a truncated member in the document.
Truncation is silent if you only look at the file. A monthly export of a busy organisation can exceed the cap without any visible sign in the CSV itself. Always check the header or the JSON member, and narrow the date window until the export comes back complete.
A scheduled job should check for truncation and split the window rather than assume a complete pull:

​
Retention, and why you export

Audit entries are retained for 365 days by default, after which older rows are removed by a background retention job. If your framework requires a longer trail - and most do, with ISO/IEC 27001 and many SOC 2 programmes expecting multi-year retention - the platform is not your system of record. Export on a schedule into storage you control, with the retention and immutability your policy requires.
A monthly scheduled export into write-once object storage is usually enough to satisfy retention and integrity expectations at once, and it gives you evidence that survives any change to the platform.

​
Forwarding to a SIEM

The export is a pull interface rather than a push integration, so the pattern is a scheduled job that pulls a window and forwards it.
1

Create a dedicated token

Issue an API token for a member whose role grants audit read and nothing else. Do not reuse an administrator’s token for automation.
2

Pull a bounded window on a schedule

Run daily or hourly with explicit start_date and end_date, rather than pulling everything each time. Bounded windows keep you under the row cap and make gaps visible.
3

Check for truncation

Fail the job on a truncated response instead of forwarding a partial file.
4

Forward and retain

Ship the rows to your SIEM and keep the raw file in your evidence store. Keep both - the SIEM is for detection, the file is for the assessor.
Run this as a pipeline agent or any scheduled runner that can reach the platform API.

​
What the audit log does not cover

Being clear about the boundary saves you from over-claiming in an audit response.
  • Kubernetes-level activity is not in the audit log. Actions taken directly against your cluster’s API server - by any tool, including kubectl through Ankra’s proxy - are recorded by your cluster’s own Kubernetes audit policy, not by Ankra. Enable Kubernetes audit logging separately if you need that trail.
  • Desired-state changes live in Git. What changed in a cluster definition, and who committed it, is in your repository’s history as attributed commits. The audit log records the platform action, and Git records the content of the change. See GitOps.
  • Data-plane activity is not recorded. Ankra is not in your application’s request path and has no view of it.
Together the audit export, your Git history and your Kubernetes audit log cover platform actions, configuration changes and cluster API activity respectively. An assessor asking “who changed this cluster” is usually satisfied by the first two.

Audit Log

Read and filter the trail in the platform.

Compliance Management

The organisation compliance report and benchmark results.

Roles & Access

Grant audit read to a compliance function.

Shared Responsibility

Where this evidence fits in your certification.