Skip to content
Case Files
CLASSIFIED2026.03.27·1 MIN READ

Secrets That Never Touch Disk

A way to hand credentials to workloads without a single secret ever landing in a file, an env dump, or a git history.

  • #security
  • #vault
  • #secrets

The safest secret is the one that was never sitting there to begin with. Not encrypted at rest. Absent at rest. If it never gets written to disk, it can’t leak from disk.

How it works

The workload proves who it is using an identity it already has, like a Kubernetes service-account token or a cloud instance role. It trades that identity for a short-lived credential, in memory, right when it needs it.

The pod starts with no secrets at all, just its service-account token. It calls the secrets broker and proves who it is. The broker hands back a credential with a short TTL over TLS. The credential lives in memory, gets used, and expires before anyone could realistically copy it out.

# Vault kubernetes auth: the workload proves identity, gets a lease
path "database/creds/api-readonly" {
  capabilities = ["read"]
}

The TTL is the whole point

A leaked static credential is good until someone notices and rotates it, which in practice is often months. A leaked 15-minute credential is good for 15 minutes. Same leak, completely different outcome. One is a breach, the other is a shrug.

That’s really the trick here. You stop treating rotation as a chore you have to remember to do and make it something that happens whether you’re paying attention or not. Doing nothing becomes the safe option.

Most secret leaks aren’t clever. They’re a .env file that got committed, or a credential that ended up printed in a log line. This approach works because it deletes the file and the log line from the story entirely. There’s nothing to commit and nothing to print.


Back to Case Files