A training fleet on your own hardware reads platform-held data using one static key copied to every node; what changes when the platform instead trusts the fleet's identity provider?
answer
- the secret stops existing
- trust registered once, credential per call
- distribution problem becomes a trust registration
- identity is only as fine as the issuer
- the issuer becomes a runtime dependency
basics
~20 sEach node stops holding anything worth stealing. It asks its own issuer for a signed assertion and exchanges that for a short-lived platform credential per call, while the platform's trust sits on the issuer rather than on a secret you distributed.
solid answer
~40 sThree things move. **What each node holds** goes from a copy of one long-lived secret to nothing durable: it asks its own issuer for a signed assertion at call time and exchanges it for a short-lived credential. **What the platform holds** goes from a credential it issued and must keep valid to a registration saying which issuer it believes, how narrowly, and what a matching caller may do. **What you operate** goes from a distribution and rotation problem spread across every node to one registration plus an issuer that must stay reachable and honest. The failure modes swap too: you lose "one key in a hundred places, indistinguishable when misused", and you gain "if the issuer cannot sign, the fleet gets nothing" plus an escalation path through whoever can make that issuer sign.
go deeper
Know the headline: instead of copying one platform secret onto every machine, the machines prove who they are to their own identity provider and the platform hands out a short-lived credential each time.
Explain both sides of the exchange and be specific that the platform stores a registration rather than a key, so adding or removing a node needs no secret handling at all.
Name what you gained and what you took on: no durable secret to chase, but an issuer on the critical path and an administration that can now cause a signature your platform believes.
Frame it as moving a control point. The migration is only a win if adding a caller to the issuer is governed at least as tightly as issuing a platform credential was, otherwise you have made delegation easier and less visible.
## The shape of the problem you are leaving A fleet that runs on your own hardware and reads data the platform holds is the honest test case for federation, because the fleet is not on the platform at all. The default answer is a platform credential created once and copied to every node, usually through configuration management, sometimes by hand. It works, and it has three properties nobody chose: - **It exists in many places.** Every copy is a place it can leak from, and the count only grows. - **It is undifferentiated.** Every node presents the same thing, so misuse cannot be attributed to a node. - **It must be kept alive.** Somebody owns its expiry, its replacement and the coordinated restart that replacement implies. External identity trust attacks the first property directly, and the second only if you do the work. ## What the exchange replaces The fleet already has an identity of its own — an issuer inside your own environment that signs for the workloads running there. Federation lets you point the platform at that issuer instead of handing the fleet a platform secret. The platform registers which issuer it believes, a narrowing condition so a match is this fleet and not everything that issuer signs, and the platform identity a match receives. At run time a node gets a signed assertion from that issuer, presents it, and receives a short-lived credential minted for that exchange. | | Static key copied to every node | Trust registered in the fleet's issuer | |---|---|---| | On each node | A long-lived secret at rest | A signing relationship with its own issuer | | On the platform | A credential it issued and maintains | A registration naming an issuer and a grant | | Adding a node | Copy the secret again | Nothing — the issuer already signs for it | | Removing the fleet | Invalidate the value everywhere it went | Remove or tighten one registration | | New dependency | None | The issuer, on the path of every call | ## The three things that actually change 1. **The durable secret stops existing.** There is no value on a node for a compromised process, a stray log line or a copied disk image to reveal. This is the change people mean when they say federation is safer, and it is worth stating precisely: the risk did not become smaller, the object carrying it disappeared. 2. **Identity becomes as fine-grained as the issuer makes it.** Federation inherits whatever distinctions the issuer draws. If the issuer signs one identical assertion for every node, you have rebuilt the shared credential with extra machinery — no secret at rest, but still no way to tell nodes apart. If it signs per-node, the platform can see and scope per node. 3. **You trade a distribution problem for a dependency.** The issuer must be reachable and correct at the moment a node needs to act, and whoever administers it can now cause a signature that the platform believes. That is a real transfer of risk, not its elimination. ## What does not change A strong answer volunteers the limits: - **Permissions.** The grant attached to the identity a match receives decides what the fleet can read. Federation changes how a caller proves what it is; it decides nothing about what it may do, and a fleet federated onto an over-broad grant is exactly as dangerous as before. - **The data path.** Nothing about the trust arrangement changes routes, transfer charges or which network the bytes cross. - **Whether anyone is watching.** Proving identity per call produces a cleaner record, but somebody still has to look at it. ## Operating it afterwards The questions that matter after the migration are different from the ones before it. You no longer ask when the key was last replaced. You ask: - Who can add a caller to the issuer, and does that go through review? It is now equivalent to being handed the fleet's platform access. - What happens to the fleet when the issuer is unavailable — does it queue, degrade, or fail the run outright? Design that answer rather than discovering it. - Is the registration still as narrow as it was on the day it was written? Registrations broaden quietly, usually while someone is making a second consumer work. The move is worth making for most long-lived machine callers, and the honest summary is not "this is more secure" but "the thing you were protecting no longer exists, and in its place you have an issuer and a registration that now deserve the attention the key used to get".
- The fleet used one key for all nodes. Does federation give you per-node identity automatically?Only to the degree the issuer distinguishes them. Federation changes where identity comes from, not how fine-grained it is. An issuer that signs the same assertion for every node reproduces the shared credential with extra steps: nothing durable at rest, but the platform still cannot tell one node from another.
- What new failure domain does this create, and how do you design for it?The fleet's own issuer, which is now on the path of every call that needs platform access. Decide deliberately what a run does when signing is unavailable — queue and retry, proceed on work already fetched, or fail fast — and make the issuer's availability something the fleet's owners monitor rather than an assumption.
- Why register trust in the issuer rather than register each node's identity with the platform?Because the issuer is the part that stays constant while nodes are created, replaced and retired. Registering per node reintroduces exactly the per-caller maintenance federation removes, and it drifts the moment the fleet autoscales or a machine is rebuilt.
saying these in an interview costs you the question
- Says federation removes the need to authorize the fleet at all
- Thinks the static key is simply moved into a secret manager
- Claims the platform calls the outside issuer on every request
- Assumes federation works for nodes that cannot reach the issuer
- Believes an issuer is trustworthy because it sits inside your network
- Treats the issuer's availability as somebody else's problem