HashiCorp Vault

Overview

HashiCorp Vault provides secrets management, encryption as a service, and identity-based access control. KYRA MDR collects Vault audit logs to monitor secret access, authentication events, policy changes, and token lifecycle for detecting credential misuse, unauthorized access, and privilege escalation.

Prerequisites

KYRA MDR account (MDR tier or above)
KYRA Collector installed and reachable from the Vault server
HashiCorp Vault 1.x with root or sudo policy access
Vault unsealed and operational

Configuration

Step 1: Enable File Audit Device

The file audit device writes JSON-formatted audit logs to disk:

# Enable file audit device
vault audit enable file file_path=/var/log/vault/audit.log

# Verify audit devices
vault audit list -detailed

Key options for the file audit device:

# Enable with additional options
vault audit enable file \
  file_path=/var/log/vault/audit.log \
  log_raw=false \
  hmac_accessor=true \
  mode=0600

log_raw=false (default): Sensitive values are HMAC-hashed in the log. Set to true only in secure debug scenarios.
hmac_accessor=true: HMAC-encode token accessors (recommended for production).
mode=0600: File permissions for the audit log.

Step 2: Enable Syslog Audit Device

Forward audit logs directly to syslog:

# Enable syslog audit device
vault audit enable syslog tag="vault" facility="AUTH"

# Or with custom syslog address
vault audit enable syslog \
  tag="vault" \
  facility="LOCAL0" \
  log_raw=false

Step 3: Enable Socket Audit Device

Send audit logs directly to the KYRA Collector over TCP:

vault audit enable socket \
  address="<COLLECTOR_IP>:514" \
  socket_type="tcp"

Step 4: Forward File Audit Logs via rsyslog

If using the file audit device, configure rsyslog to forward logs:

module(load="imfile" PollingInterval="5")

input(type="imfile"
  File="/var/log/vault/audit.log"
  Tag="vault-audit"
  Facility="local0"
  Severity="info")

local0.*  @@<COLLECTOR_IP>:514

sudo systemctl restart rsyslog

Step 5: Understand Audit Log JSON Format

Each Vault audit entry is a JSON object with this structure:

{
  "type": "request",
  "time": "2024-01-15T10:30:00.000Z",
  "auth": {
    "client_token": "hmac-sha256:abc123...",
    "accessor": "hmac-sha256:def456...",
    "display_name": "ldap-john.doe",
    "policies": ["default", "app-secrets"],
    "token_type": "service",
    "entity_id": "entity-uuid"
  },
  "request": {
    "id": "request-uuid",
    "operation": "read",
    "path": "secret/data/production/db-creds",
    "remote_address": "10.0.1.50"
  },
  "response": {
    "data": {
      "password": "hmac-sha256:ghi789..."
    }
  }
}

Sensitive fields (passwords, tokens, keys) are HMAC-encoded by default. Use vault audit enable file log_raw=true only for debugging in isolated environments.

Step 6: Configure Multiple Audit Devices

Vault blocks all client requests if every enabled audit device fails. Enable at least two devices for high availability:

# Primary: file-based
vault audit enable -path=file file file_path=/var/log/vault/audit.log

# Secondary: syslog-based
vault audit enable -path=syslog syslog tag="vault" facility="LOCAL0"

# Verify both are active
vault audit list

Step 7: Verify on KYRA Collector

# Test by reading a secret
vault kv get secret/test

# Check the audit log
sudo tail -1 /var/log/vault/audit.log | jq '.request.path'

# Verify collector receives events
kyra-collector status
kyra-collector logs --source vault --tail 5

Collected Log Types

Log Type	Description	Security Use
Authentication	Login via token, LDAP, OIDC, AppRole, userpass, certificate	Access monitoring
Secret Access	Read, write, delete, list operations on secret engines	Credential access auditing
Policy Changes	Policy create, update, delete	Access control monitoring
Token Lifecycle	Token create, renew, revoke, lookup	Session management
Lease Events	Lease grant, renew, revoke for dynamic secrets	Secret lifecycle tracking
Seal/Unseal	Vault seal, unseal, step-down operations	Operational security
Audit Device	Audit device enable, disable, hash operations	Audit integrity

Security-Critical Vault Events

Event	Indicator	Description
`auth/token/create` with `no_default_policy`	Privilege escalation	Token created without default restrictions
`sys/policy` write operation	Access control change	Security policy modified
`sys/audit` disable operation	Audit tampering	Audit logging being disabled
`sys/seal` operation	Denial of service	Vault being sealed (blocks all access)
`secret/` read from unusual `remote_address`	Lateral movement	Secret access from unexpected network segment
Multiple `authentication_failed` from same IP	Brute force	Repeated failed login attempts
`auth/token/create-orphan`	Persistence	Orphan token created (not tied to parent lifecycle)
`sys/raw` access	Root-level access	Direct storage backend access (root token only)

Troubleshooting

No audit log file: Verify the Vault process has write permission to the audit log directory. Run sudo mkdir -p /var/log/vault && sudo chown vault:vault /var/log/vault.
Vault blocking requests: If all audit devices fail, Vault refuses client requests. Check disk space and syslog connectivity. Use vault audit list to verify device status.
HMAC values unreadable: This is by design. To correlate HMAC values, use vault audit hash <mount>/<value> to compute the HMAC of a known value.
High disk usage: Audit logs can grow rapidly on busy clusters. Configure log rotation with logrotate and send SIGHUP to Vault after rotation.
Syslog not receiving: Verify the syslog facility matches your rsyslog configuration. Check journalctl -u vault for audit device errors.
Socket audit failures: If the KYRA Collector is unreachable, the socket audit device will fail. Always pair it with a file or syslog device as fallback.

Contact kyra@seekerslab.com for integration support.