Skip to content

CONCEPT Cited by 1 source

Workload identity

Workload identity is the property that a process (a VM, a container, a function invocation, a Kubernetes Pod) has a platform-attested identity — not a credential it memorizes, but an identity that the underlying platform knows about it and can prove to third parties on demand. The identity is a fact about the workload (this Machine in this org running this image in this region), not a secret the workload holds.

Why this matters

The traditional alternative — ship a long-lived credential (AWS access keys, service-account JSON, a PAT) into every workload — has well-known failure modes: credentials leak, get forgotten, end up committed to repos, need to be rotated, accumulate across a fleet. Long-lived credentials are the "beginning of every horror story told about cloud security" (Source: sources/2024-06-19-flyio-aws-without-access-keys).

Workload identity inverts the problem. The platform knows which workload is calling; a third party can ask the platform to prove it. No secret in the workload means no secret to leak.

Shape on this wiki

Platform-issued, short-lived, signed

The platform operates an identity service (an OIDC IdP on Fly.io, GCP's Workload Identity, Kubernetes service-account token projection, SPIFFE/SPIRE) that signs short-lived JWTs asserting the workload's identity. Fly.io's oidc.fly.io is the canonical wiki instance.

Claims encode the identity hierarchy

Fly.io's sub is <org>:<app>:<machine> — the identity is not a single opaque string but a structured tuple that third-party trust policies can scope along any prefix. See patterns/sub-field-scoping-for-role-trust.

Workload can't forge or leak the identity

The identity token is minted by the platform control plane (flyd on Fly.io), bound to the requesting machine via a Machine-scoped Macaroon the guest code never sees. The proxy on /.fly/api is the guest's only interface; it attaches the Macaroon on outbound requests and doesn't expose it on inbound ones. See concepts/machine-metadata-service and concepts/unix-socket-api-proxy.

Third parties trust the platform IdP, not the workload

Cloud trust policies (AWS IAM AssumeRoleWithWebIdentity, GCP Workload Identity Federation, Azure workload-identity federation) name the platform's IdP as the Federated principal. The cryptographic trust is between platform A and platform B — the workload is just the carrier of a token signed by A.

Observable consequence: identifiers aren't secrets

"The resulting ARN isn't even a secret; your cloud team could just email or Slack message it back to you." (Source: sources/2024-06-19-flyio-aws-without-access-keys) Because the security is in the trust relationship (not the knowledge of the ARN), the ARN can be shared openly — a quality-of-life improvement for ops hand-offs that access-keys-in-secret-stores simply doesn't allow.

Comparison with adjacent concepts

  • concepts/ephemeral-credentials — the credential output of workload-identity federation (the STS token returned by AssumeRoleWithWebIdentity) is an ephemeral credential, but workload identity also covers the identity layer that mints the ephemeral credential. Ephemeral credentials can also be user-facing (OPKSSH-style SSO-issued SSH keys) — workload identity specifically is for non-human identities.
  • concepts/machine-metadata-service — the delivery mechanism for workload identity inside a Machine. EC2 IMDS, Fly's /.fly/api Unix socket, and GCP metadata server are all workload-identity-service surfaces.
  • SPIFFE / SPIRE — the open-standard sibling not yet covered on this wiki; SPIFFE IDs (spiffe://trust-domain/path) are the same shape as Fly's sub — a structured per-workload identifier the platform can prove.

Canonical wiki instance

sources/2024-06-19-flyio-aws-without-access-keys — Fly Machines as the workload, systems/oidc-fly-io as the platform's identity service, AWS IAM + STS as the counterparty that trusts the identity.

Seen in

  • sources/2024-06-19-flyio-aws-without-access-keys — "we're not setting any secrets at all; we're just adding an ARN — which is not a credential — to the Machine"; the sub claim as <org>:<app>:<machine>; isolated-hardware-managed signing key; trust policy names Fly's IdP as Federated.
Last updated · 200 distilled / 1,178 read