skip to content

A single helper on a host fetches credentials for every workload on it — which identity does the store see?

level: middleimportance: should knowfreq 48%

answer

  1. the store sees the caller, not the requester
  2. one helper, one grant for everyone
  3. the union of every workload's names
  4. the local interface is the real boundary
  5. per-workload identity narrows grant and attribution

basics

~10 s

The store authenticates the fetcher, not the workload that wanted the value, so a host-wide helper appears as one machine-shaped identity whose grant must cover every workload on that machine.

solid answer

~50 s

A store decides what to release from the identity of the caller in front of it. When one helper serves the whole machine, that caller is the helper, so its grant has to be the **union** of what every workload on the host needs. Two consequences follow. Anyone who can reach the helper's local interface can ask for anything inside that union, unless the helper distinguishes its local callers and requests only their names — and the store can scope the release to match. And the store's access records attribute every read to the machine, so an unexpected read cannot be narrowed past it without the helper's own logs. A companion deployed per workload tightens both: one workload's names, attributable to one workload. What either of them presents to be accepted is a separate subject.

go deeper

for a junior

Recall that a store answers whoever is calling it. If one shared helper does all the fetching on a machine, the store knows only that the helper asked.

for a middle

Explain why a shared fetcher's grant has to be the union of the workloads it serves, and what that union means for anything able to reach its local interface. Say what a per-workload fetcher narrows.

for a senior

Show you would check the grant, not the diagram: what names the fetcher can read, who can make it fetch, and whether an unexpected read could be narrowed past the machine.

for a principal

Frame identity granularity as the estate-level input it is. If the platform cannot distinguish workloads, no placement of the fetcher fixes scope, and that becomes the prerequisite piece of work.

## The store sees the caller, not the requester Every secret store works the same way at this point: it authenticates whatever is at the other end of the connection, looks up what that identity is allowed to read, and answers. It has no view of why the request was made or on whose behalf. So the identity that matters is the **fetcher's**, and the identity granularity of your estate is decided by where you put the fetcher. That is easy to state and easy to get backwards. A common wrong answer is that a shared helper somehow passes the workload's identity through, and the store enforces the workload's own entitlement. Unless the design explicitly forwards an identity and the store is built to accept it, that is not what happens: one process called, one identity was authenticated, one grant applied. ## Why one helper means one grant Put twenty workloads on a machine with one helper serving them all: - The helper needs to be able to read the names all twenty need. That is one grant covering twenty workloads' worth of names. - That union is the **ceiling** on what the helper can obtain, and therefore on what anything that can make the helper fetch can obtain. - New workloads land on the machine over time. The pressure is always to widen the grant so that a new deployment just works, and a grant widened that way is rarely narrowed later. - The helper usually exposes a local interface on the machine so workloads can ask it for their values. Reaching that interface is a local matter, and being able to name a process is not the same as authenticating it. None of that makes the host helper wrong. It makes the helper's grant the number you have to be able to state. ## What per-workload fetching narrows | | Host-wide helper | Companion per workload | Service fetching for itself | |---|---|---|---| | Identity the store authenticates | the machine | that workload | that workload | | What the grant must cover | every workload on that host | one workload's names | one service's names | | Who can make it fetch | anything reaching its local interface | that workload | code running in that process | | A read is attributed to | the machine | one workload | one service | | One compromise reaches | the union | one workload's names | one service's names | The column that changes is not secrecy — it is **scope and attribution**. Both improve when the identity is closer to the thing that needed the value, and both depend on the platform being able to tell one workload from another in the first place. Where it cannot, a companion per workload is deployment hygiene rather than a security control, because the store still sees the same identity for all of them. ## The local interface is the boundary you actually have With a shared fetcher, the store-side control is the grant, and the host-side control is whatever guards the interface the helper exposes. It is worth saying out loud what that guard usually is: reachability. If the design intends the helper to serve only some callers, that has to be enforced — by the helper distinguishing callers and asking only for their names, by the interface being restricted to specific callers, or by both. Otherwise the helper is an open door to the union, sitting on the same machine as everything you were trying to separate. ## Two things this question is not 1. **Not how a fetcher proves who it is.** Whatever a helper, companion or service presents to be accepted — and what the store hands back once it is — is a separate subject with its own mechanics. 2. **Not how the grant itself is written.** How rules are expressed over names, and how narrow they should be, is policy design. Here the only point is that the grant attaches to the **authenticated fetcher**, so moving the fetcher moves the grant. ## What a strong answer sounds like "The store sees the helper. So the helper's grant is the union of everything the workloads on that box need, and that union is what anyone who can make it fetch can get. If I want per-workload scope I have to move the fetch next to the workload and have the platform give each workload its own identity — and if it cannot, moving the fetcher buys me nothing at the store." That answer names the mechanism, names the ceiling and names the precondition, which is what the question is for.

  • What must a host-wide helper do to avoid holding the union of every workload's grant?
    It has to distinguish its local callers and request only that caller's names, and the store has to be able to scope the release accordingly. Without both halves the helper's own grant stays the ceiling, and every workload on that machine sits inside it.
  • What does per-workload fetching buy in the store's access records?
    Attribution. A read arrives under one workload's identity, so an unexpected name, hour or volume points at one deployment rather than at a machine hosting twenty. With a shared fetcher every read looks alike, and narrowing it means correlating against the helper's own logs, if it keeps any.
  • If the platform cannot give each workload a distinct identity, is a companion still worth deploying?
    Operationally sometimes, as a way to keep the store client out of application code. At the store it buys nothing: the same identity is authenticated for every companion, so grants cannot be narrowed and reads cannot be attributed. Fixing the identity comes first.

saying these in an interview costs you the question

  • Assumes the store can tell which workload asked the shared helper
  • Thinks removing the store client from code narrows what the fetcher may read
  • Treats the helper's local interface as unreachable by other processes
  • Grants the helper every name so new workloads just work
  • Confuses proving who is calling with deciding what may be read