HashiCorp Developer AI Private beta now available Sign up today
HashiCorp Cloud Platform
HashiCorp Cloud Platform Home

Security overview

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.

Tip

Refer to the HashiCorp Cloud Platform (HCP) Architecture documentation to understand the platform architecture.

Vault data

Vault's data is encrypted and stored in an account-specific storage disk in the same region as the cluster.

MSP policy

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

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

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. Currently, few out of the box integrations are available.

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 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.

Note

The Vault cluster administrator is provided an admin token when the cluster is ready.

Cluster auto unseal

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.

Note

Externally provided 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:

Note

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.

HIPAA business associate agreement

HIPAA Business Associate Contracts (BAAs) are not supported.


Tip

Please contact HashiCorp support for security questions, concerns, or feature requests.