Your estate is replacing stored secrets with platform-attested identity — how finely should you cut each workload's identity?
answer
- the subject is the blast radius
- one identity per team proves little
- stable across redeploys, or rules rot
- whoever names the slot mints the identity
- govern naming before granting rules
basics
~20 sAs finely as the rules you can genuinely operate allow, because the attested subject is the unit of blast radius. One identity shared by a team means the document proves only that something that team runs is calling.
solid answer
~40 sGranularity decides what the attestation is worth. One identity for a whole team means every workload the team runs can read every value the team stores — the document verifies and proves nothing useful. One identity per workload makes the subject the unit of blast radius, at the cost of more rules to write, review and retire. Two constraints decide where you land. The identity must be **stable across redeploys**, or rules break on every release and someone widens them to stop the pages. And it must be **unforgeable by its own consumers**: if any team can schedule work under a subject it chose, naming *is* the control, and attestation inherits exactly the strength of your deployment governance. Write the naming scheme down once for the estate rather than letting each team invent one.
go deeper
Recall that the subject in the document is what store rules are written against, so how it is chosen decides how much one workload can reach.
Explain why a shared team identity makes a verified document almost meaningless, and why a subject that changes on every deploy pushes people towards broad rules.
Show that you would check the naming scheme against redeploys, renames, splits and environment boundaries before the first rule is written, and that you would retire old subjects deliberately.
Own the trade-off: how fine a cut the estate can actually operate, who holds naming authority, how that authority is separated from the people consuming the values, and what you standardise so teams do not each invent a scheme.
## What granularity means here When a store authenticates a workload by a platform-signed document, the document's **subject** is the identity everything else hangs off: the rules are written against it, the access records are attributed to it, and a compromise is bounded by it. So the question *how finely do we cut identity* is really the question *what is our unit of blast radius*, asked before any of the rules exist. It is a decision that is cheap to make once and expensive to change later, which is why it is a lead's call rather than a team's. ## Three ways estates cut it | Cut | What an attested document then proves | What it costs | |---|---|---| | One identity per estate or environment | That something in this environment is calling — near enough nothing | Almost no rules to maintain, and no containment at all | | One identity per team or per service group | That something the team runs is calling | Few rules; one compromised workload reaches everything the group stores | | One identity per workload | That this specific workload is calling | More rules to write, review and retire; real containment | | One identity per workload and environment | This workload, in this environment | The above, plus protection against a test workload reading production values | Most estates that take this seriously land on the last row, and the argument against it is always operational rather than conceptual: someone has to keep the rules in step with the workloads. ## The stability constraint The subject has to survive ordinary change. If it is derived from something that moves every release — a build identifier, a generated instance name, a revision — then rules break on every deploy, the team is paged, and the fix that actually gets applied is a broad rule that matches everything. That is how estates end up with a wildcard nobody intended: not by decision, but by three consecutive incidents. Before committing, establish precisely what the subject is derived from, and check it against: - a routine redeploy of the same workload; - a restart, a rescheduling, or a move to different capacity; - a rename of the team or the grouping that contains it; - splitting one workload into two, or merging two into one. ## Who controls the naming This is the question that matters most and gets asked least. If a team can schedule work under any subject it likes, then the ability to choose a name is the ability to be that identity, and every store rule in the estate is enforced by whatever governs deployment rather than by the store. Attestation does not remove the trust decision; it relocates it into the platform. So the answer has two halves that must be designed together: 1. **Who may create and schedule into a slot under a given subject** — and whether that authority is separated from the people who own the values behind those rules. 2. **Who may write the store rule that names the subject** — because a rule granting access to a subject anyone can claim is a rule granting access to anyone. An estate that gets the first half wrong has strong cryptography and no access control. ## How to decide 1. **Start from what the values are worth.** Cut finely where a compromise would be expensive and coarsely where the values are low-stakes; a uniform rule applied to both is how the operational cost becomes indefensible. 2. **Require stability as a property of the naming scheme**, not as a hope — and verify it against the change list above before the first rule is written. 3. **Separate naming authority from consumption.** The teams reading the values must not be able to mint arbitrary subjects for themselves. 4. **Bound the number of rules you will operate**, honestly. A scheme that produces more rules than anyone will review produces stale rules, and a stale rule is a standing grant. 5. **Plan retirement from the start.** Splitting a workload into three services needs three identities and three rules, plus the retirement of the old subject once nothing presents it. Otherwise the split quietly re-creates a shared identity. ## What you write down for other teams The deliverable is short: the shape of a subject, what each part of it is derived from, who may create one, what happens at a redeploy, and how an identity is retired. Teams will not infer a consistent scheme on their own, and inconsistency here is not cosmetic — it is the difference between a rule that means *this workload* and one that means *anything anyone chose to call this*.
- Who effectively controls what your store will authenticate once you adopt attested identity?Whoever controls naming and scheduling on the platform. If a team can run work under a subject that matches a rule, it can read that rule's values without ever touching the store. Attestation relocates the trust decision into deployment governance, so that governance has to be audited with the same seriousness as the store's own rules.
- A workload is being split into three services. What has to happen before the split ships?Each new service needs its own subject and its own rule, and the old subject must be retired once nothing presents it any more. Splitting the code while leaving one shared subject re-creates a group-wide identity silently, and afterwards the store cannot tell the three apart in its rules or in its access records.
saying these in an interview costs you the question
- Gives a whole team one workload identity and calls it least privilege.
- Derives the subject from a name any team can freely choose.
- Assumes the identity survives a redeploy without checking what it is derived from.
- Treats deployment governance as unrelated to store access.
- Cuts identity so finely that nobody can review the resulting rules.