Key Takeaways: Secrets and Machine Identity

A one-page reference. Reread this before an exam or before moving on. Dense by design.

The core vocabulary (memorize cold)

The thesis: a secret is an identity. Machine identities outnumber humans ~10–50×, usually have no second factor, no lifecycle, and no owner. The best fix for a secret is to eliminate it (workload identity), not "store it better."

Human vs. machine identity (why machines are harder)

The secret-management hierarchy (reach for the top)

BEST   1. Eliminate the secret   → workload identity / IAM role (no key exists)
       2. Dynamic secret         → vault issues short-lived, scoped, auto-revoked
       3. Vaulted static secret  → centralized, scoped, audited, rotated
WORST  4. Hard-coded in code     → sprawl + leak + breach

• Vault, don't scatter. Workload fetches at runtime; one place to rotate; every access logged (HSM-backed master key, from Ch.5).
• Dynamic > static: static stolen → valid for years; dynamic stolen → valid for minutes. Converts a prevention problem you lose into a time-window problem you win.
• Env vars ≠ a vault (leak into logs/child procs; no audit/rotation/expiry). A step, not a destination.

Service accounts — the five classic failures and their fixes

Certificate lifecycle (logistics, not math)

ENROLL → ISSUE → DEPLOY → MONITOR → RENEW   (and REVOKE if compromised)

• Expired-cert outage = the most preventable catastrophic failure (the date is knowable). Prevent with: discovery + daily expiry monitoring (cert_days_left) + automated renewal (ACME).
• Spreadsheet-by-one-person = anti-pattern (outage scheduled for their vacation).
• Short-lived certs force automation (manual renewal impossible) and make unreliable revocation (CRL/OCSP fail open) nearly irrelevant — a short cert revokes itself by expiring.
• Abuse: stolen private key (→ HSM + short life), rogue/mis-issued cert (→ Certificate Transparency monitoring), expiry-as-self-DoS (→ monitoring/auto-renew).

Secret scanning — find leaks, then ROTATE

Common patterns: AKIA+16 upper = AWS key; ghp_+36 = GitHub PAT; AIza+35 = Google; xox[bp]-… = Slack; -----BEGIN … PRIVATE KEY----- = private key.

Three placements: pre-commit (best, but bypassable) → pipeline/CI (enforceable, Ch.31) → history + runtime/logs (catches old + printed secrets).

THE ONE RULE: when a secret leaks, ROTATE it. Deleting the commit does nothing — the secret is in git history, clones, CI caches, and likely already scraped (public-repo secrets abused in minutes). Rotation is the only response; everything else is theater.

Detect use of misused secrets (machine behavior is boring): service account logging in interactively · workload active from new network/geo/time · spike in vault requests or a never-fetched secret requested · access key used from many IPs · first use of a dormant credential. → SIEM use cases in Ch.21.

Certification crosswalk

Project additions this chapter

• Meridian program: secrets-management standard (9 rules: no hard-coded secrets, vault everything, prefer no static secret, least privilege for machines, automated rotation, own every identity, no interactive service logon, manage certificates, scan for leaks) + machine-identity discovery results.
• bluekit toolkit: secrets.py — scan_secrets(text) (regex leak finder), cert_days_left(not_after) (expiry flag). scan_secrets is lifted into a CI gate in Ch.31.

Common pitfalls

• Hardening human auth (Ch.16–19) while leaving machine identity as a sprawl of hard-coded keys.
• "We use environment variables" mistaken for "we have secrets management."
• Deleting/force-pushing a leaked secret instead of rotating it.
• Over-privileging a service account or CI job — a small leak becomes a large breach (blast radius).
• Tracking certificate expiry in a one-person spreadsheet.
• Treating the CI pipeline as a trusted black box rather than a monitored production system holding a skeleton-key bundle of secrets.
• Forgetting that revocation often fails open — short-lived certs/credentials are the robust answer.