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: A reveal of a Kubernetes Secret’s values is one row per Secret: action_type reveal, resource_type kubernetes_secret, resource_id <namespace>/<name>, the cluster_id, and details holding the namespace, the Secret name, its key names and surface (portal for the console, api for an API token). The values themselves are never written. Filter on resource_type=kubernetes_secret to list who read which Secret. 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 audit.read to a compliance or security function lets them pull evidence themselves without broader administrative access, which is usually what you want. An API token calling the export needs the same permission: the role behind the token (the service account’s role, or the owner’s role for a personal token) must hold audit.read, and a token restricted to a list of scopes must include it.

​
Exporting from the portal

1

Open the audit log

Go to Organisation → 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 for automation

Scripts, scheduled jobs and SIEM collectors call the token route of the same export:
It accepts a service token or a personal API token as a bearer credential, and takes the same filters, formats and row cap as the portal download. The export is scoped to the token’s organisation.
-f makes curl fail on a 401 or 403 instead of writing the error body to the file. A token without audit.read receives a 403 naming the missing permission.
Use the /api/v1/... path above. The portal’s own route, /org/organisation/audit-logs/export, accepts a signed-in browser session only: a request carrying a bearer token is redirected to the sign-in page rather than refused, which looks like success unless you check the file.

​
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.
When the export is truncated, narrow the date window and export again until it comes back complete.

​
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 regularly into storage you control, with the retention and immutability your policy requires: for example a scheduled daily token export into write-once object storage.

​
Forwarding to a SIEM

There is no push integration: your SIEM pulls. Run a scheduled job that exports a bounded window with a service token and hands the file to your SIEM’s ingestion, and keep the raw file in your evidence store as well - the SIEM is for detection, the file is for the assessor.
1

Create a role that can only read the audit log

In Organisation → Roles, create a custom role holding audit.read and nothing else.
2

Mint a service token with that role

Create a service token named after the job, for example siem-audit-export, with the role from the previous step, and store it in your scheduler’s secret store.
3

Schedule the export

Pull one closed window per run - yesterday, in UTC - so every row arrives exactly once. Both window bounds are inclusive, so end the window one microsecond before midnight rather than at midnight.
A daily GitHub Actions job, as an example. It uses GNU date, as on GitHub-hosted Linux runners; the last step is a placeholder for your SIEM’s ingestion:
The JSON document is {"entries": [...], "truncated": false}, newest entry first, with the columns listed above as fields of each entry. Failing the job on truncated matters: a truncated window silently drops its oldest rows.

​
What the audit log does not cover

Being clear about the boundary saves you from over-claiming in an audit response.
  • Individual Kubernetes API calls are not in the audit log. Ankra records who was given Kubernetes access (grant changes, kubeconfig generation, token minting), every pod terminal session, with a transcript, and every reveal of a Secret’s values through the console or the API. Individual calls made 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. 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.