This tutorial provides guidance on best practices for a production hardened deployment of Vault. The recommendations are based on the Vault security model and focus on defense in depth.
These recommendations are divided into two sections. The baseline recommendations should be followed if at all possible on any production deployment of Vault. The extended recommendations provide additional layers of security which may require additional administrative overhead or may not be suitable for every deployment.
Do not run as root. Use a dedicated, unprivileged service account to run Vault, rather than running as the root or Administrator account. Vault is designed to be run by an unprivileged user, and doing so adds significant defense against various privilege-escalation attacks.
Allow minimal write privileges. The unprivileged Vault service account should not have access to overwrite its executable binary or any Vault configuration files. Only directories and files for local Vault storage (eg, for the integrated storage backend) or audit logs should be writable by the Vault user.
End-to-End TLS. Vault should always be used with TLS in production. If intermediate load balancers or reverse proxies are used to front Vault, TLS should be used for all network connections between every component of the system to ensure all traffic is encrypted in transit to and from Vault.
Disable Swap. Vault encrypts data in transit and at rest, however it must still have sensitive data in memory to function. Risk of exposure should be minimized by disabling swap to prevent the operating system from paging sensitive data to disk. This is especially important when using the integrated storage backend.
Disable core dumps. A user or administrator that can force a core dump and has access to the resulting file can potentially access Vault encryption keys. Preventing core dumps is a platform-specific process; on Linux setting the resource limit
0disables core dumps. In the systemd service unit file, setting
LimitCORE=0will enforce this setting for the Vault service.
Single Tenancy. Vault should be the only main process running on a machine. This reduces the risk that another process running on the same machine is compromised and can interact with Vault. Similarly, running on bare metal should be preferred to a VM, and running in a VM should be preferred to running in a container.
Firewall traffic. Use a local firewall or network security features of your cloud provider to restrict incoming and outgoing traffic to Vault and essential system services like NTP. This includes restricting incoming traffic to permitted subnets and outgoing traffic to services Vault needs to connect to, such as databases.
Avoid Root Tokens. Vault provides a root token when it is first initialized. This token should be used to setup the system initially, particularly setting up auth methods so that users may authenticate. We recommend treating Vault configuration as code, and using version control to manage policies. Once setup, the root token should be revoked to eliminate the risk of exposure. Root tokens can be generated when needed, and should be revoked as soon as possible.
Enable audit logging. Vault supports several audit devices. Enabling audit logging provides a history of all operations performed by Vault and a forensics trail in the case of misuse or compromise. Audit logs securely hash sensitive data, but access should still be restricted to prevent any unintended disclosures.
Upgrade Frequently. Vault is actively developed, and updating frequently is important to incorporate security fixes and any changes in default settings such as key lengths or cipher suites. Subscribe to the HashiCorp Announcement mailing list to receive announcements of new releases and visit the Vault CHANGELOG for details on what changes are being made in each release.
Synchronized Clocks. Use NTP or whatever mechanism is appropriate for your environment to ensure that all the Vault nodes agree about what time it is. Vault uses the clock for things like enforcing TTLs and setting dates in PKI certificates, and if the nodes have significant clock skew, a failover may wreak havoc.
Restrict Storage Access. Vault encrypts all data at rest, regardless of which storage backend is used. Although the data is encrypted, an attacker with arbitrary control can cause data corruption or loss by modifying or deleting keys. Access to the storage backend should be restricted to only Vault to avoid unauthorized access or operations.
No Clear Text Credentials. The
sealstanza of the Vault configuration file configures the seal type to use for additional data protection such as using HSM or Cloud KMS solutions to encrypt and decrypt the master key. DO NOT store your cloud credentials or HSM pin in clear text within the
sealstanza. If the Vault server is hosted on the same cloud platform as the KMS service, use the platform-specific identity solutions. For example:
- Resource Access Management (RAM) on AliCloud
- Instance Profiles on AWS
- Managed Service Identities (MSI) on Azure
- Service Account on Google Cloud Platform
If that is not applicable, set the credentials as environment variables (e.g.
Disable SSH / Remote Desktop. When running a Vault as a single tenant application, users should never access the machine directly. Instead, they should access Vault through its API over the network. Use a centralized logging and telemetry solution for debugging. Be sure to restrict access to logs as need to know.
Use systemd security features. Systemd provides a number of features that can be used to lock down access to the filesystem and to administrative capabilities. The service unit file provided with the official Vault Linux packages sets a number of these by default, including:
See the systemd.exec manual page for more information and details.
Immutable Upgrades. Vault relies on an external storage backend for persistence, and this decoupling allows the servers running Vault to be managed immutably. When upgrading to new versions, new servers with the upgraded version of Vault are brought online. They are attached to the same shared storage backend and unsealed. Then the old servers are destroyed. This reduces the need for remote access and upgrade orchestration which may introduce security gaps.
Configure SELinux / AppArmor. Using additional mechanisms like SELinux and AppArmor can help provide additional layers of security when using Vault.