Skip to content

v0.11 — An audit trail that outlives the node

Choose a tag to compare

@sethbergman sethbergman released this 25 Aug 20:21
· 69 commits to main since this release
f04596e

An audit log that exists only on the node it describes is one a
compromise can delete. Anything able to destroy the Vault node is able to
destroy the evidence of what it did there.

v0.8 enabled two audit devices and argued for putting the secondary on a
different failure domain. This is that argument carried through: the
socket device now points at a collector container writing to a Docker
named volume with a lifecycle independent of every container.

Proven by destruction, not by inspection

The integration suite destroys the vault-0 container outright and reads
the trail back afterwards. That is the property worth having, and reading
a file while everything is running would not have demonstrated it.

The pairing also stays deliberate. A socket device alone can block
Vault when its endpoint goes away; paired with a file device it cannot,
because the file keeps satisfying the at-least-one guarantee. The suite
stops the collector and shows Vault still accepting writes, still
healthy, still recording to the survivor.

What it is not

Not off-host. A Docker named volume outlives the container and does not
leave the machine — anything with access to the Docker daemon can still
reach it.

docs/audit.md states this plainly and describes what a real deployment
should point the socket at instead, along with the properties worth
insisting on: a different host, append-only or object-locked storage, and
credentials that are not Vault's own. The last two are the ones people
skip, and shipping a log to a place the same attacker can edit is a
change of address rather than of risk.

See docs/audit.md.