Skip to content

CONCEPT Cited by 2 sources

Ephemeral credentials

Ephemeral credentials are credentials — keys, tokens, certificates, or passwords — that are generated on demand, used for a short lifetime, and discarded. The security property is that at any point in time, the set of valid credentials is structurally small: old credentials self-expire, so the attack window for a compromised credential is bounded.

Contrasts with long-lived credentials — SSH keys in ~/.ssh/id_rsa, AWS IAM access keys, personal access tokens — which tend to accumulate, get forgotten, and grant indefinite access unless someone notices and rotates them.

The accumulation problem

Tatu Ylonen (SSH's inventor), cited in the OPKSSH announcement:

"In many organizations – even very security-conscious organizations – there are many times more obsolete authorized keys than they have employees. Worse, authorized keys generally grant command-line shell access, which in itself is often considered privileged. We have found that in many organizations about 10% of the authorized keys grant root or administrator access. SSH keys never expire."

Ephemeral credentials resolve this by construction: if the key lifetime is 24 hours, there is no accumulation. Obsolete keys physically cannot exist long enough to pile up.

Shapes on this wiki

  • sso-with-ephemeral-ssh-keys — OPKSSH's shape: user signs in via OIDC, gets a 24-hour SSH keypair, re-signs in tomorrow to get a new one.
  • per-boot-ephemeral-key — compute-side: each VM boot generates a fresh key in memory, key dies with the VM. Terminating the VM cryptographically shreds its local state.
  • AWS STS short-lived tokens — centralized-identity-federation: every federated assume-role call yields a fresh STS token with an hours-scale lifetime.

Why ephemeral credentials don't eliminate trust — they refocus

it

The long-lived-credential threat is "an attacker eventually finds a key that wasn't rotated." The ephemeral-credential threat is "an attacker compromises the mint." What shifts is not the existence of a trust anchor but its nature — instead of trusting a static keystore, you trust the identity provider (or the KMS, or the CA) that issues credentials on demand. The compromise surface is smaller (one mint vs. N scattered keys) and more concentrated (rotation, revocation, and audit all go through one point).

Tradeoffs

  • Online dependency. Every credential use may require (or at least recently required) contact with the mint. SSH with ephemeral keys still works offline once the key is minted, but re-minting is online. Per-boot keys need a trusted entropy source. STS tokens need network reachability to STS.
  • Log volume. The mint now logs every credential issuance, which is more records but more useful records (every issuance is a real authentication event, not a months-old provisioning).
  • Clock sync. Short expirations amplify the impact of clock skew. Most systems tolerate minutes of skew; hours-scale credentials don't care, but sub-minute credentials do.

Seen in

  • concepts/least-privileged-access — ephemeral credentials are the temporal axis of least privilege.
  • cryptographic-shredding — in-memory-only keys (per-boot pattern) give free data shredding at teardown.
  • concepts/short-lived-credential-auth — the cloud-API- oriented sibling concept; STS credentials are the canonical short-lived-credential output.
  • concepts/workload-identity, concepts/sso-authentication — the identity-layer and protocol-layer concepts that drive ephemeral-credential issuance for workloads.
  • per-boot-ephemeral-key — compute instantiation.
  • sso-with-ephemeral-ssh-keys — SSH instantiation.
  • oidc-role-assumption-for-cross-cloud-auth — cross-cloud-workload instantiation.
  • centralized-identity-federation — AWS-STS-based instantiation.

Merged aliases

  • ephemeral-credential-injection
Last updated · 766 distilled / 2,225 read