Skip to content

CONCEPT Cited by 1 source

OIDC federation for cloud access

OIDC federation for cloud access is the architectural pattern where a workload running in platform A (e.g. Fly.io, GitHub Actions, Kubernetes) obtains credentials to call a service in platform B (e.g. AWS, GCP, Azure) without sharing any long-lived secret between the two platforms. The mediating protocol is OpenID Connect (OIDC): platform A operates an OIDC identity provider (IdP) that signs short-lived JWTs asserting the workload's identity; platform B is configured once to trust that IdP (via an Identity Provider resource + a policy that constrains the acceptable audience + subject claims); at runtime, the workload presents its OIDC token to platform B's token-exchange API (AWS STS's AssumeRoleWithWebIdentity, GCP's Workload Identity Federation, etc.) and receives short-lived credentials of platform B's native shape.

What replaces what

Without OIDC federation:

  • Someone provisions a long-lived credential in platform B (an AWS IAM access key, a GCP service-account key JSON).
  • That credential is copied into platform A's secret store (fly secrets set, environment variables on the CI runner, a Kubernetes Secret).
  • The credential is read by the workload and used directly.

With OIDC federation:

  • Platform A's IdP is registered once in platform B as an Identity Provider.
  • A Role (AWS) / Service Account binding (GCP) is created in platform B with a trust policy that names the IdP and constrains who can assume it (via aud + sub claims).
  • The workload references only the Role / binding by identifier. The identifier isn't a secret — it can be emailed or Slacked.
  • At runtime, the workload calls its platform-A token endpoint to get an OIDC JWT, then presents it to platform B's token-exchange API.
  • Platform B vends short-lived native credentials.

The post's framing: "Here, we're not setting any secrets at all; we're just adding an ARN — which is not a credential — to the Machine. […] That's the 'secret credential': the pre-configured trust relationship in IAM, and the public keypairs it manages." (Source: sources/2024-06-19-flyio-aws-without-access-keys)

Why this is a structural improvement

  • No long-lived key ever exists. The mechanism doesn't store and rotate a long-lived key more carefully; it eliminates the long-lived key. See concepts/ephemeral-credentials.
  • The trust-policy constraints are declarative and auditable. "This is a rare instance where you can reasonably drive the entire AWS side of the process from within the web console. Your cloud team adds Roles all the time; this is just a Role with an extra snippet of JSON." (Source: sources/2024-06-19-flyio-aws-without-access-keys)
  • Scope is cryptographically enforced. Platform B rejects any OIDC token whose aud / sub doesn't match the trust policy. The workload's platform-attested identity is the pivot, not a trusted handoff.
  • Short-lived native credentials fall out naturally. "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."

Trust anchors

The trust graph is:

STS (verify-token) ── trusts ─▶ oidc.fly.io (sign-token)
oidc.fly.io        ── trusts ─▶ flyd (which Machine issued which request)
flyd               ── issues ─▶ Machine (Macaroon bound to that Machine)
Machine            ── proffers ─▶ OIDC token via STS.AssumeRoleWithWebIdentity
STS                ── returns ─▶ STS credential
Machine            ── uses   ─▶ STS cred to fetch from S3

The trust anchor shifts from "attacker eventually finds a key that wasn't rotated" to "attacker compromises the IdP." See why ephemeral credentials refocus trust rather than eliminate it.

Canonical instance

systems/oidc-fly-io + systems/aws-sts + systems/aws-iam as documented in sources/2024-06-19-flyio-aws-without-access-keys.

Pattern lineage

This concept is the architectural basis for patterns/oidc-role-assumption-for-cross-cloud-auth — the pattern page covers the operational shape (how to actually set this up step by step on AWS).

Sibling patterns on this wiki:

Seen in

  • sources/2024-06-19-flyio-aws-without-access-keys — canonical wiki source. Full token shape, trust-policy shape, twelve-step happy path, and the honest framing that "they asymptotically approach the security properties of Macaroon tokens" (i.e. better than long-lived keys, not equal to Macaroons).
Last updated · 200 distilled / 1,178 read