skip to content

A broker accepts clients that present no secret because the platform they run on vouches for them — what is actually being trusted?

level: seniorimportance: should knowfreq 45%

answer

  1. the platform vouches, not the client
  2. signer, validity window, intended audience
  3. no secret to distribute
  4. identifies where it runs, not what runs
  5. verification material is now a dependency

basics

~20 s

The broker trusts the platform's signer, not the client. It checks a short-lived signed statement about the workload — who signed it, that it is current, that it names this cluster — and derives the principal from it.

solid answer

~50 s

With **delegated platform identity** the client presents nothing it was given. The platform it runs on produces a short-lived signed statement about the workload, and the broker checks three things: that the signer is one in its **trust set**, that the statement is current, and that it was meant for this cluster rather than some other audience. From that it derives the principal the broker sees. What this removes is the whole distribution problem — no secret to bake into an image, drop in a repository, or hand to a new client. What it does not remove is the coarseness of the identity: whatever runs under that platform identity is that principal, so a sidecar process or anyone able to start a workload under it is indistinguishable from the real application. It also adds an availability dependency, because the broker must be able to obtain and refresh the material that verifies those signatures.

go deeper

for a junior

Know the shape: the client stores no secret, the platform it runs on signs a short-lived statement about it, and the broker trusts the signer rather than the client.

for a middle

Say what the broker checks before it believes the statement — the signer, that it is current, that it was meant for this cluster — and where the principal's name comes from.

for a senior

Name the trade: the distribution problem disappears, but identity is only as fine as the platform's, the clock tolerance is replay room, and the broker fails closed if it cannot verify signatures.

for a principal

Treat it as moving the control surface: the estate's real question becomes who may deploy under which platform identity, and which client populations have no platform to vouch for them at all.

## What the broker is verifying Nothing about **delegated platform identity** removes the need for proof; it moves who produces it. The client asks the platform it runs on for a short-lived signed statement about itself and presents that at connect. The broker then checks, at minimum: - **Who signed it.** The signer must be one the cluster's **trust set** names. A valid signature from an unexpected signer is the whole attack. - **Whether it is current.** The statement carries a short validity window, and the broker accepts it only inside that window — with some tolerance for the two sides' clocks disagreeing. - **Who it was meant for.** A statement addressed to one audience should not be accepted by another, or a workload's proof to some unrelated service becomes proof to the cluster. - **What it names.** The principal the broker sees is derived from the statement's subject, and grant rules are written against that derived name. ## What it genuinely buys | Problem with a distributed secret | What platform identity does to it | |---|---| | Getting the first credential onto a new client | Removed: nothing is handed over, the workload asks where it runs | | Secrets in images, repositories and process environments | Removed: there is nothing durable to leave behind | | A secret that is valid until someone notices | Reduced: the statement is short-lived by construction | | Cleaning up after a client is decommissioned | Reduced: identity is tied to the workload, not to a stored artefact | That is a large gain, and on an estate of hundreds of clients it is often the decisive one: the mechanisms that require distribution are the ones that scale worst. ## What it does not prove, and the new dependencies 1. **It identifies where the code runs, not which code runs.** The statement says a workload with this platform identity is asking. Any process able to reach the platform's identity path under that workload gets the same statement — a companion process in the same unit, a debugging shell, a library pulled into the same application. The identity is as fine-grained as the platform's own unit of identity and no finer. 2. **Anyone who can start a workload under that identity is that principal.** This moves the security question up a level: the control that matters becomes who may deploy under which platform identity, which is a property of the platform and not of the broker. 3. **A tolerance window is an attack window.** Accepting statements a little outside their stated validity to survive clock disagreement gives a captured statement that much more usable life. Wide tolerance is a quiet decision to accept replay. 4. **The broker gains an availability dependency.** It must be able to obtain and refresh the material that verifies these signatures. If that path fails, the broker does not fail over to accepting everything — it fails closed, and no client can connect, including the ones that were going to fix it. 5. **It does not cover everything that connects.** Clients outside the platform — another platform's workloads, on-premises jobs, operational tools, engineers — have no platform to vouch for them. A cluster that offers this mechanism almost always still accepts another one for them, and that second mechanism is the estate's real floor. What varies: some brokers offer this only for clients on the same platform as the cluster; a **managed tier** may offer it as the primary mechanism and something else only grudgingly; others accept statements from an external signer and treat the platform as just another issuer. Do not assume the shape you have used is the general one. ## How to reason about it in an interview Start with what is checked — signer, currency, intended audience, derived name. Then state the trade plainly: you have exchanged a distribution problem for a delegation problem. Nothing is stored, nothing leaks from an image, and nothing needs handing to a new client; in return, the broker's notion of identity is only as precise as the platform's, the interesting control has moved to who can deploy under that identity, and the cluster cannot authenticate anybody at all if it cannot verify signatures. That is usually a good trade, and saying *why* it is a trade rather than a free win is what distinguishes the answer.

  • Why does the broker check who a platform-signed statement was meant for, and not just the signature?
    Because a signature only shows the signer produced the statement. Without an intended audience, a statement the workload legitimately obtained to prove itself to some unrelated service could be replayed at the broker. Binding the statement to this cluster means proof obtained for one purpose does not silently work as proof for another.
  • What happens to client connections if the broker cannot verify the platform's signatures any more?
    New connections fail. Verification failing closed is the correct behaviour — the alternative is accepting unverified proof — but it means the cluster has a new dependency whose outage looks like a total authentication outage. Existing long-lived connections may survive on designs that fix identity at connect, which can mask the problem until something reconnects.
  • How do you keep the principal from becoming too coarse under this mechanism?
    Give each application its own platform identity rather than sharing one across a machine or a team, and keep the deployment path that can run workloads under an identity as tightly held as a secret would have been. If the platform's unit of identity is coarser than your applications, the broker cannot tell them apart no matter how the grant rules are written.

A letter of introduction from the landlord rather than a key of your own. The porter checks the landlord's seal and the date — but the letter says which flat you came from, not which person you are.

saying these in an interview costs you the question

  • Calls it authentication without any credential at all
  • Says it proves which application code is running
  • Ignores who is allowed to deploy under that platform identity
  • Skips checking the intended audience of the signed statement
  • Widens the clock tolerance without noticing it extends replay
  • Assumes clients outside the platform can use it too