Attestkeep docs

Using the console

What each screen does, in the order you meet them. The screenshots are the real console; your own numbers will differ.

The security overview

The dashboard is the posture of one cluster at a glance: operator health, the admission webhook's state, the database, and the vulnerability feed — then the counts that matter, image coverage, what was blocked, and where you stand against your monthly image band.

The security overview: health tiles across the top, coverage and quota counts below, a severity trend and a compliance donut.
The overview warns you before any of these becomes an incident: a webhook failing open, a single operator replica, a licence certificate inside its final week, a workload running that admission never saw.

Policies — what admission allows

A policy is the rule admission applies: which severities deny, whether a signature and an attestation are required, whether :latest and floating tags are allowed, and whether the whole policy runs in enforce (deny for real) or audit (record what it would have denied, deny nothing). One policy is the cluster-wide default; others bind to a namespace. The list is the whole rule set at a glance.

The policies list: a cluster-wide default in enforce mode and a namespace policy in audit mode, each with its rule summary and required supply-chain checks; a break-glass banner is active on a third policy.
Each row states the mode, the namespaces it covers, the rule summary, and the supply-chain checks it requires. The banner at the top is break-glass in force on one policy — enforcement suspended for a named incident, with who approved it, the incident reference, and when it expires. That is the same override that later shows up in the evidence package.

Vulnerabilities

Every finding across your images, grouped by CVE, with the installed and fixed versions side by side and how many images each affects. The filters narrow by severity, by whether a fix exists, and by triage state, so a view like "critical, fixable, untriaged" is three filters, not a scroll through everything.

The vulnerabilities list: CVEs with severity, package, installed and fixed versions, affected image count and triage state.
The triage column tells you at a glance what still needs a decision. "Partly triaged" means some affected images carry a decision and some do not.

Triaging a finding

A finding you have assessed does not have to keep blocking or keep nagging. Expand a CVE and open Triage. A triage decision is a record an auditor reads, so it is deliberately not a silent mute:

  1. Choose the status — false positive, accepted risk, or under investigation.
  2. Write a justification. It is required, and it has to be long enough to actually say something.
  3. Set an expiry. A triage cannot run forever — when it lapses, the finding returns to the policy verdict on its own.
The triage dialog: status buttons, a justification field, an expiry date, and the account it is recorded under.
The scope, the required justification, and the ceiling on how long a triage may run are all stated on the form.
The triage dialog filled in: accepted risk, a written justification, and an expiry date.
Every decision is stamped with who made it and when, and it lands in the audit log and the next evidence package.

Evidence packages

Day-to-day scanning is one thing; the record you hand an external auditor is another. An evidence package is one consolidated, signed document per audit period, generated inside the cluster and verifiable by the auditor with their own tools.

The compliance evidence page: one signed package per period, with framework, signature state, recipient and delivery, and the installation's signing key.
Each package names the period, the framework it maps to, and whether it has been signed and delivered. The signing key at the bottom is what an auditor verifies a package against.

Open one and the whole document is there: the control statement, scan coverage, the compliance outcome clause by clause, admission decisions with their reasons, triage and break-glass usage, the supply chain, and the evidence chain.

An evidence package open: header with period and framework, control statement and scan coverage sections.
The report states what it cannot prove as plainly as what it can — a package that overclaims is worth less than one that admits its edges.

Every break-glass override is on the record too — who forced a deployment through, when, and why — because the moment a control is bypassed is exactly the moment an auditor wants named.

The break-glass usage section of an evidence package.
Break-glass is not hidden. It is a section of the record, with the reason attached.

Ledger integrity — can the record itself be believed

The last section answers the question a careful auditor asks about any audit trail: how do you know these records were not edited after the fact? Every admission decision is hashed when it is written and sealed under signed, chained checkpoints. The report re-verifies the whole ledger at the moment it is generated — every sealed record re-hashed, every seal's signature checked, the chain walked — and states the result.

The ledger integrity section: Intact, signed seals, records re-verified, and records not yet sealed.
Intact means every sealed record reproduced its hash, every seal its root, the chain is unbroken and every signature verifies. The full design, and the honest limits, are on the evidence trust model page.