DEV Community

Cover image for Secrets Management — Vault, SSM, and Secrets Manager Compared
Gorav Singal
Gorav Singal

Posted on

Secrets Management — Vault, SSM, and Secrets Manager Compared

#security

I've watched a production database get wiped because someone committed a root password to a public GitHub repo. It took less than twelve minutes from push to compromise. Automated bots scan every public commit for secrets — and they find them constantly.

If secrets management isn't the first security problem you solve, nothing else matters. Here's a condensed comparison of the three tools I reach for in practice.

The Problem

A "secret" is any credential your app needs at runtime but should never be visible in source code, logs, or config files — database passwords, API keys, TLS certs, OAuth tokens.

The naive approach (env vars, config files in version control) fails because:

  • Git history is forever — deleting a secret in a later commit doesn't remove it from history
  • Env vars leak — process listings, crash dumps, and logging frameworks routinely expose them
  • No rotation — baked-in secrets mean redeploying everything to rotate
  • No audit trail — you can't tell who accessed what and when

The Three Tools

1. SSM Parameter Store

The simplest option. A key-value store baked into AWS with native IAM integration.

aws ssm put-parameter \
  --name "/prod/myapp/db-password" \
  --value "s3cureP@ssw0rd!" \
  --type SecureString \
  --key-id "alias/myapp-key"
Enter fullscreen mode Exit fullscreen mode

The hierarchical naming (/prod/myapp/db-password) maps directly to IAM policies — grant access to /prod/myapp/* without exposing /prod/billing/*.

Use when: Simple config and secrets that don't need auto-rotation. Free standard tier covers most teams (up to 10,000 parameters).

2. AWS Secrets Manager

The killer feature is built-in automatic rotation via Lambda, plus first-class RDS/Redshift/DocumentDB support.

The rotation flow: a Lambda creates a new credential, sets it as pending, tests it, then promotes it to current. If any step fails, the current secret stays untouched.

Use when: Database credentials needing auto-rotation, versioned secrets, cross-account sharing. $0.40/secret/month.

3. HashiCorp Vault

Vault isn't just a secrets store — it's a secrets engine. It generates short-lived, on-demand credentials for databases, cloud providers, PKI, and SSH.

# Get a dynamic credential (valid for 1 hour)
vault read database/creds/myapp-readonly
Enter fullscreen mode Exit fullscreen mode

Every call creates a brand-new database user with a unique password. When the TTL expires, Vault revokes it automatically. No rotation needed — credentials are ephemeral by design.

Use when: Multi-cloud environments, dynamic credentials, PKI management, encryption-as-a-service. The tradeoff is operational complexity.

Quick Comparison

Dimension SSM Parameter Store Secrets Manager HashiCorp Vault
Cost Free (standard) $0.40/secret/month Self-hosted or HCP
Auto-Rotation Manual only Built-in (Lambda) Dynamic secrets
Multi-Cloud AWS only AWS only Any cloud + on-prem
Dynamic Secrets No No Yes
Complexity Low Medium High

My rule of thumb: Start with SSM. Graduate to Secrets Manager when you need rotation. Move to Vault when you need multi-cloud or dynamic secrets.

Common Pitfalls

  1. Secrets in env vars logged to stdout — frameworks like Express, Django, and Spring dump env vars in error pages. Use a secrets SDK instead.

  2. No caching layer — calling Secrets Manager on every request adds 5-15ms latency and costs money. Cache with a 5-minute TTL.

  3. Terraform state with plaintext secrets — aws_secretsmanager_secret_version stores values in plaintext in state. Encrypt your state backend (S3 + KMS).

  4. Overly broad IAM policies — ssm:GetParameter on * means every Lambda reads every secret. Scope to specific paths.

  5. No secret scanning in CI/CD — tools like gitleaks or GitHub's built-in scanning should be mandatory. The twelve-minute push-to-compromise window is real.

Key Takeaways

  • Never hardcode secrets — not in code, config, Docker images, or logged env vars
  • Encrypt at rest (KMS) and in transit (TLS), no exceptions
  • Cache aggressively to balance freshness against latency
  • Audit everything — if you can't answer "who accessed this at 3am Tuesday," it's incomplete
  • Rotate or go ephemeral — long-lived, never-rotated secrets are ticking time bombs

This is a condensed version. For the full article with complete code examples (Python, Node.js, Terraform), rotation Lambda patterns, and detailed implementation walkthroughs, read the full post on gyanbyte.com.

Top comments (0)