Stop 12 · Security & DevSecOpsTopics · 2/9

Secrets Management (Vault, AWS Secrets Manager)

In short

One database password pasted into a config file ends up in Git history, Slack and backups. A secrets manager keeps it in one guarded place and hands it only to who needs it.

Dedicated tools for storing, rotating and controlling access to sensitive credentials — going beyond a CI/CD platform's built-in secrets (Phase 6) to a centralized, auditable system with fine-grained access control.

The mascot opens a small steel locker in a bank locker room, with a visitor register on the desk.

Think of it like this

The bank locker room

Your jewellery isn't kept in a kitchen drawer. It sits in a bank locker. Only listed people get in, the bank writes down every visit, and you can change the key if one is lost. A secrets manager is that locker for passwords and API keys.

Watch it happen

An app fetching its database password

App

Identity

Secrets store

Database

who am I?

1/6The app starts with no password at all. It proves its identity using the role attached to its server or pod.

The big ideas

What you need to know

One source of truth

Secrets live in one store, not copied into ten config files. Change it once and every app picks up the new value.

Every read is logged

An audit log shows which app or person read which secret and when. Very handy when something leaks.

Rotate regularly

Secrets managers can change passwords on a schedule. A leaked password that changes every 30 days has a short shelf life.

Dynamic secrets

Vault can create a fresh database user per app that expires after an hour. Nothing long-lived to steal.

See it in code

Walk through the code

bash

1# Store a secret once (AWS Secrets Manager)2aws secretsmanager create-secret \3  --name prod/orders/db-password \4  --secret-string 'S3cure-Example-Only'5 6# The app (or a script) reads it at runtime7aws secretsmanager get-secret-value \8  --secret-id prod/orders/db-password \9  --query SecretString --output text10 11# Same idea with HashiCorp Vault's key/value engine12vault kv put secret/orders db_password='S3cure-Example-Only'13vault kv get -field=db_password secret/orders

1/3Create the secret with a clear path-like name: environment, service, then what it is.

In a real app you'd call the SDK instead of the CLI, and the IAM role or Vault policy decides who can read prod/orders/db-password.

Save yourself the pain

Common mistakes

Oops

Committing a .env file with real keys and deleting it in the next commit.

Do this instead

Git keeps history, so the key is still there. Rotate the key immediately, then add .env to .gitignore.

Oops

Giving every service read access to every secret to keep things simple.

Do this instead

Scope access per service: the orders app reads only prod/orders/*. A breach then exposes one service, not all.

Your mission

Run Vault on your laptop

~30 min

Quick check

Why is a short-lived, auto-generated database password safer than a long-lived one?

Go deeper

1Explore HashiCorp Vault or AWS Secrets Manager's basic concepts (storing and retrieving a secret).
2Learn why secret rotation (regularly changing credentials) reduces the blast radius of a leak.
3Understand the audit trail benefit: knowing exactly who accessed which secret and when.