a3dfde5cec
* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
123 lines
6.6 KiB
Markdown
123 lines
6.6 KiB
Markdown
---
|
|
layout: "guides"
|
|
page_title: "Production Hardening - Guides"
|
|
sidebar_title: "Production Hardening"
|
|
sidebar_current: "guides-operations-production-hardening"
|
|
description: |-
|
|
This guide provides guidance on best practices for a production hardened deployment of HashiCorp Vault.
|
|
---
|
|
|
|
# Production Hardening
|
|
|
|
This guide provides guidance on best practices for a production hardened
|
|
deployment of Vault. The recommendations are based on the [security
|
|
model](/docs/internals/security.html) and focus on defense in depth.
|
|
|
|
~> **Apply When Possible!** This guide is meant to provide guidance for an
|
|
_ideal_ deployment of Vault, not to document requirements. It is entirely
|
|
possible to use Vault without applying any of the following recommendations.
|
|
These are best practice recommendations that should be applied when possible
|
|
and practical.
|
|
|
|
# Recommendations
|
|
|
|
* **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, they
|
|
should _not_ terminate TLS. This way traffic is always encrypted in transit
|
|
to Vault and minimizes risks introduced by intermediate layers.
|
|
|
|
* **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 a VM preferred to a container.
|
|
This reduces the surface area introduced by additional layers of abstraction
|
|
and other tenants of the hardware. Both VM and container based deployments
|
|
work, but should be avoided when possible to minimize risk.
|
|
|
|
* **Firewall traffic**. Vault listens on well known ports, use a local firewall
|
|
to restrict all 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.
|
|
|
|
* **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.
|
|
|
|
* **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. Vault attempts to ["memory lock" to physical memory
|
|
automatically](/docs/configuration/index.html#disable_mlock), but disabling
|
|
swap adds another layer of defense.
|
|
|
|
* **Don't Run as Root**. Vault is designed to run as an unprivileged user, and
|
|
there is no reason to run Vault with root or Administrator privileges, which
|
|
can expose the Vault process memory and allow access to Vault encryption
|
|
keys. Running Vault as a regular user reduces its privilege. Configuration
|
|
files for Vault should have permissions set to restrict access to only the
|
|
Vault user.
|
|
|
|
* **Turn Off 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 `RLIMIT_CORE` to `0` disables core dumps. This can be
|
|
performed by process managers and is also exposed by various shells; in Bash
|
|
`ulimit -c 0` will accomplish this.
|
|
|
|
* **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.
|
|
|
|
* **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](https://www.hashicorp.com/blog/codifying-vault-policies-and-configuration/),
|
|
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](/guides/operations/generate-root.html), and should be
|
|
revoked as soon as possible.
|
|
|
|
* **Enable Auditing**. Vault supports several auditing backends. Enabling
|
|
auditing provides a history of all operations performed by Vault and provides
|
|
a forensics trail in the case of misuse or compromise. Audit logs [securely
|
|
hash](/docs/audit/index.html) any 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 [Vault
|
|
mailing list](https://groups.google.com/forum/#!forum/vault-tool) and [GitHub
|
|
CHANGELOG](https://github.com/hashicorp/vault/blob/master/CHANGELOG.md) for
|
|
updates.
|
|
|
|
* **Configure SELinux / AppArmor**. Using additional mechanisms like SELinux
|
|
and AppArmor can help provide additional layers of security when using Vault.
|
|
While Vault can run on many operating systems, we recommend Linux due to the
|
|
various security primitives mentioned here.
|
|
|
|
* **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](/docs/internals/security.html) 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.
|
|
|
|
* **Disable Shell Command History**. You may want the `vault` command itself to
|
|
not appear in history at all. Refer to [additional methods](/guides/secret-mgmt/static-secrets.html#additional-discussion)
|
|
for guidance.
|
|
|
|
* **Tweak ulimits**. It is possible that your Linux distribution has strict process `ulimits`.
|
|
Consider to review `ulimits` for maximum amount of open files, connections, etc. before
|
|
going into production; they may need increasing.
|
|
|
|
* **Docker Containers**. To leverage the ["memory lock"](/docs/configuration/index.html#disable_mlock)
|
|
feature inside the Vault container you will likely need to use the `overlayfs2` or another supporting driver.
|