Choosing Vault’s Transit Engine for Stateless Encryption: Decision Guide

Why the Decision Matters

When a micro‑service needs to protect sensitive payloads without storing plaintext, Vault’s Transit Secrets Engine offers a dedicated, stateless encryption‑as‑a‑service (EaaS) solution. The choice between Transit, KV v2, or PKI hinges on how you want to handle key material, rotation, and auditability.

Decision Context & Constraints

• Stateless services that cannot hold key material locally.
• Need for automatic key rotation without manual key distribution.
• Desire to keep ciphertext separate from key metadata in Vault.
• Compliance requires audit logs of encryption/decryption operations but not of plaintext.
• Application must be able to re‑encrypt existing data when a key rotates.

Supported Options in a Compact Table

Engine	Primary Use	Key Management	Rotation Support	Audit Visibility
Transit	Stateless encryption‑as‑a‑service	Only key material stored; ciphertext never persisted in Vault	Yes – key versioning; can force rotation policy	Encrypt/decrypt calls logged; no plaintext exposure
KV v2	Configuration store, optional encryption	Stores keys and values; can enable encryption at rest	Key rotation requires re‑writing stored data	Full read/write logs of key/value pairs
PKI	Certificate issuance	Manages CA keys; certificates are the secrets	CA key rotation invalidates certs; renewal needed	Certificate issuance/deletion logged

Trade‑Off Analysis

• Transit vs KV v2: Transit keeps ciphertext outside Vault, ideal for services that should never see plaintext. KV v2 can store encrypted data, but the service still handles encryption logic and may inadvertently expose keys.
• Transit vs PKI: PKI is for certificates, not arbitrary data. If your service needs to encrypt logs or user data, PKI is inappropriate.
• Key Rotation: Transit’s versioned keys allow seamless rotation; KV v2 requires re‑encryption of all stored values, which can be costly for large datasets.
• Auditability: Transit logs the operation context (client IP, token, etc.) but never logs plaintext. KV v2 logs every read/write, which may reveal sensitive data if not encrypted at rest.
• Operational Complexity: Transit requires an extra API call per encryption/decryption but eliminates the need to manage key material in the application.

Concrete Implementation & Validation

Below is a step‑by‑step example using Vault 1.13+ on a Linux host. Replace placeholders with your environment values.

1. Enable the Transit engine

   # Run as a user with the "sudo" or "root" role
   vault secrets enable transit
   vault secrets list
   

   Check that transit/ appears in the list.

2. Create a key

   vault write -f transit/keys/enc-key
   vault read transit/keys/enc-key
   

   Verify the output shows key_type=transit and key_hmac_type=sha2-256. The latest_version will be 1.

3. Encrypt data

   # Create a plaintext file
   printf "sensitive data" > plain.txt
   
   # Encrypt via API
   vault write transit/encrypt/enc-key plaintext=@plain.txt > enc.json
   cat enc.json
   

   The response contains a ciphertext field. Do not store this file in Vault; keep it in your application or a secure store.

4. Decrypt data

   vault write transit/decrypt/enc-key ciphertext=<ciphertext> > dec.json
   cat dec.json
   

   Compare the plaintext field with the original file. They should match.

5. Audit log verification

   # Assuming audit device is file‑based
   cat /var/log/vault/audit.log | grep "transit/encrypt/enc-key"
   cat /var/log/vault/audit.log | grep "transit/decrypt/enc-key"
   

   Each entry should include the client IP, token ID, and the request path. No plaintext should appear.

6. Key rotation

   # Rotate the key
   vault write transit/keys/enc-key/rotate
   vault read transit/keys/enc-key
   

   The latest_version will increment. Existing ciphertext encrypted with version 1 will remain decryptable but will not be re‑encrypted automatically.

Practical Checkpoints

• After encryption, run vault read transit/encrypt/enc-key and confirm the ciphertext field exists.
• After decryption, compare the plaintext field to the original file using diff or sha256sum.
• Verify audit logs contain entries for both encrypt and decrypt calls.
• After rotation, attempt to decrypt the old ciphertext; it should succeed if the key version is still available.

Limitations & Mitigations

• Rotation invalidates old ciphertext if the key is deleted or the rotation policy forces a new key. Mitigate by storing ciphertext in a separate, versioned store and re‑encrypting when rotation occurs.
• Audit logs do not capture plaintext. Ensure your compliance framework logs the operation context (client IP, token, request path) to satisfy audit requirements.
• Transit does not provide a built‑in key backup mechanism. Back up Vault’s storage backend to recover key material.

When to Choose Transit

• Your services are stateless and cannot hold key material.
• You need a single source of truth for encryption keys with automated rotation.
• Compliance demands that plaintext never resides in Vault or the client.
• You prefer to keep ciphertext outside Vault to avoid accidental exposure.

When to Choose KV v2 or PKI Instead

• Storing configuration data that may be encrypted at rest but is read often.
• You need to manage secrets that are not purely ciphertext (e.g., passwords, API keys).
• Certificates or certificate signing requests are the primary secret type.

Conclusion

Vault’s Transit engine is the go‑to solution for stateless, encryption‑as‑a‑service scenarios. Its key‑only storage, versioned rotation, and audit‑friendly API make it a robust choice for modern micro‑services. Use the steps above to enable, test, and validate Transit in your environment, and remember to plan for key rotation and audit compliance.