Vault Audit Logs: Enable and Ship Every Request (2026)

Vault audit logs are critical for security and compliance, but getting them to record everything and shipping them reliably can be surprisingly tricky.

Let’s see Vault audit logs in action. Imagine a user trying to read a secret from a Kubernetes-backed Auth Method.

{
  "time": "2023-10-27T10:30:00.123456789Z",
  "type": "request",
  "request": {
    "id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
    "operation": "read",
    "path": "auth/kubernetes/login",
    "client_addr": "192.168.1.100",
    "namespace": {
      "id": "default",
      "path": "default"
    },
    "auth": {
      "client_token": "s.abcdef1234567890",
      "accessor": "some_accessor_string",
      "metadata": {
        "kubernetes_namespace": "default",
        "serviceaccount_name": "vault-agent"
      },
      "display_name": "kubernetes",
      "policies": [
        "default",
        "kubernetes"
      ],
      "token_policies": [
        "default",
        "kubernetes"
      ],
      "token_type": "service",
      "token_explicit_max_ttl": 0,
      "token_duration": 0,
      "token_renewable": true,
      "token_creation_time": "2023-10-27T10:29:55.123Z",
      "entity_id": "some_entity_id"
    }
  },
  "error": null
}

This log entry shows a read operation on the auth/kubernetes/login path. The request.id is unique to this transaction. Notice the auth block, detailing the client token, policies, and metadata associated with the request. This is the raw data that security teams pour over.

The core problem Vault audit logs solve is providing an immutable, detailed record of every interaction with the Vault server. This isn’t just about what was accessed, but who accessed it, when, from where, and how. This is fundamental for:

• Security Monitoring: Detecting suspicious activity, unauthorized access attempts, or policy violations.
• Compliance: Meeting regulatory requirements (like HIPAA, PCI DSS, SOC 2) that mandate detailed audit trails.
• Troubleshooting: Understanding the sequence of events leading to an error or unexpected behavior.
• Forensics: Reconstructing events after a security incident.

Vault offers two primary audit device types: file and syslog. You can configure multiple audit devices simultaneously to ship logs to different destinations.

Here’s how you enable a file audit device:

vault audit enable file \
    file_path="/vault/logs/vault.audit.log" \
    max_open_files=10 \
    max_file_size=104857600 \
    log_raw=true \
    disable_request_ PII=false

This command creates an audit log file at /vault/logs/vault.audit.log. max_open_files=10 means Vault will keep up to 10 log files open at a time, rotating them when they reach max_file_size=104857600 bytes (100MB). log_raw=true is crucial; it ensures that the full request and response bodies are logged, not just metadata. disable_request_PII=false ensures sensitive data isn’t redacted by default.

For shipping to a centralized logging system like Splunk or Elasticsearch, syslog is often preferred.

vault audit enable syslog \
    syslog_facility="LOCAL5" \
    syslog_address="udp://127.0.0.1:514" \
    log_raw=true \
    disable_request_PII=false

This configures Vault to send audit logs via UDP to 127.0.0.1:514, using the LOCAL5 syslog facility. Again, log_raw=true is vital for comprehensive logging.

The log_raw option is where many people stumble. By default, it’s false. If log_raw is false, sensitive information within the request and response bodies (like secret values) will be redacted, making the logs far less useful for deep analysis or troubleshooting. Always set log_raw=true for your primary audit devices.

Another common pitfall is disable_request_PII. If this is set to true, Vault will redact personally identifiable information from the request itself before logging it. While this might seem like a security feature, it can hinder investigations by removing details like client IP addresses or specific user identifiers from the audit trail. For most security and compliance use cases, you want this set to false to retain maximum detail.

When configuring your audit devices, remember that Vault processes them in the order they are enabled. If you have multiple file devices, the first one enabled might be for raw logs, and a second one could be for filtered or less verbose logs.

The log_format option is also worth noting. While json is the default and most common format for machine parsing, you can also choose json,syslog to send both formats simultaneously if needed, though this is less common.

Finally, for robust shipping, especially with syslog, ensure your syslog daemon (e.g., rsyslog, syslog-ng) is correctly configured to receive, buffer, and forward the logs. A misconfigured syslog daemon can silently drop logs. For file-based auditing, ensure the file permissions are correct and the disk has ample space.

After successfully enabling and shipping your audit logs, the next challenge you’ll face is parsing and alerting on this high-volume, detailed data.