Linking

Workload Identity Federation

One logical service usually runs under several workload identities at once — one per cloud, per cluster, per environment. Federation records that they belong to the same enduring service, and does nothing else.

What it does

It records that these are the same service

The relationship between a public identity and the internal identities a service runs under is, today, held in somebody's head or in a naming convention.

One service, several runtimes
A workload identity in each cloud, a service account in each cluster, a SPIFFE identity per environment — declared as bindings against one ECZ-ID.
Continuity across a migration
Moving a service between providers changes which bindings are active. It does not change the identity, and a counterparty sees continuity rather than a disappearance.
A readable answer outside the boundary
A counterparty with no access to any of your infrastructure can still reach one record that names the service and the organisation operating it.
A declared pipeline
Where a CI provider's OIDC identity publishes or deploys the service, that can be bound too — as a declaration, recorded with when it was learned.

The objection, answered directly

It takes no control of anything

A binding shows that a relationship has been declared. It does not grant, prove or imply authority to act.

It never replaces or controls your cloud IAM, SPIFFE identities or service accounts. Those stay exactly where they are, governed exactly as they are.
Nothing is issued. No credential, no certificate, no token and no trust relationship is created in your cloud by recording a binding.
It is not in the execution path. No workload calls this to start, to scale or to serve a request, and an outage here does not reach your service.
It grants no access. A binding is a declaration that a relationship exists, not a permission to do anything.
No cloud account identifier is published. The binding records a relationship, not a copy of your configuration.

Optional