Secrets Management vs Key Management

Secrets management and key management solve related but distinct problems. Secrets management is about securely storing and delivering sensitive values — passwords, API keys, database connection strings, tokens — to applications that need them at runtime. Key management is about the lifecycle of cryptographic keys — generating them securely, controlling who can use them, rotating them on schedule, and ensuring they’re never exposed outside their secure boundary. The key distinction: secrets are delivered to applications (the app gets the value). Cryptographic keys in a KMS are used by the KMS on behalf of applications (the app never gets the key).

Why it matters

• Different threat models — a leaked secret (password, API key) is immediately exploitable. A leaked encryption key compromises all data encrypted with it (potentially years of data). The protection requirements differ.
• Different lifecycles — secrets are often short-lived and frequently rotated (database passwords every 30 days). Cryptographic keys may have multi-year lifecycles with complex rotation procedures (re-encrypting existing data).
• Different access patterns — applications need to read secrets (get the database password). Applications need to use keys (encrypt this data) without reading them (never see the raw key material).
• Compliance requirements — PCI DSS, HIPAA, and NIST SP 800-57 have specific requirements for cryptographic key management (HSM storage, split knowledge, ceremony procedures) that don’t apply to general secrets.
• Tooling overlap — HashiCorp Vault does both (secrets engine + PKI/transit engine). AWS has both Secrets Manager (secrets) and KMS (keys). Understanding which tool serves which purpose prevents misuse.

How it works

Secrets Management:

1. Secret stored in vault (encrypted at rest)
2. Application authenticates to vault (IAM role, K8s service account, AppRole)
3. Vault checks authorization policy (is this app allowed to read this secret?)
4. Secret value delivered to application (environment variable, file, API response)
5. Application uses the secret directly (connects to database with password, calls API with key)
6. Secret rotated periodically (vault generates new password, updates database, apps get new value)

Key Management:

1. Key generated inside KMS/HSM (never leaves the secure boundary)
2. Application sends data to KMS: “encrypt this plaintext with key X”
3. KMS performs encryption internally, returns ciphertext
4. Application stores ciphertext (database, S3, disk)
5. To decrypt: application sends ciphertext to KMS, receives plaintext back
6. Key rotated: KMS generates new key version, old version retained for decryption of existing data

The critical difference:

• Secrets management: the application receives the sensitive value
• Key management: the application never sees the key — only the results of operations performed with it

In real systems

Secrets management (HashiCorp Vault KV):

# Store a secret
vault kv put secret/production/database \
  username="app_user" \
  password="s3cur3P@ss" \
  host="db.internal:5432"

# Application retrieves the secret
vault kv get -field=password secret/production/database
# Returns: s3cur3P@ss (the actual value — app uses it directly)

# Dynamic secrets (Vault generates short-lived credentials)
vault read database/creds/readonly
# Returns: username=v-app-readonly-abc, password=xyz (valid 1 hour)

Key management (AWS KMS):

# Encrypt data (key never leaves KMS)
aws kms encrypt \
  --key-id alias/data-encryption-key \
  --plaintext fileb://sensitive-data.json \
  --output text --query CiphertextBlob > encrypted.b64

# Decrypt data (key never leaves KMS)
aws kms decrypt \
  --ciphertext-blob fileb://encrypted.b64 \
  --output text --query Plaintext | base64 -d > decrypted.json

# The encryption key NEVER appears in any API response
# You can't "get" the key — only use it for operations

Both together (envelope encryption):

# Pattern: KMS protects the key, secrets manager delivers it
# 1. Generate a data encryption key (DEK) via KMS
aws kms generate-data-key --key-id alias/master-key --key-spec AES_256
# Returns: Plaintext DEK (use once, discard) + Encrypted DEK (store)

# 2. Encrypt data with the plaintext DEK (locally, fast)
openssl enc -aes-256-gcm -in data.json -out data.enc -K $PLAINTEXT_DEK

# 3. Store encrypted DEK alongside encrypted data
# 4. Discard plaintext DEK from memory

# To decrypt: send encrypted DEK to KMS → get plaintext DEK → decrypt data locally
# KMS master key never leaves KMS. DEK exists in memory briefly.

Vault Transit engine (key management within Vault):

# Vault performs encryption — key never exposed
vault write transit/encrypt/my-key plaintext=$(echo "secret data" | base64)
# Returns: ciphertext:v1:abc123...

vault write transit/decrypt/my-key ciphertext="vault:v1:abc123..."
# Returns: plaintext (base64 encoded)

# Key rotation (new version, old data still decryptable)
vault write -f transit/keys/my-key/rotate

Where it breaks

Using secrets manager for encryption keys — a team stores an AES-256 key in AWS Secrets Manager and retrieves it in application code to perform encryption. The key exists in application memory, in Secrets Manager API responses, and potentially in logs. If the application is compromised, the key is exposed. Use KMS instead: the key never leaves the KMS boundary, and the application only sees ciphertext/plaintext — never the key itself.

Using KMS for everything — a team tries to use KMS to “store” database passwords by encrypting them with KMS and storing the ciphertext. To use the password, they decrypt via KMS API, get the plaintext password, and connect to the database. This works but adds latency and complexity for no security benefit over a secrets manager (the password is still exposed to the application). Use the right tool: KMS for encryption keys, secrets manager for credentials.

No rotation on either — secrets (API keys, passwords) are stored in Vault but never rotated. Encryption keys in KMS are created once and never rotated. Both accumulate risk over time. Secrets managers support dynamic secrets (auto-generated, short-lived). KMS supports automatic key rotation. Use these features — static secrets and static keys are the default failure mode.

Operational insight

The decision framework is simple: if the application needs to see the sensitive value to use it (password, API key, connection string, token), use a secrets manager. If the application needs cryptographic operations performed with a key but should never see the key itself (data encryption, signing, HMAC), use a key management system. Most applications need both: a secrets manager for database credentials and API keys, and a KMS for encrypting data at rest. The mistake is using one tool for both purposes — either exposing encryption keys unnecessarily (secrets manager for keys) or adding unnecessary complexity (KMS for passwords).

Related topics

• HashiCorp Vault and PKI
• Key Lifecycle Management
• What are Hardware Security Modules
• NIST SP 800-57 Key Management
• KMIP