The Transit secret engine in HashiCorp Vault is surprisingly not for storing your secrets directly, but for encrypting and decrypting them using cryptographic keys managed by Vault itself.
Let’s see it in action. Imagine you have a sensitive API key you don’t want to store unencrypted in a configuration file, but you also don’t want to manage the encryption keys yourself.
# 1. Enable the Transit engine
vault secrets enable transit
# 2. Create a named encryption key
vault write transit/keys/my-api-key
# 3. Encrypt your secret
# The output will be a base64 encoded ciphertext
vault write transit/encrypt/my-api-key plaintext=$(echo -n "s3cr3t_4p1_k3y_v4lu3" | base64)
# Example Output:
# Key Value
# --- -----
# ciphertext vault:v1:ey... (long base64 string)
# 4. Store the ciphertext in your config file instead of the plaintext secret.
# 5. When your application needs the secret, it retrieves the ciphertext and asks Vault to decrypt it.
vault write transit/decrypt/my-api-key ciphertext="vault:v1:ey..."
The core problem Transit solves is offloading the burden of key management and cryptographic operations from your applications. Instead of every service needing to know how to encrypt/decrypt using a specific algorithm and managing its own key material, it simply calls Vault. Vault acts as a centralized, auditable, and secure cryptographic service.
Internally, when you create a key with transit/keys/<key-name>, Vault generates a symmetric encryption key (AES-256-GCM by default) and stores its metadata. The actual key material never leaves Vault’s secure storage. When you encrypt, Vault uses this managed key to perform the AES-GCM encryption and returns the ciphertext. Decryption works in reverse: Vault takes the ciphertext, uses its managed key to decrypt it, and returns the plaintext. This means your application only ever sees the plaintext secret during the brief moment it’s being processed by Vault for encryption or decryption.
The primary levers you control are the key names, the encryption algorithms (though AES-256-GCM is the default and often sufficient), and the key rotation policies. You can configure keys to automatically rotate, ensuring that even if a past ciphertext were somehow compromised, it would only be decryptable with the then-current key.
A key aspect often overlooked is that the Transit engine supports several cryptographic operations beyond simple encryption and decryption. For instance, you can use it for signing and verification (transit/sign/<key-name>, transit/verify/<key-name>), generating random data (transit/random/<key-name>), and even performing HMAC operations. This makes Transit a versatile cryptographic toolkit for your infrastructure, allowing you to consolidate various crypto needs into a single, secure service.
The next challenge you’ll likely encounter is managing how your applications authenticate to Vault to access the Transit engine.