Positioning
Beside your workload identity, never instead of it
If you run production workloads you already have workload identity, and it works. This page is about what an ECZ-ID adds beside it, and about the fact that it takes nothing away.
The short answer
It replaces none of them
Cloud-native IAM answers an internal question: may this running thing do that, right now, inside this boundary. It answers it with short-lived credentials, scoped to a tenant, a project or an account, and it is designed so that nobody outside can read it.
That design is correct and this does not touch it. What it leaves open is the other question: who, outside the boundary, is the enduring thing on the other end, and which organisation answers for it. A counterparty with no access to your tenant cannot read a service account, and should not be given one.
An ECZ-ID adds provider-neutral identity, operator, relationship and proof semantics around what you already run. It is not in the execution path, it is not a credential, and nothing authenticates with it.
Named, one by one
What each already does, and what sits beside it
SPIFFE and SPIRE
- What it does
- Issue short-lived workload identities inside your infrastructure.
- What an ECZ-ID adds
- A stable public identifier for the enduring service, rather than a rotating internal one for a running process.
Kubernetes service accounts
- What it does
- Identify pods to the cluster and to other workloads in it.
- What an ECZ-ID adds
- One identity for the logical workload that stays the same while pods, replicas and clusters change.
Microsoft Entra Agent ID and workload identities
- What it does
- Govern what an agent or workload may do inside your Microsoft tenant.
- What an ECZ-ID adds
- An identity that resolves outside the tenant, for parties with no access to it.
AWS IAM
- What it does
- Governs what a role or workload may call inside your AWS accounts.
- What an ECZ-ID adds
- A public identity a counterparty can read without any access to your accounts.
Google Cloud IAM and workload identity federation
- What it does
- Govern access to your Google Cloud projects.
- What an ECZ-ID adds
- A public identity readable outside your projects, naming the organisation that operates the subject.
OAuth 2.x and OpenID Connect
- What it does
- Delegate authorisation and authenticate a principal for a session.
- What an ECZ-ID adds
- A durable public record of the subject and its operator that outlives any token and needs none to read.
The subject
The enduring service, not the thing currently running
What is never a separate identity
Pods, replicas, regions, environments and deployments of that workload are not separate Passports. A rotating SPIFFE identity, a Kubernetes service account and a short-lived cloud credential are all bindings or nothing at all — never the subject.
Why that is the useful unit
The thing a counterparty depends on is the service, not the process serving it this afternoon. An identity pinned to the process would be correct and useless; one pinned to the service outlives every deployment of it.
What the record does not contain
No cloud account identifier is published
No account number, no subscription or project identifier, no tenant identifier, no cluster name, no internal hostname and no credential of any kind appears in a public record. Where a cloud workload identity is bound, the binding is recorded as a relationship; it is not a copy of your configuration.
A binding is a declaration, recorded with when it was learned. It does not grant access, it does not prove control of anything, and it confers no authority.
How a logical service is linked to the identities it runs under