Cloud Parts

Secrets management

A locked vault for passwords, keys and tokens, handed out at runtime.

4 technologies on this page ↓
Live model
What you’re watchingThe app, running with an allowed role, gets the secret. The laptop script has no permission and is refused. Periodically the manager rotates the database password.

How it works

A secrets manager stores credentials encrypted and hands them only to callers whose identity is allowed to read them. Apps fetch secrets at startup or on demand instead of keeping them in code or config files. Every read is audited, and many managers rotate credentials automatically, changing the database password and the stored value together.

Think of it as

A hotel safe with an access log. Only the right keycard opens it, every opening is recorded, and the combination changes on a schedule.

Reach for it when

  • Database passwords, API keys, signing keys, certificates
  • Automatic credential rotation
  • Auditing who read which secret, and when
  • Finding secrets that leaked into code, wikis or chat anyway, with a scanner such as GitHub secret scanning, gitleaks, TruffleHog or HCP Vault Radar

Think twice when

  • Committing secrets to git, even in a private repository
  • Baking secrets into images or printing them in CI logs

A real example

The API’s role is allowed to read db/password, so it fetches the current value on boot. Every 30 days the manager rotates the database password. A script on someone’s laptop with no role is refused.

Technologies

Specific products, and what each does differently.

What each provider calls it

AWS
Secrets Manager, SSM Parameter Store
Google Cloud
Secret Manager
Azure
Key Vault
Open source & others
HashiCorp Vault, OpenBao, SOPS

In code · python

import boto3, json, psycopg
sm = boto3.client("secretsmanager")

secret = json.loads(sm.get_secret_value(SecretId="db/password")["SecretString"])
conn = psycopg.connect(host=secret["host"], user=secret["username"],
                       password=secret["password"], dbname="app")

Worth exploring

WebsitePlatform tooling landscapePlatformEngineering.orgA filterable map of tools for building an internal developer platform. Each tool sits in one of five “planes” (developer control, integration and delivery, resource, observability, security) and a category such as IaC, CD pipeline, secrets or developer portal, with a one-line description. Vendors can submit their own tools, so treat it as a list of what exists rather than a ranking.
All resources →

Often confused with

Identity & access (IAM)AuthenticationVirtual private cloudsInfrastructure as code
Where it came from2015–2026

For a long time a database password lived wherever the code that needed it lived: in source code, in configuration files, in configuration management, or copied onto servers by hand. When Square open-sourced its own secrets tool in 2015, its engineers listed what was wrong with that. Source repositories exposed secrets to developers and CI systems that never needed them, hand-deployed secrets were scattered and impossible to audit, and configuration management tools, built to keep everything visible with full history, were exactly the wrong place for them.

The Twelve-Factor App methodology gave a simple test: could the codebase be made open source at any moment without compromising any credentials? Its answer was environment variables. Dedicated secret managers went further. In April 2015 Square released Keywhiz, which hands secrets to services as files over mutual TLS, and HashiCorp announced Vault, which also creates credentials on demand for each client and revokes them when their lease ends. In April 2018 AWS launched Secrets Manager with automatic rotation; until then, it noted, customers had to run extra infrastructure just to manage secrets.

Since then the push has been to need fewer stored secrets at all. GitHub began scanning public repositories for leaked tokens in 2018, and short-lived identity tokens, such as GitHub Actions’ OIDC tokens in 2021, let workloads reach clouds without any stored key.

Why it’s built this way

Keep secrets out of code and config files
Anything committed to a repository is exposed to everyone and every system that can read it, including CI, and config files are easy to commit by mistake. Storing secrets separately means code can be shared without sharing access.
Fetch at runtime, authorized by identity
A central store that checks who is asking and logs every read answers the question scattered config files never could: who has access to this secret, and who used it?
Rotate, or make credentials short-lived
A secret that never changes stays useful to an attacker forever. Automatic rotation limits that window, and dynamic secrets that expire within hours shrink it further.

Timeline

  1. 2015

    Square open-sources Keywhiz; HashiCorp announces Vault, both in April

  2. 2018

    AWS Secrets Manager launches in April with automatic rotation

  3. 2018

    GitHub starts scanning public repositories for leaked tokens

  4. 2021

    GitHub Actions OIDC lets CI deploy to clouds without stored keys

  5. 2026

    Vault 2.0 syncs secrets using workload identity, without static credentials

Sources15

Improve this page on GitHub