Skip to content
←Security

// Security · 06

Secrets Management

Password in gitleads tofetch at startVault lookupleads toRotated, scoped secret

Secrets live in a vault or an identity, never in code, config or logs.

How it fits together

Secrets Management structureCommitted secretappsettings.jsonin git historySecret scannerblocks the pushOrders servicemanaged identityno password stored«external»Key vaultholds secret versionsOrders databaseshort-lived login1 identity auth2 connect3 rotate login4 push blocked
uses / callsreplicates / copiesfails / error path· numbered steps replay in order
  • Orders service uses / calls Key vault (1 identity auth)
  • Orders service uses / calls Orders database (2 connect)
  • Key vault replicates / copies Orders database (3 rotate login)
  • Secret scanner fails / error path Committed secret (4 push blocked)

Spot it

  • Password found in a git history search
  • Connection string committed to the repo
  • Same API key used since last year

It costs

One more moving part at startup, and a dependency on the vault being reachable.

Go deeperThe full explanation and what to ask for · 1 min readExpand

A secret is anything that grants access: passwords, API keys, connection strings with credentials, signing keys, certificates. The rule is that a secret lives in one place built for it (a vault or a secret manager), reaches the process at runtime, and is never written into source, configuration files, container images or logs. Once a secret is in git history, treat it as public: rotate it. Deleting the line is not enough.

The best secret is none. A managed or workload identity lets a service obtain tokens from the platform, so no password exists to leak. Where a secret must exist, rotate it on a schedule and on any suspicion, with an overlap window so the old and new values both work during the switch. Prefer short-lived, dynamically issued database credentials over one long-lived shared login.

Catch leaks before they land. Pre-commit hooks and server-side secret scanning match known patterns; they miss what they do not recognise, so do not rely on them alone. Keep secrets out of logs and error messages, and mask them in pipeline output. When NOT to bother: a throwaway local prototype can use an environment variable, as long as it is never committed.

Ask for it

  • secret store / vault
  • managed identity / workload identity
  • rotation and overlap window
  • secret scanning
  • dynamic credentials
  • pre-commit hook

Move the database password and payment API key from appsettings into the cloud key vault, read through the service managed identity. Rotate the payment key every 90 days with a 24h overlap. Add secret scanning to the pipeline and fail on any match. Revoke the leaked key, then scrub it from history.

Connects to