Reference architecture for workload identity

The target state

Three facts, separable, at every call. The workload's own identity, attested from its runtime. The authority it carries, which for an agent means a delegated human principal held in a separate token. And a decision evaluated at the point of use rather than baked into issuance.

Everything below is a way of getting the first fact right on a specific platform. The second and third are covered in delegation chains and the authorization and signals layer.

What each runtime gives you

The pattern is identical across all six. Something the workload cannot forge vouches for it, and a credential is minted for a bounded period against that proof.

Where the seams are

• Crossing clouds. A workload in one provider authenticating to another. Federation works, and the trust configuration is where mistakes concentrate. Pin the issuer, the subject and the audience, and review those conditions as you would review a firewall rule.
• Crossing organisations. Federate trust domains rather than sharing credentials. This is the SPIFFE model and the direction the WIMSE drafts formalise.
• Appliances and embedded devices. No attestation mechanism and often no way to rotate. Front them with a terminating proxy that holds the modern credential, or register a documented exception with an owner and a review date.
• Datastores. Most accept only a username and password. A secrets engine issuing per-use credentials converts that into a dynamic pattern without changing the database.
• Vendor software. If it only accepts a static API key, that key is a registered exception. Scope it as tightly as the vendor permits and monitor it as a known weak point.

Migration order

1. CI/CD. Highest credential concentration, best native support, least coupled to production availability. Removing long-lived cloud keys from repository secrets is the single largest reduction in exposure available to most organisations. See CI/CD credentials.
2. Kubernetes workloads. Projected tokens plus cloud federation. Largely configuration.
3. Cloud compute. Instance and managed identities in place of keys.
4. Datastore access. Dynamic credential issuance.
5. SaaS integrations. Hardest, because the credential lives at the other party. Scope reduction and review cadence rather than replacement.
6. On-premise and legacy. SPIFFE where attestation is possible, documented exceptions where it is not.

Do not attempt these in parallel. Each stage teaches you which consumers cannot automate, and that list is the input to the next stage.

Four anti-patterns

1. A vault as the destination. Moving static secrets into a store is progress and not the target. If the vault hands out the same long-lived value, you have centralised the problem rather than solved it. Dynamic issuance is the target.
2. One role for everything. A single broadly-scoped role assumed by every workload defeats the model. Attestation tells you which workload is calling, and that information is wasted if they all get the same authority.
3. Loose trust conditions. A federation trust policy that matches any subject from an issuer is equivalent to a shared credential, and it looks modern in an architecture diagram.
4. Migrating without deleting. The old key still works. Migration is not complete until the previous credential is revoked and confirmed dead, and this is the step most often skipped.

Frequently asked questions

What is the target architecture for workload identity?

No static long-lived secrets. Every workload proves what it is to its runtime through attestation, and receives a short-lived credential on that basis. All three major clouds, Kubernetes and the common CI/CD systems support this natively today, so most of the work is configuration of infrastructure you already own rather than new tooling.

Where should a workload identity migration start?

CI/CD. It has the highest credential concentration, the best native support through OIDC token exchange, and the least coupling to production availability. Removing long-lived cloud access keys from repository secrets is usually the single largest reduction in exposure available, and it teaches you which consumers cannot automate before you touch production.

Do you still need SPIFFE if you use cloud-native workload identity?

Not for workloads inside a single cloud, where the native mechanism is sufficient. SPIFFE earns its place at the seams: on-premise and mixed estates, workloads crossing organisational boundaries, and anywhere you need one identity model spanning runtimes that each have their own. Attestation quality is the control, so weak node attestation makes strong workload identity meaningless.

What is the most common mistake when adopting workload identity?

Migrating without deleting. The new credential path works, the old key still exists, and nobody revokes it. Migration is not complete until the previous credential is revoked and confirmed dead. Close behind it is a federation trust policy loose enough to match any subject from an issuer, which is equivalent to a shared credential while looking modern in a diagram.

How do you handle systems that cannot support attested identity?

Three options in order of preference: front the system with a terminating proxy that holds the modern credential, use a secrets engine to issue per-use dynamic credentials where the system accepts a username and password, or register a documented exception with a named approver, a compensating control and an expiry. Appliances, embedded devices and vendor software with fixed API key authentication usually end in the third category.