Proposal: name the API caller in audit records

[sumansaurabh]

The problem

AerolVM writes an audit record each time a sandbox's secrets are opened, and each time the network filter refuses a connection. The records sit in a hash chain, so a changed or deleted record shows. Each one names the sandbox and the server that did the work, but not who called the API. An auditor asking "who read this sandbox's variables?" gets a server name, not a person or service.

What you can do today

Have your own gateway add an X-Correlation-ID or X-Request-ID header to each API call. When a call reads a sandbox's variables, the audit record keeps that value, so you can match it against the gateway's logs. Records written when a sandbox starts or is rebuilt have no caller, because no API call caused them.

A starting shape

• Each record gets a caller field: the token's name or ID, or operator for the operator token.
• The field is covered by the hash chain, like every other field.
• With scoped tokens and SSO, the caller is a real person or service.
• Exports to a file, a webhook and S3 carry the new field. Older records stay valid.

Questions for you

1. Which question does your auditor ask most: who read a secret, who ran a command or who deleted a sandbox?
2. Should command runs and file reads be recorded too, not just secret reads?
3. Where do your audit records end up: a SIEM, S3 or something else?

How to weigh in

React with 👍 if you need this, and comment with your answers.

Want to talk it through? Book a call with the maintainer, or join the community call on the first Saturday of every month at 8 pm Pacific Time.

If your company needs this soon, you can sponsor the work. It is built in the open and ships to everyone.

[sumansaurabh]

Thanks for proposing this. It shipped in v0.6.8, together with scoped
tokens and roles (#646) and SSO (#647).

What changed in the audit log:

• Every record names its caller, in a hash-chained caller field: the
  kind (person, API token, operator, cluster server, the server's own work,
  an SSH key), a stable ID (tok_…, oidc:<issuer>:<sub>), a display name,
  the team, and via, the server a forwarded call came through. The hash
  covers it, so changing who did something breaks the chain.
• API calls are now recorded, not only secret reads. Create, delete,
  start, stop, ports, snapshots, tokens, and every command and file call write
  an api record. Refused calls are recorded too (403s as denied, 401s as
  auth_denied). Commands are recorded as a fingerprint by default, since
  they can carry secrets.
• The server's own actions (lifecycle deletes, reconcile) name the part
  of the server that did them, so "who deleted this sandbox" always has an
  answer.
• Search and access reviews. aerolvm audit search --caller ana@acme.com --since 7d finds what one person did, checked against the chain as it
  reads. aerolvm access review --since 90d writes a SOC 2 CC6.2/CC6.3
  access review from the token list and the export.
• Even with access control off, records now say operator or
  system:<subsystem>, instead of only the server's ID.

Two things to know before you upgrade:

• Display names are often email addresses, so treat audit records and exports
  as personal data. The audit page explains how retention bounds them.
• Once a server has written a caller, do not roll it back below this release:
  an older binary cannot verify those records and refuses to start with strict
  boot verification on. Upgrade aerolvm (the CLI) before you verify exports.

Docs: https://microvm.aerol.ai/enterprise/audit-evidence/