Docs

Audit Log

What this screen is for

The audit log records what people did through Cluster Console — and, just as importantly, what they were refused. Because Cluster Console acts directly on live clusters, this is the record that makes that acceptable.

Before you start

To do this You need
Open the audit log cluster-console.read

Opening it

Direct URL: /cluster-console/audit

The interface

📸 Screenshot Placeholder: The audit log with several entries, one of them refused. Mark: (1) the When column, (2) the Outcome column with a refused entry, (3) Action, (4) User, (5) Cluster, (6) Target, (7) Reason.

Column What it tells you
When Time of the attempt
Outcome Whether it succeeded or was refused
Action Which action was attempted
User Who attempted it
Cluster Which cluster
Target Which resource
Reason Why it was refused — shown on the refused entry

The Outcome and Reason pair is what makes this more than a change log. A refused entry tells you someone tried something and a guardrail or a permission stopped them, which is worth knowing whether it was a mistake or a signal that someone’s access is wrong for their job.

Walkthroughs

Find out who changed something

  1. Open the audit log.
  2. Look for the resource in Target around the time the change appeared.
  3. User and Action give you the answer.

Understand a refusal

Find the refused entry and read Reason. It distinguishes the two cases that look identical to the person who hit them:

  • A guardrail — the namespace or kind is protected.
  • A permission — they lack the grant for that action.

The fix is different for each, so read the reason before acting on a report.

Review activity after an incident

Filter to the cluster and the window around the incident. The combination of successful and refused entries usually reconstructs what someone was trying to do, which is more useful than either on its own.

Scenario

Something changed in production and nobody has owned up.

  1. Open the audit log and find the resource in Target, around the time the behaviour changed.
  2. If there is a matching entry, User and Action answer the question directly, and you are done.
  3. If there is no entry, that is itself informative: the change did not come through Cluster Console. Look at Deployments for a release, or the environment’s Events tab for a reconcile.
  4. While you are there, scan for refused entries on the same resource. A refusal shortly before the change often shows someone trying one route, being stopped, and taking another.
  5. If the refusals show someone repeatedly blocked from something their job needs, that is a permissions finding, not a discipline one. Fix it in People & Access.

Step 3 is the part people miss. An empty audit log is not “no answer” — it rules out an entire route and points you at the other two.

When it doesn’t work

Symptom Cause How to check Fix
Cannot open the audit log Missing cluster-console.read Access Explorer Ask for a role granting it
No entry for a change you know happened It did not go through Cluster Console Deployments, or the environment’s Events tab Look on the route that actually made it
Many refused entries from one user Their permissions do not match their job The Reason column Adjust their role, or explain the guardrail
A refusal says “protected” A guardrail, not a permission gap The Reason text Needs cluster-console.protected.override, or a safer route
Entries are missing for another cluster Cluster visibility is decided per cluster — Expected; ask for access to that cluster

Next