Skip to main content

Module blast

Module blast 

Source
Expand description

Phase 36 — blast radius (ADR-0142).

After a compromise the question is always which credentials were on that machine, and when? It is never answerable, so the honest answer becomes “rotate everything”, so nobody does. This module answers it from three things the vault already keeps:

  • the hub’s audit chain says which files a node applied and when (node.apply rows, Phase 34);
  • the config history says what each of those files contained, as the list of vault secrets whose exact value appears in it (exposed, Phase 36), kept per snapshot because by the time of a compromise the entry may have been rotated, edited or deleted;
  • the vault says which of those values are still current, by fingerprint.

The pure logic lives here so it is testable without a database; callers supply the three lookups.

§What it cannot know, and says so

A file applied before the history existed, or whose snapshot was pruned, has no recorded contents: it is reported as unaccounted rather than silently dropped, because “nothing was exposed” would be a lie. A pull target’s file was never rendered by the hub, so it is not covered at all.

Structs§

CurrentEntry
What the vault holds for an entry now.
Deployment
One thing a host received.
EntryExposure
Exposed
A secret whose exact value appeared in a rendered file or an environment. Stored with the snapshot (or the local log) at the moment it was written.
Report

Functions§

failed_apply_touched_disk
True when a failed apply still put the new file on disk for a moment (it was written, then restored). A refused or hash-mismatched one never was.
report
Builds the report. deployments are what the host received, lookup maps a file hash to what it contained (None = not recorded), current maps an entry id to what the vault holds now (None = deleted).