Security overview
This document describes how we safely and securely manage your data. While this document reflects the current state of HCP Vault Dedicated, we may periodically update it to communicate changes or modifications to security protocols or considerations.
Tip
Refer to the HashiCorp Cloud Platform (HCP) Architecture documentation to understand the platform architecture.
Vault data
Each HCP Vault Dedicated cluster is created in an HCP organization. When you deploy HCP Vault Dedicated, you select a supported cloud service provider (CSP). Both the HCP organization and CSP are dedicated to a single HCP customer.
Vault's data is encrypted and stored in an account-specific storage disk in the same region as the cluster.
Encryption key ownership
A unique Key Management Service (KMS) cryptographic key is used for automatic unsealing of HCP Vault Dedicated clusters and encrypting all cluster snapshots. This key is managed in the organization's dedicated HCP tenant using the cloud provider’s KMS and is configured to be trusted by the HCP Vault Dedicated compute instances. This key is managed using carefully crafted, secure policies and all usage is audited. The key is not shared between clusters or tenants.
Managed policies
HashiCorp uses a number of policies to manage HCP Vault Dedicated clusters:
The Managed Service Provider (MSP) policy is used to perform updates on all HCP Vault Dedicated clusters. This policy allows us to manage and access policies required for the HCP Vault Dedicated service where we may periodically add new management functionality.
The Disaster Recovery (DR) Primary policy is used to manage replication operations on the primary cluster in a DR setup.
The Performance Replication (PR) Secondary policy is used to manage replication operations on the secondary cluster in a PR setup.
When an update takes place using any of these policies, a root token is
generated, and is visible in the audit logs. The root token is part of the platform
management of your cluster and will only be used to access non-user managed paths
(i.e., only root level sys
paths). Once the update is completed, the root token is
destroyed. Please ignore any root token audit logs tied to the msp
, dr-primary
, or
pr-secondary
policies. Additionally, 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
Snapshots are available for production tier clusters. For these clusters, HashiCorp performs snapshots daily and before any upgrades. You may also capture snapshots on demand. Snapshots are encrypted using a dedicated encryption key from the CSP account where the cluster was created and stored in HashiCorp's managed, encrypted Amazon S3 buckets in the US.
Audit logs
Audit logs are accessible to production tier clusters. Audit logs are stored in encrypted object storage with the CSP, and in the same region where the HCP Vault Dedicated cluster was deployed.
If desired, you can upload this data to your existing security information and event management (SIEM) platform using one of the supported integrations.
Namespace API lock
Namespace API lock and unlock can be used directly by the Vault cluster administrator to block most Vault API endpoints in the admin namespace or its descendants. Besides the endpoint for namespace unlock, its mostly the unauthenticated ones which remain available (e.g. sys/health). The same functionality can be accessed through the HCP Vault Dedicated UI, where previously we offered the cluster seal functionality.
Root token
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.
The Vault cluster administrator can generate an admin token when the cluster is ready to perform the initial HCP Vault Dedicated configuration.
Cluster auto unseal
Cluster auto unseal is managed by HashiCorp. For each Vault cluster a unique key is created in either AWS Key Management Service (KMS) or Azure Key Vault, depending on the cloud provider where the cluster was deployed. This key is trusted by the instances that are backing the Vault cluster and configured to be used as the autounseal mechanism.
External AWS KMS or Azure Key Vault keys are not supported.
Cluster hardening
Clusters adhere to our production hardening guidelines.
End-to-end TLS - Instances use
LetsEncrypt
certificates 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 and TCP/5696 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
-namepace
(-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. <namespace>/sys/leader
).
Changing /sys/metrics
to an authenticated endpoint to be accessible only to
production tier clusters is planned.
GDPR data processing agreement
HashiCorp supports General Data Protection Regulation (GDPR) Data Processing Agreement (DPA) for HCP Vault Dedicated.
HIPAA business associate agreement
HIPAA Business Associate Contracts (BAAs) are not supported.
Support
Please contact HashiCorp support for security questions, concerns, or feature requests.