Vault 1.0: How to Auto-Unseal and Other New Features

Since its first release in 2015, HashiCorp Vault has grown from a place to keep secrets to a platform that provides comprehensive secrets management, encryption as a service, and identity-based security for some of the largest organizations in the world. It enables users to centrally manage secrets to enforce access to systems, applications, and protect sensitive data. With the understanding that solving the secrets management problem can be complex, each release of Vault has been aimed at addressing this complexity through features such as encryption as a service, dynamic credentials, automatic key rotation, auto unseal, and more.

HashiCorp Vault 1.0 is the culmination of a journey that brings broad ecosystem integration, feature completeness, and enterprise readiness to the popular secrets management tool.

In the last release of HashiCorp Vault 0.11, we introduced Namespaces, Vault Agent, and many more new features, paving the way for Vault 1.0. At HashiCorp, Vault 1.0 means ensuring major use cases are understood and well supported with a mature technical architecture and implementation that is highly stable for the intended use cases.

The user experience and workflow of the project is well defined, easy to learn, and enables the major use cases in practice. The focus is on feature completeness, enterprise stability, ecosystem integration, and scale and includes new features like deeper integration with Kubernetes, helm charts, Auto Unseal for open source, and batch tokens for enabling serverless and high scale batch processing use cases, and many other enhancements.

What you'll learn

• Automate the ability to unseal Vault through the use of cloud KMS providers.
• Provide the ability for existing shamir-encrypted clusters to transition to auto-unseal model
• Improve performance during write-heavy operations such as Vault authentication through the use of batch tokens

Agenda

0:00 — Introduction

3:30 — Auto Unseal

9:45 — Seal Migration

15:45 — Batch Tokens

30:00 — Q&A

Q&A

• Is there also support for credentials through the Instance Profile rather than environment variables? Yes

• After manually sealing Vault, would restarting the server unseal it automagically? Yes

• During auto-unseal, if you manually seal vault, and you restart the Vault process, does it remain sealed, or is it auto-unsealed? Unsealed

• Why do we need to use a recovery key to unseal Vault? As long as we restart the service, won’t Vault will be auto unsealed? Recovery keys can be used to make Vault operable if Vault has been manually sealed through the vault operator seal command, for instance. Recovery keys are also used for high-privilege operations such as rekey and root token generation.

• If we use Shamir on Enterprise right now, is there NO migration path to auto-unseal now? No

• Is auto-unseal a Enterprise feature? Yes, but it was also added to the open source version recently for Cloud KMS providers.

• Is seal migration an Enterprise feature? No

• Can you explain the interaction with cloud and security around the auto unseal process? Vault server uses the key ID of the KMS key to interact with the cloud KMS to encrypt the master token and store the encrypted master token in Vault’s storage.

• Is the token_type param valid for all auth methods, like userpass and GitHub? Yes. Token types can be tuned on the mount. It is applicable for all auth methods.

• You mentioned supporting different key types, (AES GCM or AES CBC). How do you specify that? In the seal block of the configuration.

• Since the storage backend is untrusted, is it safe for Vault in auto-unseal mode to store the master key in there? The master key that Vault stores in its storage backend is encrypted. In this case, we use the HSM or KMS provider to encrypt the master key before storing it.

• Can I auto-unseal using Azure and Google and AWS or only one of them? One

• What is passed over the wire? Master key/root key or unseal key? Master

• What happens to Shamir keys when we migrate to Auto Unseal? They become the recovery keys.

• If HSM is not accessible, can we use the recovery key to unseal Vault instead of auto unseal? No, you cannot auto-unseal if the HSM on the KMS provider is unavailable.

• Is the HSM auto unseal using PKCS11 still available only in Enterprise? Or is it open sourced now? It is still an Enterprise feature.

• Can you configure the number of recovery keys and the threshold with auto unseal? Yes

Slides