This document describes how we safely and securely manage your data. While this document reflects the current state of HCP Vault, we may periodically update it to communicate changes or modifications to security protocols or considerations.
Refer to the HashiCorp Cloud Platform (HCP) Architecture documentation to understand the platform architecture.
Vault's data is encrypted and stored in an account-specific Amazon Elastic Block Store (EBS) in the same region as the cluster.
Hashicorp uses the Managed Service Provider (MSP) policy to perform updates on all HCP Vault Clusters.
This policy allows us to manage and access policies required for HCP Vault Service where we may periodically add new management functionality. When an update takes place using this policy, a root token is generated, and is visible in the audit logs. Once the update is completed, the root token is destroyed. While you may see the
hcp-metadata path appear in your audit logs, there are no actions required from you; please ignore the path.
Snapshots are available for production tier clustlers. For these clusters, HashiCorp performs snapshots daily and before any upgrades. You may also capture snapshots on demand. Snapshots are stored in HashiCorp's managed, encrypted Amazon S3 buckets in the US. The co-location of snapshots in the same region as the Vault cluster is planned.
Audit logs are accessible to production tier clusters. Audit logs are stored in an encrypted Amazon S3 bucket in the same region as the cluster.
If desired, you can upload this data to your existing security information and event management (SIEM) platform. Support for out-of-the box integration is planned.
Cluster initialization generates a root token used to enable initial authentication methods, define policies, and establish trust with the control plane. The root token is revoked after setup is complete.
NOTE: The Vault cluster administrator is provided an admin token when the cluster is ready.
»Cluster auto unseal
A unique Key Management Service (KMS) key is created for each Vault cluster. This KMS key is trusted by the EC2 instances that are backing the Vault cluster and configured to be used as the autounseal mechanism.
NOTE: Externally provided KMS keys are not supported.
Clusters adhere to our production hardening guidelines.
End-to-end TLS - Instances use
LetsEncryptcertificates that are automatically rotated.
Single tenant, Vault dedicated clusters - Instances run only the Vault process and management subsystem. Vault instances are not shared between organizations.
Firewall restrictions - Allow only inbound TCP/8200 on the public and private IP address. Public IP usage is discouraged in production.
Disable SSH / Remote Desktop - Port 22 is disabled for all Vault clusters.
Disable swap - Swap space is permanently disabled on instances.
Don’t run as root - Vault processes run as a dedicated, non-root user account.
Turn off core dumps - Core dumps are disabled on instances.
Immutable upgrades - Immutable instances are used to upgrade Vault clusters; software packages are never upgraded in-place.
Avoid root tokens - The root token is used to initially configure the cluster and then revoked; it is never shared outside the cluster.
Enable auditing - Enabled by default on all production clusters. Audit logging is not available on Dev clusters.
Upgrade frequently - Monthly updates are performed for system packages. Today, HCP automatically upgrades Vault versions. Support of customer-controlled major version upgrades for production tier clusters is planned.
Configure SELinux / AppArmor - These are not in use.
Restrict storage access - All Vault data is encrypted and stored under the customer’s dedicated account. HashiCorp’s access to this account is restricted to support staff on a need-to-access basis.
Disable shell command history - Not applicable as Vault commands are not issued.
Tweak ulimits - Ulimits have been optimized for Vault usage.
Docker containers - Not applicable as Docker is not used.
No clear text credentials - All credentials are encrypted.
»System API endpoints
Most endpoints under
/v1/sys that require authentication are not available.
However, the following endpoints are available:
To access those endpoints, you must set the targeted namespace using the
-ns for shorthand) flag with CLI commands or set the
VAULT_NAMESPACE environment variable. If using the API, set the
X-Vault-Namespace header in the HTTP request header or specify the namespace
in the endpoint (e.g.
/sys/metrics to an authenticated endpoint to be accessible only to production tier clusters is planned.
»Supported Auth Methods
The following authentication methods were demonstrated to function as intended with HCP Vault:
Additional auth methods are being validated with HCP Vault.
HCP Vault does not place any explicit restrictions to use any of the Vault's authentication methods; however, you may encounter some limitations with configuration or functionality.
»Supported Secrets Engines
The following secrets engines were validated and shown to function as expected with HCP Vault:
Additional secret engines are being validated with HCP Vault.
There are no explicit restrictions to use other available secrets engines; however, you may encounter configuration or functional limitations.
»GDPR Data Processing Agreement
HashiCorp supports General Data Protection Regulation (GDPR) Data Processing Agreement (DPA) for HCP Vault.
»HIPAA Business Associate Agreement
HIPAA Business Associate Contracts (BAAs) are not supported.
Please contact HashiCorp support for security questions, concerns, or feature requests.