Security¶

Threat Model¶

Threat Vector	Impact	Mitigation
Storage backend compromise	Access to encrypted data only	Encryption barrier (AES-256-GCM); storage is untrusted
Memory dump / swap	Secrets leaked to disk	`mlock` prevents swapping; memory is zeroed on shutdown
Unseal key exposure	Full Vault decryption	Shamir's Secret Sharing (K-of-N); auto-unseal with cloud KMS
Root token compromise	Unrestricted Vault access	Minimize root token use; revoke after initial setup
Token theft	Unauthorized secret access	Short TTLs, renewable tokens, token type restrictions
Policy misconfiguration	Overly permissive access	Default-deny model; policy review process
Audit log tampering	Loss of forensic trail	Multiple audit devices, append-only storage, SIEM forwarding
Network interception	Man-in-the-middle attacks	TLS everywhere; mutual TLS for client authentication

Seal and Unseal Security¶

By default, Vault uses Shamir's Secret Sharing to protect the master key. The unseal key is split into N shares, and a threshold of K shares is required to reconstruct it.

Recommended configuration: 5 shares, 3 threshold (5/3). This tolerates the loss of 2 shares while requiring at least 3 operators to unseal.
Key shares must be stored separately -- Each share should be held by a different trusted individual or stored in a different secure location. Never store all shares together.

Shamir Limitations

Shamir's Secret Sharing does not provide verifiable secret sharing. A malicious share holder could provide an invalid share. Additionally, the reconstruction happens in memory on the Vault server, so a compromised server could intercept the reconstructed key.

Auto-Unseal¶

Auto-unseal delegates the unseal operation to a trusted cloud KMS or HSM, eliminating the need for manual key share distribution:

Backend	Security Properties
AWS KMS	FIPS 140-2 validated; CloudTrail audit logging for key usage; IAM controls access
GCP CKMS	FIPS 140-2 Level 3; Cloud Audit Logs; IAM controls access
Azure Key Vault	FIPS 140-2 Level 2 (HSM: Level 3); Azure Monitor logging; RBAC controls access
Transit (another Vault)	Inherits security of the primary Vault; useful for nested deployments
PKCS#11 HSM	Hardware-protected keys; vendor-specific FIPS certification

Auto-unseal security best practices: - Restrict KMS key access to only the Vault server instances via IAM policies. - Enable CloudTrail / Cloud Audit Logs to monitor all KMS decrypt operations. - Use VPC endpoints (AWS) or private connectivity to prevent KMS traffic from traversing the public internet. - Rotate KMS keys periodically and update Vault configuration.

# AWS KMS auto-unseal configuration
seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "19ec80b0-dfdd-4d97-8164-c6examplekey"
}

Root Token Handling¶

The root token is created during vault operator init and has unrestricted access to all Vault operations.

Root Token Policy

Use the root token only for initial configuration (enabling auth methods, creating policies, setting up audit devices).
Revoke the root token immediately after initial setup.
Generate short-lived root tokens via vault operator generate-root only when absolutely necessary.
Never store root tokens in configuration files, environment variables, or version control.
Monitor for root token usage in audit logs as an indicator of potential compromise.

ACL Policies¶

Vault uses a default-deny, path-based ACL system. Every action is forbidden unless explicitly permitted by a policy.

Policy Writing Principles¶

Principle of least privilege -- Grant only the minimum capabilities needed.
Use explicit paths -- Avoid wildcards (*) in production policies.
Deny by default -- No policy means no access. Adding policies only increases permissions.
Use templated policies -- Vault supports Identity templating in policies for parameterized access.

# Good: specific path, specific capability
path "secret/data/myapp/config" {
  capabilities = ["read"]
}

# Bad: overly broad
path "secret/*" {
  capabilities = ["read", "list", "create", "update", "delete"]
}

Sentinel (Enterprise)¶

Vault Enterprise supports Sentinel, a policy-as-code framework that enforces fine-grained, conditional access rules beyond what HCL policies can express. Sentinel policies can: - Require multi-party approval for sensitive operations. - Enforce time-of-day restrictions. - Validate secret format or rotation compliance. - Implement break-glass procedures with mandatory audit annotations.

Audit Devices¶

Audit devices are critical for security monitoring and compliance. They record every request and response to Vault.

Recommended Configuration¶

Enable at least two audit devices for redundancy:

# File audit device with HMAC for sensitive values
vault audit enable file file_path=/var/log/vault/audit.log
log_raw=false

# Syslog for SIEM integration
vault audit enable syslog facility="AUTH" tag="vault" log_raw=false

Audit Log Security¶

HMAC sensitive values -- By default (log_raw=false), Vault HMACs sensitive values in audit logs rather than logging plaintext. This preserves the audit trail without exposing secrets in logs.
Append-only storage -- Store file-based audit logs on append-only filesystems or ship them immediately to an immutable SIEM.
Encrypt at rest -- Use disk encryption for audit log files.
Monitor for gaps -- Alert on gaps in audit log sequences, which could indicate tampering.

Transit Encryption¶

The Transit secrets engine provides encryption-as-a-service without storing the encrypted data. Applications send plaintext to Vault and receive ciphertext back, or vice versa.

Security benefits: - Key separation -- Each named key in Transit is independent; compromising one key does not affect others. - Key rotation -- Transit supports automatic key versioning. New encryptions use the latest version; old ciphertext remains decryptable. - Convergent encryption -- Optional mode where the same plaintext produces the same ciphertext (for deduplication use cases). Use with caution as it can enable chosen-plaintext attacks. - No key export -- Private key material never leaves Vault. Applications only interact with ciphertext.

Application                     Vault Transit
    |                               |
    |  encrypt/my-key (plaintext)   |
    |------------------------------>|
    |                               |  Encrypt with latest key version
    |  ciphertext:vX:base64data     |
    |<------------------------------|
    |                               |

Namespace Isolation (Enterprise)¶

Vault Enterprise supports namespaces for multi-tenant isolation:

Each namespace has its own auth methods, secrets engines, policies, and audit devices.
Namespaces are hierarchical; child namespaces inherit nothing from parents.
Administrators in a parent namespace cannot access secrets in child namespaces (unless explicitly granted).
Tokens are scoped to a namespace and cannot cross boundaries.

Token Security¶

Token Types¶

Type	Behavior	Use Case
Service	Standard token with TTL; renewable	Applications and automation
Batch	Non-renewable, encrypted offline token	High-throughput, short-lived operations
Periodic	Renewable without parent; self-renews	Long-running services
Root	Unrestricted, never expires	Initial setup only

Token Security Best Practices¶

Short TTLs -- Issue tokens with the shortest practical TTL. Re-authenticate when tokens expire.
Use response wrapping -- Deliver initial tokens via response wrapping (-wrap-ttl). The unwrapping process is one-time-use and detects interception.
Prefer periodic tokens -- For long-running services, periodic tokens self-renew without requiring a parent token.
Batch tokens for high-volume -- Batch tokens are lighter weight and do not require storage, reducing the load on the token store.
Revoke on compromise -- Use vault token revoke -prefix to revoke all tokens under a role or auth path.

mlock and Memory Protection¶

Vault uses the mlock system call to prevent the operating system from swapping its memory pages to disk:

Why it matters -- If Vault's memory is swapped to disk, encryption keys, unseal keys, and decrypted secrets could be written to the swap partition in plaintext.
Linux requirement -- mlock requires CAP_IPC_LOCK capability. The Vault binary is configured with this capability by default.
Disabling mlock -- Can be disabled via disable_mlock = true in the configuration. This is only appropriate for testing environments.

Disable mlock Only for Testing

Never disable mlock in production. Without it, secrets may be written to disk in plaintext via the swap partition. On systems with limited mlock limits, increase ulimit -l rather than disabling the feature.

TLS Configuration¶

All communication with Vault should be encrypted with TLS:

listener "tcp" {
  address       = "0.0.0.0:8200"
  cluster_address = "0.0.0.0:8201"

  tls_cert_file = "/etc/vault/tls/tls.crt"
  tls_key_file  = "/etc/vault/tls/tls.key"
  tls_client_ca_file = "/etc/vault/tls/ca.crt"

  # Require mutual TLS for client authentication
  tls_require_and_verify_client_cert = true
}

Best practices: - Use certificates from a trusted CA or internal PKI (Vault's own PKI engine can issue its own TLS certificate). - Enable mutual TLS (tls_require_and_verify_client_cert) for production deployments. - Set tls_min_version = "tls12" to enforce TLS 1.2 or higher. - Rotate TLS certificates before expiration using cert-manager or automated workflows.