Vault Transit Secrets Engine: Central Encryption Service

HashiCorp Vault Transit lets apps encrypt data via HTTP while keeping keys inside Vault. This post shows a CLI walk‑through, key rotation, audit logging, and the latency and availability trade‑offs to consider.

The problem: encryption keys sitting beside the data they protect

Many teams store an encryption key in application configuration or environment variables. The key travels with code, containers, and pipelines, exposing a single point of compromise. Compliance demands traceability of decryption, but application‑level logging is fragile.

Transit: a key‑custody model that never hands keys to your code

HashiCorp Vault’s Transit secrets engine keeps AES‑256‑GCM keys inside Vault. Applications send plaintext to Vault over HTTP; Vault encrypts or decrypts and returns the result. The key never leaves the cluster, eliminating the risk of key leakage.

Key features that matter to engineers

Key versioning and rotation: Create a new key version with vault write -f transit/keys/mykey/rotate. New encryptions use the latest key; older ciphertext remains decryptable with earlier versions.
Audit logging: Enable an audit device (e.g., vault audit enable file file_path=/tmp/vault_audit.log) to capture every encrypt/decrypt request with immutable request/response IDs.
Zero key exposure: The application never sees the raw key material; only ciphertext travels back and forth.

Concrete CLI walk‑through

Assumptions: a running Vault cluster, VAULT_ADDR and VAULT_TOKEN exported, and a token with create and update permissions on transit/keys/*.

vault secrets enable transit
vault write -f transit/keys/mykey
vault write -format=json transit/encrypt/mykey plaintext=$(base64 <<< 'hello')

The encrypt call returns JSON containing a ciphertext field like vault:v1:.... Use that in a decrypt call:

vault write -format=json transit/decrypt/mykey ciphertext="vault:v1:..."

Decode the returned plaintext with base64 -d and verify it matches the original string.

Trade‑offs to weigh before production use

Latency & CPU: Each encrypt/decrypt is a network round‑trip plus cryptographic work on a Vault node. High‑throughput workloads may need performance testing or caching of decrypted values.
Availability: Transit is a single point of failure if the Vault cluster goes down. Deploy Vault in HA mode and maintain a disaster‑recovery plan.
Payload size: The API is intended for small fields (SSNs, tokens). For large blobs, use envelope encryption: generate a data key locally, encrypt the bulk data, then wrap that key with Transit.

How to verify your integration works

Create a test key and encrypt a known plaintext.
Decrypt the ciphertext and confirm the plaintext matches.
Check the audit log for matching request IDs on both calls.
Verify key rotation leaves older ciphertext decryptable.

If all checks pass, you can safely move key custody to Vault while keeping the application logic simple.

The post correctly notes Transit is designed for small fields. For larger data, the standard pattern is envelope encryption: generate a random data encryption key (DEK) locally, encrypt your bulk data with the DEK (using AES-GCM or similar), then send only the DEK to Transit for wrapping. Store the wrapped DEK alongside the ciphertext. This keeps network payloads tiny while Vault still manages the master key hierarchy. When decrypting, unwrap the DEK via Transit first, then decrypt locally. This also lets you rotate the master key in Transit without re-encrypting all your data—just re-wrap the DEKs. For very high throughput, consider batching wrap/unwrap calls or using connection pooling to amortize round-trip latency.