BUILDING Parts of this page describe what is not built yet, and each says so.
The audit chain
Every change in your organisation is recorded as an entry, and each entry carries the hash of the entry before it. A copy of the log can be checked on your own machine, and the check shows that the copy is consistent with itself. Kept beside the head hash of an earlier copy, a later copy also shows that nothing up to that head was rewritten.
What an entry is
An entry has a sequence number, a time, who did it, what they did and to what, and the document as it was before and after. It is written once. The log is append-only, and that is enforced by the database itself, not by the application that writes to it.
Who is in it, and what reading does
The actor of an entry is one of six kinds: a user, a token, an agent, the system, staff, or a service principal.
What a member of RunningLake staff does in your organisation through our staff console is written
into your chain under the actor kind staff, beside your own people, and you can
filter the log by actor kind to see only that.
That is not everything staff can do. A command run on our control plane’s host can mint an
owner’s token into your organisation: the entry that mints it names the staff member, and
what the token then does reads as the owner’s own credential. A second host command, which retries provisioning, is recorded as a
system actor with the reason typed for it and no staff member; the same retry from the
staff console is recorded under the actor kind staff, with the staff member and
the reason. Reading your dead-lettered jobs, or the repair state of your projects, in the
staff console is written to your chain too, under the staff member, with a count and no names. Reads of the fleet, of cost and of the list of organisations are not written to a
customer’s chain. And whoever has access to the host or to the database is outside all of
these records.
Reading the log is recorded in it. Reading it in the console, exporting it, and asking us to
verify it each write an entry to it, and the console and rl say so. Checking a copy
you already hold, on your own machine, writes nothing.
What it proves
That the copy you hold is consistent with itself: every entry’s hash recomputes from the entry, every entry names the one before it, and no sequence number is missing. A change to the value of a field the hash covers is caught. A later copy checked against the head hash of a copy you took earlier also shows that nothing before that head has been rewritten since. You can check all of this yourself, without trusting us, because the rule that links the entries is published and the checker is a Python program of about seven hundred lines that you can read. Keep each copy’s head hash: it is in the first line of the file. The hash does not read everything in the file, and Verify your audit log lists what it leaves out.
What it cannot prove
The hash is not keyed or signed. Anyone holding a copy can edit an entry and recompute its hash and every hash after it, and the result is still consistent; whoever can edit our database can do the same there. So a copy checked on its own shows only that it is consistent with itself, and not who wrote it or that it is the record as it was first written. A signed daily checkpoint is meant to close part of that gap: it needs delivery to your own bucket, which is not switched on yet, and what one shows and how to check it is on the verify page. It also cannot show you an entry that was never written: it shows that the record is consistent, not that the record is everything that happened. Comparing the last entry of your copy with the one we hold shows that we still hold what you hold. It is the same server that wrote the chain answering about itself, and the comparison is itself recorded, as above.
Where to go next
- Verify your audit log shows how to get a copy and check it.
- Delivering the log to a bucket in your own account as it is written is not switched on yet. Export and verify work today.
- Review and approval says which decisions end up in it.