Skip to content

CONCEPT Cited by 1 source

Short-lived credential auth

Short-lived credential auth is the security property that a workload's authorization is carried by credentials with minutes- scale lifetime, generated dynamically per session, never stored in configuration or environment variables, and self-rotating. Compromising one credential yields a time-bounded window during which an attacker can act; the window closes automatically without human or automated action.

Canonical quote:

AWS STS credentials are short-lived. Because they're generated dynamically, rather than stored in a configuration file or environment variable, they're already a little bit annoying for an attacker to recover. But they're also dead in minutes. They have a sharply limited blast radius. They rotate themselves, and fail closed. (Source: sources/2024-06-19-flyio-aws-without-access-keys)

The four properties

  1. Dynamic generation. Credentials are minted per session by a token-exchange service (AWS STS, GCP Workload Identity Federation, etc.) rather than written to disk or environment variables at provisioning time.
  2. Short lifetime. Minutes-scale by default (AWS STS default 1 hour, DurationSeconds minimum 15 minutes). Compromise window is bounded by the lifetime.
  3. Self-rotating. The SDK or credential broker re-invokes the mint when approaching expiry; no operator intervention required.
  4. Fail closed. If the mint is unreachable, new requests fail rather than falling back to a cached long-lived credential. The system refuses to do unauthenticated work.

Why this is structurally different from "rotate keys often"

Rotation discipline on long-lived keys is a process property: someone has to remember, someone has to update the secret store, someone has to catch the keys that never got rotated. The failure mode is the old key that never expired.

Short-lived credential auth makes the failure mode impossible by construction: there is no long-lived credential to forget. The credential cannot be older than its lifetime, because it is issued against the current moment.

Blast radius

Short-lived credential auth is a direct blast-radius control. A compromised STS credential can only be used for (say) 15 minutes, and only within the scope of the Role it represents. The same compromise on a long-lived AWS access key grants the attacker open-ended access until the key is rotated — which, if the compromise wasn't detected, means indefinitely.

What stays long-lived

The trust relationship in the cloud provider (IAM Identity Provider + Role + trust policy) is long-lived. The IdP's signing keys are long-lived (rotated out-of-band by the platform). The workload's credentials are short-lived.

This is the same shift as TLS certificates vs session keys: long- lived signing certificates authenticate a one-off short-lived key exchange.

Canonical instance

sources/2024-06-19-flyio-aws-without-access-keys — Fly Machines → OIDC token → AssumeRoleWithWebIdentity → STS credential. The STS credential is the short-lived credential; the OIDC IdP trust + IAM Role are the long-lived substrate.

Contrast: long-lived cloud access keys

Fly.io's opening pitch for why short-lived credential auth matters:

You could ask your security team to create a user, give it permissions, and hand over the AWS keypair. Then you could wash your neck and wait for the blade. Passing around AWS keypairs is the beginning of every horror story told about cloud security, and security team ain't having it. (Source: sources/2024-06-19-flyio-aws-without-access-keys)

The horror stories are pretty consistent in their shape: key committed to a public repo, key logged into an error tracker, key in an environment-variable dump, key that no one knew who owned. All of those vanish as a category when there's no long-lived key to leak.

Relationship to other concepts

Seen in

Last updated · 200 distilled / 1,178 read