HashiCorp Launches Vault Security Platform for Cloud Environments

HashiCorp has launched Vault, a new tool for securely managing secrets and encrypting data in-transit. From storing credentials and API keys to encrypting passwords for user signups, Vault is being offered as a new solution for security in cloud environments.

Vault secures, stores, and tightly controls access to tokens, passwords, certificates, API keys, and other secrets in modern computing. Vault handles leasing, key revocation, key rolling, and auditing. Vault presents a unified API to access multiple backends including HSMs, AWS IAM, SQL databases, raw key/value, and more.

The goal of Vault is to manage secrets which, at the most fundamental level, include reading/writing arbitrary secrets to Vault securely. The data stored with Vault is encrypted using 256-bit AES in GCM mode with a randomly generated nonce. This encryption happens in-memory prior to ever being sent to the backend storage driver. This way the storage never sees the unencrypted value.

The key used to encrypt the data is also encrypted using 256-bit AES in GCM mode. This is known as the master key. The encrypted encryption key is stored in the backend storage. The master key is then split using Shamir's Secret Sharing. Shamir's Secret Sharing ensures that no single person (including Vault) has the ability to decrypt the data. To decrypt the data, a threshold number of keys (by default three, but configurable) are required to unseal the Vault. These three keys are expected to be with three different individuals.

With the Vault unsealed, all API calls are done with HTTP over TLS. While it is possible to disable TLS, it requires explicitly opting into it both on the server as well as all clients.

All API calls to Vault require an identity obtained through authentication. This identity is mapped to various metadata. The identity and metadata are logged with every audit log entry. For example, if you use GitHub for authentication, the GitHub username and organization of the user is in the audit logs. If you use certificate authentication, the fingerprint of the client certificate is logged.

Within Vault, data is split into multiple backends. For example, when you write data to secret/foo, it is communicating with a different secret backend than when you read a PostgreSQL credential from postgresql/creds. Each backend is given a restricted view to the backend data. The backend at secret/foo can never access the data at postgresql/creds, for example. This isn't just an ACL; the backends themselves simply do not have a way to address data from other backends. This ensures that even within Vault there is protection against malicious activity.

- Secure secret storage: Arbitrary key/value secrets can be stored in Vault. These secrets are encrypted prior to being written to persistent storage, so gaining access to the raw storage isn't enough to access your secrets. Vault can write to disk, Consul, and more.

- Dynamic secrets: Vault can generate secrets on-demand for some systems, such as AWS or SQL databases. For example, when an application needs to access an S3 bucket, it asks Vault for credentials, and Vault will generate an AWS keypair with valid permissions on demand. After creating these dynamic secrets, Vault will also automatically revoke them after the lease is up.

- Leasing and renewal: All secrets in Vault have a lease associated with it. At the end of the lease, Vault will automatically revoke that secret. Clients are able to renew leases via built-in APIs.

- Revocation: Vault has built-in support for secret revocation. Vault can revoke not only single secrets, but also a tree of secrets. For example, Vault can revoke all secrets read by a specific user or all secrets of a specific type. Revocation assists in key rolling as well as locking down systems in the case of an intrusion. This also allows for organizations to plan and train for various "break glass" procedures.

- Data encryption: Vault can encrypt and decrypt data without storing it. This allows security teams to define encryption parameters and developers to store encrypted data in a location such as a SQL database without having to design their own encryption methods.

- Auditing: All access to Vault can be sent to multiple audit backends. This includes any request to Vault: successes, failures, configuration, data access, etc. Audit logs can be sent to syslog, files, and more. Multiple audit backends can be enabled to have redundant copies of audit logs.

- Access control policies: ACLs can be created to restrict or grant fine-grained access to any feature of Vault. This is a critical feature for a secret management system.

- Multiple authentication methods: Vault includes multiple methods for authentication (each enabled individually) so you can choose what works best with your organization. For 0.1, Vault supports tokens, username/password, GitHub, certificates, and more. In the future, many more will be added.