Skip to main content
Vault’s Transit Auto Unseal method offloads unseal operations to a dedicated Transit Secrets Engine running in a separate Vault cluster. This approach protects the master key and enables automatic unsealing of dependent clusters on startup.

​
Architecture Overview

One Vault cluster (the “unsealer”) runs the Transit Secrets Engine and holds the encryption key for unsealing. Other clusters delegate their unseal operations to this central cluster:
The image illustrates the process of unsealing with Transit Auto Unseal, showing a flow from a Vault Cluster to a Master Key, then to an Encryption Key, and finally to Vault Data. It includes icons representing each component and a character illustration in the corner.
Each dependent cluster connects to the Transit cluster using the configured key. You can chain dependencies (green unseals from orange, red from green, etc.), but the core pattern remains: one cluster auto-unseals from another.
The image illustrates the concept of "Unsealing with Transit Auto Unseal," showing a central "Vault Cluster (Running Transit)" connected to multiple "Other Vault Clusters In the Organization" with arrows indicating interaction.

​
Key Features

The image is a slide titled "Unsealing with Transit Auto Unseal," listing features such as using a different Vault cluster's Transit Secret Engine, key rotation support, and availability in open source and Enterprise. It also mentions the need for a highly-available core Vault cluster.
If the central Transit cluster becomes unavailable, all dependent Vault clusters will fail to unseal. Ensure your Transit cluster is highly available and monitored.

​
Configuration

To enable Transit Auto Unseal, add a seal stanza to your Vault configuration file:
  • address and token point to the central Vault cluster running Transit.
  • key_name, mount_path, and namespace identify which key to use.
  • TLS settings ensure secure communication between clusters.

Watch Video