← Workflows

阅读中文版本

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.

advanced~180 minsecuritysecretsmigration

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

  1. Inventory secrets in code, config, and CI settings. Expected state: You know the full scope to migrate.
  2. 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 is migrated. Expected state: Migrated secrets are also fresh.
  4. 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.