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. Kubernetes access is recorded too: cluster access grants and their changes, every kube token minted (including the one behind each generated kubeconfig), every pod terminal session, whose entry links to a recording of the session, and every reveal of a Kubernetes Secret’s values (action reveal, resource type kubernetes_secret, naming the cluster, namespace, Secret and key names, never the values). Other individual Kubernetes API calls are not in this log; your cluster’s own audit policy records those. Cluster access grants are recorded as cluster_access_grant_created, cluster_access_grant_extended and cluster_access_grant_deleted, and each grant entry records the authority: the permission the grant was made under, kube_access.manage or, for a break-glass elevation by a caller that holds only the break-glass permission, kube_access.elevate. Every change to the organisation access policy is recorded as cluster_access_policy_updated. Entries are append-only - nobody in your organisation can edit or delete them, and only the retention job removes them - 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 → 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.

​
Standard changes

Entries for changes Ankra makes to a cluster also record which kind of change they were. A change that matches the standard-change catalogue - an add-on upgrade that fixes a published security advisory, a Kubernetes patch upgrade, autoscaling within your limits, a scheduled power action, access expiry - is marked as a pre-approved standard change, with the catalogue entry and the reason it qualified. The cluster Audit tab shows it as Pre-approved SC-01 (or the matching ID) beside the action; the full record is under change_classification in the entry’s details. Entries without that record are normal changes, or events that are not changes at all. See Change Management for the catalogue and for how to require approval for every change instead.

​
Exporting

Export the current filtered view to CSV or JSON from the portal. 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 and how to get the trail into 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.

Change Management

Pre-approved standard changes and how they are recorded.

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.