Guide
What Vault audit logs contain
Every API operation in Vault produces an audit log event: secret reads and writes, token creation and revocation, authentication attempts, policy changes, lease operations, namespace management. Vault audit log monitoring means reading these events and deriving actionable signals from them.
{
"type": "response",
"auth": { "token_type": "service", "policies": ["admin"] },
"request": {
"path": "secret/data/production/database",
"operation": "read"
},
"response": { "data": { "metadata": { "version": 3 } } }
}
Every event is a JSON object with the full context of who did what, when, and through which auth method.
Why raw audit logs are not enough
- Volume - A busy Vault cluster produces 10–40 million events per day. Nobody reads 40M JSON lines.
- No built-in analysis - Vault writes audit logs to files or syslog. It does not analyze them, derive metrics, or alert.
- grep doesn’t scale -
grep | jqworks for investigation. It doesn’t work for continuous monitoring. - Compliance requires analysis - Having audit logs is a compliance checkbox. Analyzing them is where security actually happens.
What to look for in Vault audit logs
Security signals:
- Failed authentication spikes - Multiple failed auth attempts from the same source.
- Privilege jumps - An entity accessing paths outside its normal pattern.
- Off-hours access - Production secrets read at 3 AM on a Saturday.
- Token creation spikes - Unusual volume of new tokens created.
- Policy changes - Permissions modified without a corresponding change ticket.
- Lease anomalies - Leases not renewed, mass revocations, expired credentials.
How Logystera monitors Vault audit logs
Logystera ingests Vault audit log events via Fluentd or file tail. The processor applies metric definitions that understand Vault semantics: namespaces, entities, auth methods, secret paths, token types. Metrics are derived automatically. Rules fire when patterns match.
Example alert when it fires:
[CRITICAL] Failed authentication spike Vault cluster: prod-eu-1 23 failed auth attempts in 10 min Auth method: userpass Top offender: contractor-842 (17 attempts) Last 5 events attached
Vault audit log monitoring with Logystera means you don’t read 40 million events. You read the 3 alerts that matter.
Real example: contractor accessing production secrets
A company processing 40 million Vault events per day had no analysis in place. Logystera revealed: an external contractor account was reading secrets from production/database/* - a path the contractor had no business reason to access. The access pattern started 3 weeks before it was detected.
With a Logystera rule watching for unexpected path access, the alert would have fired on the first read.
Your audit logs already know
Vault audit logs are compliance evidence and security signals. Without structured analysis, they’re a growing pile of JSON. With Logystera, they become the security visibility your team needs.
Logystera doesn’t guess. It derives truth from logs.
Related Logystera content
Frequently asked questions
What does Vault's audit log capture?
Every API request and response: which token made the request, what path was accessed, what action (read, write, list, delete, etc.), the response code, request and response timestamps, and the client IP. Sensitive values (secrets) are HMAC-hashed by default so the audit log itself doesn't become a credential leak.
How do I enable audit logging in Vault?
vault audit enable file file_path=/var/log/vault/audit.log — that's the simplest backend. Vault also supports syslog and socket backends. Run with multiple backends so a single point of failure can't lose audit data; Vault refuses requests if all configured audit devices fail to write.
What's the most useful security signal from Vault audit logs?
Token access patterns. A token that suddenly accesses paths it never touched before, or that authenticates from a new IP range, or that fails on paths it has permissions for (suggesting permission probing) — those are the patterns worth watching for. Volume metrics matter less than pattern shifts.
Should Vault audit logs be stored in the same place as application logs?
No. Vault audit logs are security-critical and have stronger retention/immutability requirements than ordinary application logs. Ship them to a write-once, append-only log destination separate from your operational logs. Treat them like financial transaction records, not server logs.
See what's actually happening in your HashiCorp Vault system
Connect your site. Logystera starts monitoring within minutes.