Federate workload identity without static keys

Protection need

A workload in one platform needs limited access to a service in another identity domain. Copying a long-lived cloud key into an environment creates a portable secret with weak instance binding, difficult rotation, and broad replay value. The system needs a short-lived target credential based on current source-platform identity and explicit exchange policy.

Workload identity federation connects two authorities. The source issuer vouches for a workload under its namespace. A federation or security-token service validates that assertion and issues or enables a credential for the target authority. The target service validates the resulting credential and authorizes its own resource action.

Security objectives and requirements

• Begin with platform evidence or a short-lived source credential, not a copied target-cloud secret.
• Trust an exact source issuer and key set through bounded configuration.
• Match exact subject, audience, workload attributes, and source environment.
• Issue for one target audience, role, account, or resource with the smallest useful authority and lifetime.
• Preserve the workload and acting intermediary when both matter.
• Prevent one tenant, cluster, repository, namespace, or ServiceAccount from matching another's mapping.
• Record exchange policy, source identity, target identity, credential lifetime, and use without recording credentials.

Use immutable or controlled source claims. Treat repository names, branches, namespace labels, and external account identifiers as security inputs with lifecycle owners.

Security invariants and evidence

The target credential cannot be minted without a current valid source assertion. An assertion for another audience, issuer, subject, environment, or workload does not match. The exchange cannot grant more target authority than its policy defines. Static target keys are absent from workload storage and deployment configuration.

Evidence links the source attestation or token, federation rule version, mapped target principal, requested resource, issued lifetime, and target-service decision. Use hashes or identifiers, not full tokens.

Failure cases

• A wildcard subject rule lets any namespace or repository assume a privileged target role.
• The federation endpoint accepts a token intended for another audience.
• A shared source ServiceAccount makes unrelated workloads indistinguishable.
• Mutable claims such as a branch or label can be changed by an untrusted actor.
• The target role is broad, so a narrow source match still creates excessive authority.
• An intermediary exchanges on behalf of a workload but erases the actor.
• A source token and resulting target credential both outlive workload termination.
• Discovery or key retrieval accepts an attacker-controlled issuer.
• Federation outage triggers fallback to a long-lived emergency key that becomes permanent.

Build negative assertions for another tenant, cluster, namespace, ServiceAccount, repository, branch, audience, issuer, and expired workload. Each must fail at the federation boundary.

Design tradeoffs and residual risk

Federation removes long-lived target secrets and adds dependency on source identity, token exchange, clocks, and policy mapping. Short lifetimes reduce replay windows and increase issuance load. Rich claims improve precision and increase drift and administration risk.

Direct trust in a source issuer reduces components. A broker can normalize several issuers and becomes a high-authority deputy. Preserve source and actor context through the chain.

Residual risk includes compromised source issuers, malicious workloads that legitimately hold an identity, claim-administration compromise, cached credentials, and target roles that authorize too much. Federation changes credential delivery. It does not remove target authorization.

Pomerium boundary

Pomerium service accounts provide programmatic identity for documented Pomerium access. They are not automatically a cloud provider workload-federation credential. Operators can place Pomerium in an access path, but the source issuer, federation service, target cloud, and application each own their validation and authorization steps.

Exercise

Choose one workload that currently stores a target-cloud key. Draw the current key path and the proposed federation path. Record the source evidence, issuer, subject, audience, exchange endpoint, mapping rule, target principal, target resource, lifetime, refresh behavior, and evidence.

Remove the static key in staging. Test the valid workload plus another namespace, ServiceAccount, cluster, audience, issuer, and terminated Pod. Confirm that no failure path restores a long-lived target key.

Evaluation checklist

• Does federation begin from current platform identity instead of a stored target secret?
• Are issuer, subject, audience, environment, actor, and target resource exact?
• Can mapping changes and resulting credentials be traced to one policy version?
• Do target roles remain narrow after a correct source match?
• Is outage behavior safe and free of permanent static-key fallback?