Vault Associate: Secure and Operate a Vault Deployment

Transport and access

Run Vault behind TLS with a certificate clients validate (VAULT_CACERT, VAULT_ADDR=https://...). Never use VAULT_SKIP_VERIFY outside labs. Never run vault server -dev in production: it is in-memory, pre-unsealed, uses a root token, and listens on plain HTTP.

Audit devices

Enable at least one audit device (file, syslog, socket): vault audit enable file file_path=/var/log/vault_audit.log. Audit logs record every request and response, with sensitive values HMAC'd using a salt. Critically, if Vault cannot write to any enabled audit device, it refuses requests - a broken log path becomes an outage.

Operational hygiene

Revoke the initial root token once admin auth methods and policies exist; create new root tokens only with vault operator generate-root and the required quorum. Distribute unseal shares among separate holders, or prefer KMS auto-unseal in cloud. Back up regularly with vault operator raft snapshot save and test restores. Upgrade standbys first, then fail over. Monitor with vault status, telemetry, and the health endpoint. Rotate with vault operator rekey (unseal keys) and vault operator rotate (encryption key).

Traps

• Exporting VAULT_TOKEN in a shell profile leaks a long-lived token.
• A failing audit device blocks requests; it does not silently drop logs.
• Auto-unseal and seal wrap protect key material but do not replace least-privilege policies.
• Snapshots are encrypted by the barrier, so a snapshot alone is useless without unseal material.

Rule of thumb: TLS on, at least one working audit device, root token revoked, backups tested - in that order, before anything else goes live.