Skip to main content
Every administrative change in Ankra is recorded in the organisation Audit Log. It is the platform’s system of record for governance questions: who invited that member, who approved that deployment, who accepted that CVE as risk, and when.

​
What is recorded

Each entry captures:
  • Who - the actor (a member, or a token acting on their behalf)
  • What - the action and the resource it touched, with structured details of the change
  • When - the timestamp
  • Where from - the source IP
Administrative changes across the platform write entries: invitations and role assignments, cluster-group edits, credential changes, cluster lifecycle operations, security disposition changes, and organisation settings edits. Entries are append-only - they cannot be edited or deleted - and they are written for every change regardless of who can view the log.

​
Who can see it

Viewing the audit log requires the audit read permission, held by owners and admins by default. It can also be granted to custom roles, so a compliance or security function can review the log without broader administrative access.

​
Reading and filtering

Open Organisation → Settings → Audit Log. From there you can:
  • Search entries by keyword
  • Filter by user, action type, cluster, resource type, and date range
  • Expand an entry to see the structured details of the change
Every entry names the cluster it belongs to, and the name links straight to that cluster’s own Audit tab. Organisation-level events - sign-ins, invitations, role changes - show no cluster. A cluster you have since deleted keeps its name in the trail, marked deleted: the record outlives the cluster, which is exactly what makes the deletion itself auditable. The cluster filter is carried in the page URL, so a view narrowed to one cluster can be bookmarked or shared as a link.

​
Per-cluster view

Each cluster carries its own slice of the trail: the Audit tab in cluster Settings shows only the manual actions performed on that cluster - lifecycle operations, scaling, node restarts, and stack changes - with the same permission gate and entry format. See Cluster Settings → Audit. The two views are connected in both directions. From the organisation log, a row’s cluster takes you into that cluster’s tab; from the tab, View in organisation audit log takes you back to the full trail with that cluster preselected as the filter - the same entries, alongside the organisation-level events the tab leaves out.

​
Exporting

Export the current filtered view to CSV or JSON, from the portal or through the API for scheduled evidence jobs. The download honours the filters on screen, including the cluster filter, and the export rows carry the cluster alongside the actor and action. A cluster’s Audit tab exports through the same path, so a per-cluster download and the organisation view filtered to that cluster contain the same entries. A single export returns up to 100,000 rows and signals truncation when more rows match. See Audit Export for the full column list, the API parameters, and how to forward the trail to a SIEM.

​
Retention

Audit entries are retained for 365 days, after which older rows are removed by a background retention job. Entries inside the window are immutable. If your framework requires a longer trail, export on a schedule into storage you control - the platform is not intended to be your long-term system of record.

​
Relationship to Git history

Ankra gives you two complementary trails:
  • The audit log records platform actions - who signed in, assigned a role, approved a plan, or changed a disposition.
  • Git history records desired-state changes as attributed commits - exactly what changed in your cluster definitions and Stacks, and when it was deployed.
Together they answer both “who did what in the platform” and “what actually changed in the cluster”. For how commits are produced and attributed, see GitOps.

Roles & Access

Grant the audit read permission via custom roles.

GitOps

The attributed commit trail for desired-state changes.

Security at Ankra

How the audit log fits the wider control set.

Cluster Security

Disposition changes that land in the audit log.