lookout audit exemptions

Audit the exemption file itself: which reviewed exemptions have lapsed (and are therefore no longer annotating anything) and which are about to. The mechanism that keeps an exemption file from becoming a permanent, unread list of things nobody checks any more.

MCP tool: k8s_audit_exemptions (MCP profile: audit)

Usage

lookout audit exemptions [flags]

Flags

Flag	Type	Default	Meaning
--within	duration	336h0m0s	how far ahead to warn about entries that are still live but expiring soon; 0 reports only entries that have already lapsed

Common flags (every lookout command)

Flag	Type	Default	Meaning
--namespace	string	—	limit the scan to one namespace
-A	bool	—	scan all namespaces
--workload	string	—	target one workload as <Kind>/<namespace>/<name>, e.g. Deployment/prod/api
--since	duration	—	how far back to look (0 = command default)
--format	string	logfmt	output format: logfmt|json (one record per line either way)
--timeout	duration	10s	abort the invocation after this long (exit 1)
--kubeconfig	string	—	path to a kubeconfig file, instead of $KUBECONFIG / ~/.kube/config
--context	string	—	kubeconfig context to read, instead of its current-context. Selects a cluster for THIS invocation only — nothing is written back — so concurrent invocations can target different clusters. Reported as context=<name> in the summary line
--exemptions	string	—	path to a git-reviewed exemption file (YAML); covered findings are ANNOTATED with their reason and expiry and counted as exempt=<n> in the summary, never dropped

Finding kinds

Every kind= this command can emit, and the severities it carries them at. Nothing else appears in its output; a kind absent from a run means the check looked and found nothing. See the finding-kind glossary for the whole vocabulary.

Kind	Severity	Claim
audit.exemption_expired	warning	an exemption entry has lapsed: the findings it used to annotate are being reported unqualified again
audit.exemption_expiring	info	an exemption entry lapses within —within — renew it or let it go deliberately

Output fields

Beyond the shared envelope fields (kind, severity, namespace, kind_of_object, name, reason, message, fingerprint, exempt_reason, exempt_expires):

Field	Meaning
exempt_kind	the finding kind the entry covers — this is the entry’s kind: field, not this finding’s own kind
subject	the entry’s match scope as written: <kind>, <kind> in <ns>, or <kind> on <ns>/<name>
expires	when the entry stops applying, RFC 3339 (a bare YYYY-MM-DD in the file resolves to 00:00:00Z that day)
expired_for	how long ago the entry lapsed, rounded to whole days — only on audit.exemption_expired
expires_in	how long until the entry lapses, rounded to whole days — only on audit.exemption_expiring
owner	the entry’s owner: field, absent if it has none — which is itself worth fixing, since “expired, and nobody knows whose it was” is where these files end up
justification	the entry’s reason: field: why the exempted finding was accepted. Distinct from the envelope’s exempt_reason, which is the justification for THIS finding being exempt

Output contract

Output: one finding per line (logfmt; —format=json for one JSON object per line), keys in fixed order; healthy resources emit nothing. The final line is always the summary: scanned= findings= elapsed= — findings=0 with a summary present means “scanned and healthy”; a stream without a summary line is void. Exit 0 data, 1 runtime error (diagnostics on stderr only), 2 usage.

Examples

lookout audit exemptions --exemptions=exemptions.yaml
lookout audit exemptions --exemptions=exemptions.yaml --within=720h
lookout audit exemptions --exemptions=exemptions.yaml --within=0s