Secrets Manager Migration Workflow
Inventory hardcoded and config-file secrets, migrate them to a secrets manager with references, rotate on migration, and remove the old plaintext copies.
Objective
Move scattered plaintext secrets into a managed store with rotation and a removal plan for the old copies.
Environment
- A secrets manager
- Access to application configuration and repositories
Steps
1. Inventory secrets in code, config,
Inventory secrets in code, config, and CI settings.
Expected state: You know the full scope to migrate.
2. Store each secret in the manager
Store each secret in the manager and reference it at deploy time.
Expected state: Apps read secrets from one managed source.
3. Rotate each secret as it
Rotate each secret as it is migrated.
Expected state: Migrated secrets are also fresh.
4. Remove plaintext copies and add scanning
Remove plaintext copies and add scanning to catch new ones.
Expected state: The old exposure is closed and cannot recur.
Decision points
Rotate during migration or after?
- During migration
- After everything moves
Rotate during migration so a leaked copy is invalidated immediately.
Big-bang or per-app?
- Per application
- All at once
Per application lets you verify runtime resolution and rollback one service at a time.
Expected outcome
Secrets live only in the secrets manager, are referenced at runtime, have been rotated, and plaintext copies are gone.
Verification
Confirm the repository and config scanners find no plaintext secrets and that applications resolve all secrets from the manager at runtime.
Cleanup
Record the migration inventory and enable ongoing secret scanning in CI.
Overview
Move scattered plaintext secrets into a managed store with rotation and a removal plan for the old copies. Confirm the repository and config scanners find no plaintext secrets and that applications resolve all secrets from the manager at runtime.
Steps
- Inventory secrets in code, config, and CI settings. Expected state: You know the full scope to migrate.
- Store each secret in the manager and reference it at deploy time. Expected state: Apps read secrets from one managed source.
- Rotate each secret as it is migrated. Expected state: Migrated secrets are also fresh.
- Remove plaintext copies and add scanning to catch new ones. Expected state: The old exposure is closed and cannot recur.
aws secretsmanager create-secret --name app/db --secret-string file://secret.json
# app reads at runtime, not from a committed file
export DB_URL=$(aws secretsmanager get-secret-value --secret-id app/db --query SecretString --output text)
Verification
- Secrets live only in the secrets manager, are referenced at runtime, have been rotated, and plaintext copies are gone.
Decision points
- Rotate during migration or after? Options: During migration; After everything moves. Recommended: Rotate during migration so a leaked copy is invalidated immediately.
- Big-bang or per-app? Options: Per application; All at once. Recommended: Per application lets you verify runtime resolution and rollback one service at a time.