Audit Export

Export the organisation audit trail as CSV or JSON, forward it to your SIEM or evidence store, and keep records beyond the platform retention window.

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:

Column	Contents
created_at	UTC timestamp of the action
user_email	The acting member’s email address
user_id	The acting member’s stable identifier
action_type	What was done, for example a role assignment or credential change
resource_type	The kind of resource acted on
resource_id	The specific resource
ip_address	Source IP the action came from
cluster_id	The cluster the action applied to, where the action is cluster-scoped
cluster_name	That cluster’s name at export time
details	Structured detail of the change, as compact JSON

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.

curl -sS \
  -H "Authorization: Bearer <your-token>" \
  "https://platform.ankra.app/org/organisation/audit-logs/export?format=csv&start_date=2026-07-01&end_date=2026-07-31" \
  -o audit-log-july.csv

Supported query parameters mirror the viewer’s filters:

Parameter	Purpose
format	csv (default) or json
start_date / end_date	Bound the window, as dates
user_id	Limit to one member
cluster_id	Limit to one cluster
action_type	Limit to one kind of action
resource_type	Limit to one kind of resource
search	Free-text match

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:

response_headers=$(mktemp)
curl -sS -D "$response_headers" \
  -H "Authorization: Bearer <your-token>" \
  "https://platform.ankra.app/org/organisation/audit-logs/export?format=csv&start_date=2026-07-01&end_date=2026-07-31" \
  -o audit-log-july.csv

if grep -qi "^x-ankra-export-truncated: true" "$response_headers"; then
  echo "Export truncated - narrow the window and re-run" >&2
  exit 1
fi

---

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.

---

Related

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.