Should 400 workers of one service share one store identity or hold one each, judged purely by which abnormal reads become visible?
answer
- the shape is attached to the identity
- sharing folds behaviours together
- a union envelope departs from nothing
- thin shapes and identity churn are real costs
- per role or per environment, rarely per instance
basics
~20 sOne each, on detectability alone: a shared identity averages 400 workers into one shape, so a thief's reads hide inside the fleet's normal spread. The cost is 400 thin baselines and churn that resets them whenever the fleet scales.
solid answer
~50 sThe baseline is only as sharp as the identity it is attached to. With one shared identity, the recorded shape is the union of 400 workers: every source range the fleet has ever run in, every hour any instance was alive, and a read count in the tens of thousands. An attacker reading from inside that envelope departs from nothing. With one identity per worker, each shape is two names, one source, a narrow hour band and two reads per start, and almost any abuse leaves it. The honest cost is real: 400 baselines to derive and keep, identities that churn every time the scheduler replaces a worker, and thin shapes that a single legitimate extra read can move. Most estates settle in between — an identity per deployment or per environment, not per instance.
go deeper
The idea to hold on to: if many machines share one credential, the store cannot tell them apart, so 'unusual for this caller' loses most of its meaning.
Explain what sharing does to each dimension — source and hour become unions, volume becomes a wide spread — and note that breadth is the one that survives.
Argue the operational side: thin baselines on short-lived identities are noise, so recommend a boundary per role or per environment and keep source attribution on the event.
Own the trade explicitly. Set the identity boundary to the thing you want to reason about, price churn and administration honestly, and pair the split with grant narrowing so visibility and reach improve together.
## Why identity granularity is a detection decision Every signal in this area is a comparison between a read and a recorded shape, and the shape is attached to an identity. So the choice of how many identities exist is, whether anyone intends it or not, a choice about how sharp every one of those comparisons can be. It is usually argued on other grounds — how much access one compromised credential buys, how much administration each identity costs — and those are legitimate. This question deliberately isolates the detection axis, because it is the one teams forget they are deciding. ## What a shared identity does to the shape Take the 400 workers, each reading two values at start-up. With one shared identity, the baseline becomes the **union** of everything any instance ever did: - **Source:** every address range the fleet has ever occupied, which after a couple of migrations is broad. - **Hours:** the union of every hour any of 400 instances was alive, which for anything that runs continuously is all of them. - **Volume:** tens of thousands of reads a day, with a wide spread, because deploys and scale events are lumpy. - **Names:** still two — breadth is the one dimension that survives sharing, because sharing does not widen what the job needs. The result is an envelope so wide that an attacker reading the two values a few thousand times, from inside the fleet's own network, during the day, departs from nothing at all. The only dimension left with any resolution is breadth, and only if the grant is tight. ## What per-worker identity buys, and costs | | Shared identity | Identity per worker | |---|---|---| | Source dimension | union of all ranges the fleet used | the one host this worker runs on | | Hour dimension | effectively always-on | the narrow band this instance lived in | | Volume dimension | tens of thousands, wide spread | two per start, exact | | Breadth dimension | unaffected by sharing | unaffected by sharing | | Baselines to maintain | one | four hundred | | Effect of scale-out | none | new identities with no shape yet | The costs in the bottom rows are not bookkeeping complaints; they are the reason most estates do not go all the way. Workers a scheduler replaces get new identities constantly, so a per-instance shape may never accumulate enough history to be a baseline at all. A shape built from two reads is also brittle: one legitimate extra read is a 50% departure, and a stream of those trains everybody to ignore the signal. ## Where the honest answer usually lands The useful framing for a lead is: **make the identity boundary match the boundary you want to be able to reason about.** In practice that is usually not per instance and definitely not per fleet: 1. **Per deployment or per role**, so all 400 workers of one service share one identity but do not share it with the batch jobs, the gateway or the migration tooling. The shape stays meaningful because the members genuinely do the same thing. 2. **Split by environment**, so a production shape is never widened by test traffic — this is often the single cheapest sharpening available, because test behaviour is the messiest. 3. **Separate anything whose shape is different in kind**, especially human-driven and break-glass access, which should never be averaged into a workload's shape. 4. **Derive the shape at the group level and keep instance attribution on the event**, so the baseline is stable while the record still says which host read. That last point is the one that resolves most of the tension: you do not need 400 separate baselines to know which of 400 hosts made a given read, provided the source is recorded per event. Granularity of the *identity* and granularity of the *record* are different knobs, and conflating them is what makes this look like a binary choice. ## The judgment to demonstrate There is no universally right answer, which is what makes it a lead's call. What a strong answer shows is that the person understands the mechanism behind the trade: a baseline's resolution is bounded by how many different behaviours were folded into the identity it describes, and sharing an identity is exactly the operation that folds behaviours together. Then they price the other side honestly — identity churn, thin shapes, the administrative load — and pick a boundary with a reason attached rather than inheriting whatever the deployment tooling made convenient. One caveat worth stating: none of this changes what the credential can reach. Splitting identities to sharpen detection while every one of them carries the same wide grant improves visibility and nothing else. The two decisions travel together and are worth making together.
- Which dimension of the baseline is unaffected by sharing an identity?Breadth. Sharing does not widen what the job needs, so the set of names remains two whether one worker or 400 use the credential. That is why an over-wide grant hurts twice — it is the one dimension a shared identity would otherwise have kept.
- How do you get per-host attribution without 400 baselines?Keep the identity at the group level and record the source on every event. The baseline then describes the role, while the record still answers which host made a particular read. Identity granularity and record granularity are separate knobs.
- What is the strongest argument against per-worker identities in a fleet that scales constantly?A shape needs history, and an identity that exists for twenty minutes never accumulates any. You end up with hundreds of baselines too thin to depart from, which produces noise rather than signal and trains people to ignore the whole class.
saying these in an interview costs you the question
- Assumes finer identities are strictly better at every fleet size
- Forgets that a shared shape is the union of every member's behaviour
- Ignores identity churn in a fleet the scheduler replaces constantly
- Splits identities for detection while leaving every grant equally wide
- Conflates how granular the identity is with how granular the record is