> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Transit Secrets Engine
> This article explores HashiCorp Vault’s Transit Secrets Engine for encryption-as-a-service and centralized key management.
Explore how HashiCorp Vault’s Transit Secrets Engine provides encryption-as-a-service, centralizing key management while keeping your applications agnostic of encryption details.
## Enterprise Encryption Challenges
Most enterprises deploy three-tier applications (web tier → app tier → database). Storing sensitive data (PII, credit cards) in clear text poses a serious security risk.
Storing sensitive data in plaintext can lead to breaches if your database is misconfigured or compromised.
## Encryption Options for Data at Rest
To protect data at rest, teams typically choose between:
1. **Database-native encryption**
2. **Application-level encryption** using external SDKs or APIs
### Drawbacks of Database-Native Encryption
Relying on built-in database features can lock you into a specific platform. For example, you might choose Cassandra for scale but switch to MSSQL solely for encryption support.
### Siloed Developer Encryption
When each team implements its own solution, you end up with:
* Team A: OpenSSL
* Team B: Go libraries
* Team C: .NET APIs
* Team D: In-house tool
* Team E: Third-party service
Security teams specialize in cryptography. Let Vault handle keys and operations so developers focus on code.
## Introducing the Transit Secrets Engine
Vault’s Transit Secrets Engine offers a unified encryption service:
* Applications send plaintext data to Vault over TLS
* Vault encrypts with a centrally managed key
* Vault returns ciphertext
* Applications store ciphertext anywhere (DB, object store, etc.)
Applications never handle encryption keys directly. This decouples storage from encryption, harmonizes security across teams, and supports multiple applications against a single Vault cluster.
## Key Features
* Encrypt/decrypt over HTTP API
* Centralized key management inside Vault
* Auto-unseal support with Cloud KMS integrations
* Stateless engine—Transit doesn’t store data
Each application can have dedicated keys and fine-grained policies (encrypt-only, decrypt-only, or both).
## Supported Key Types
Below is a summary of common Transit key types:
| Key Type | Use Case | Notes |
| ----------------- | ---------------------- | ---------------- |
| aes256-gcm96 | Symmetric encryption | Default |
| chacha20-poly1305 | Symmetric encryption | High performance |
| ed25519 | Signing & verification | Modern elliptic |
| rsa-2048 | Signing & verification | Asymmetric |
Vault also supports **convergent encryption**, where identical plaintexts always produce the same ciphertext, enabling efficient searches over encrypted data.
All plaintext must be Base64-encoded before sending to Transit (this is encoding, not encryption).
***
## Hands-On: Enable, Create Key, Encrypt & Decrypt
Enable the Transit engine:
```bash theme={null}
vault secrets enable transit
# Success! Enabled the transit secrets engine at: transit/
```
Create an encryption key named `training`:
```bash theme={null}
vault write -f transit/keys/training
# Success! Data written to: transit/keys/training
```
Encrypt Base64-encoded data:
```bash theme={null}
vault write transit/encrypt/training \
plaintext=$(base64 <<< "Getting Started with HashiCorp Vault")
# Key Value
# --- -----
# ciphertext vault:v1:FYpph6C7r5MUILIiEiFhCoJBxelQbsGe...
# key_version 1
```
Decrypt ciphertext:
```bash theme={null}
vault write transit/decrypt/training \
ciphertext="vault:v1:FYpph6C7r5MUILIiEiFhCoJBxelQbsGe..."
# Key Value
# --- -----
# plaintext R2V0dGluZyBTdGFydGVkIHdpdGggSGFzaGlDb3JwIFZhdWx0Cg==
```
***
## Rotating & Configuring Keys
Rotate a key (manual or via `auto_rotate_period`):
```bash theme={null}
vault write -f transit/keys/training/rotate
# Success! Data written to: transit/keys/training/rotate
```
Inspect key metadata:
```bash theme={null}
vault read transit/keys/training
# Key Value
# --- -----
# keys map[1:1647960245 2:1647960257 3:1647961177]
# latest_version 3
# min_decryption_version 1
# ...
```
Set the minimum decryptable version:
```bash theme={null}
vault write transit/keys/training/config \
min_decryption_version=4
# Success! Data written to: transit/keys/training/config
```
Applications using ciphertext from versions below this threshold will be refused decryption.
## Rewrapping Ciphertexts
To upgrade existing ciphertext to the latest key version—without exposing plaintext—use `rewrap`:
```bash theme={null}
vault write transit/rewrap/training \
ciphertext="vault:v1:FYpph6C7r5MUILIiEiFhCoJBxelQbsGe..."
# Key Value
# --- -----
# ciphertext vault:v4:RPzp1kMpjtUIis+6qxrNjIE...
# key_version 4
```
Rewrap operations keep data protected entirely within Vault.
***
## Policy Example
Grant an application the ability to encrypt and decrypt using `training`:
```hcl theme={null}
# Encrypt capability
path "transit/encrypt/training" {
capabilities = ["update"]
}
# Decrypt capability
path "transit/decrypt/training" {
capabilities = ["update"]
}
```
***
## Links and References
* [HashiCorp Vault Transit Secrets Engine](https://www.vaultproject.io/docs/secrets/transit)
* [Vault HTTP API](https://www.vaultproject.io/api-docs)
* [Vault Tokens and Policies](https://www.vaultproject.io/docs/concepts/policies)
* [HashiCorp Certified: Vault Associate](https://www.hashicorp.com/certification/vault-associate)