Cloud Security
Intermediate 16 min read Cloud Security

Secrets Management in the Cloud

Stop treating secrets as config and start treating them as identity: vaulting, rotation, short-lived credentials, and the pre-commit scan that catches them early.

secretsvaultrotationshort-lived credentialssecret scanninggitleaks
Introduction

What is this?

Secrets management is the discipline of storing credentials in a purpose-built service with access control, rotation, and audit — instead of in config, artifacts, and commit history.

Motivation

Why do you need it?

  • A leaked secret is the single most reusable attack primitive in the cloud: one key opens a sliding door.
  • Rotation turns a leak from 'game over' into 'contained while we rotate'.
  • Scanning for secrets pre-commit catches the leak before the word 'push' is even typed.
Think about it

Mental model

Imagine

A ring of keys in one drawer

Think of

A lock-smith who issues keys on demand and logs the copies

The drawer leaks once and everything is open; the locksmith revokes one key and life goes on.

Mechanics

How it works

  • A vault (e.g. cloud secret store / Vault / SOPS+age) keeps the value out of code: applications fetch at runtime.
  • Access control + audit bind every fetch to an identity; short-lived credentials render the secret near-useless if leaked.
  • Rotation can be automated: new key in vault, app fetches next, old key revoked after a grace period.
  • Commit scanning (gitleaks/trufflehog) blocks patterns and history-rescans to purge the past.

Fetch-on-demand, not bake-in-as-config

App
Vault
Secret
Use
Rotate
Real world

In production

  • A deployment pipeline fetches DB credentials from the vault seconds before use and never persists them to disk.
  • A secret-scanner blocks a committed AWS key and auto-forces rotation of the linked IAM user.
  • A platform rotates a TLS cert from the vault automatically, ending the 'expired cert at 2am' ticket tier.
Guidelines

Best practices

  • Move secrets out of config/env history into a vault with RBAC and audit.
  • Prefer short-lived/federated credentials wherever the platform allows.
  • Scan commits and PRs for secrets; treat a hit as an incident, not a lint error.
  • Rotate on a schedule AND immediately after any suspected leak — grace windows are exploitable.
Watch out

Common mistakes

  • Committing .env with a real key 'once' to fix a build; the police of history never forgets.
  • Exporting a secret to a CI log 'temporarily' and never rotating after the near-miss.
  • Using the vault but granting admin to everyone because setup was tedious.
  • Rotating the value but leaving the old one in a pinned artifact, still valid on the edge.
When things break

Debugging tips

  • When a rotated pipeline fails, check which vault path/version it fetched — stale refs, not the secret, are usually the culprit.
  • For a leaked-key investigation, list access history first: what could it touch in the exposure window.
  • Validate a rotation by attempting the old value after the grace window — it must fail.
Security

Security considerations

  • A secret surfaced in logs is an incident: rotate, revoke, scan the history, and inspect the blast radius.
  • Always prefer revoke-and-rotate over 'sanitize and continue' — the leaked copy still works.
Interviews

Interview checkpoint

Practice

Hands-on lab

Secret-Hunt Your Own History and Purge It
40 min · intermediate
In progress
Objectives
  • Scan a repo you own for secrets with gitleaks.
  • Simulate a leak and confirm the finding.
  • Plan the rotate/revoke response and rewrite history safely.

Secret-Hunt Your Own History and Purge It

40 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

The best response to finding a secret in a pushed commit is...

2

A short-lived credential is safer because...

Go deeper

Official documentation