A search indexer's grant allows every action on every resource — what does narrowing it by action, by resource and by condition each buy?
answer
- three dimensions, not one slider
- verbs, targets, circumstances
- action narrows what, resource narrows which
- condition narrows when, where, how called
- a wildcard on any axis reopens it
basics
~20 sEach axis cuts a different dimension of blast radius: actions limit what the caller may do, resources limit what it may touch, conditions limit the circumstances in which the grant applies. Narrowing one leaves the other two wide.
solid answer
~50 sA grant is not one slider. `action` says which operations are allowed, `resource` says which things they may be performed on, and `condition` says under what circumstances the grant is evaluated at all — caller network, transport, time of day, or an attribute of the request. For the indexer, the actions drop from everything to reading and listing, the resources drop from the whole account to the one prefix it indexes, and a condition can require that the call arrive over the private route and be encrypted. The axes are independent, which is why narrowing only the actions still lets the caller read every object in the account, and narrowing only the resources still lets it delete the one it was given. I narrow the resource first, because it bounds the data exposed and I can verify it from the workload's own configuration.
code
json · 6 lines{
"effect": "allow",
"principal": "workload/search-indexer",
"action": "*",
"resource": "*"
}go deeper
Recall that a grant names an action, a resource and often a condition, and that leaving any of them as a wildcard means that dimension is unrestricted.
Explain each axis and what it independently restricts, and show with the indexer what a stolen credential can still do after narrowing only one of them.
Show the order you would apply the narrowing on a live grant, how you verify each step before it ships, and which failure mode each axis has in production.
Frame the axes as a standard other teams can follow without you: which axis is mandatory, which is advisory, and how the choice is kept true as resources multiply.
## What a grant is made of A platform grant is a small declarative document. Whatever a provider calls the fields, the same five things are always present: - **effect** — allow or deny. - **principal** — who the grant is about: a human, a group, or a workload identity such as the indexer. - **action** — which operations are permitted. - **resource** — which things those operations may be performed on. - **condition** — the circumstances under which the grant applies at all. **Least privilege is not a property of the document; it is the claim that each of the last three fields is as narrow as the job allows.** A wildcard in any one of them re-opens the grant along that axis, however tight the other two are. That is the whole reason interviewers ask this question by axis rather than asking "do you follow least privilege": everyone says yes, and the useful answer is which axis you narrowed and what it bought. ## The three axes are independent | Axis | Restricts | Answers | Leaves open | |---|---|---|---| | `action` | the verbs | what may this caller do? | which things it may do them to | | `resource` | the targets | which things may it touch? | everything it may do to them | | `condition` | the circumstances | when, from where, how called? | everything, whenever the condition holds | Independence is the point. A grant of `read` on `*` is a grant to read the whole account. A grant of `*` on one store is a grant to delete that store. Neither is least privilege, and both are common — each was written by someone who narrowed the axis they happened to be thinking about. ## Narrowing the indexer, one axis at a time The indexer is a customer-facing search tier's batch job. It walks published catalogue media, extracts text, and writes an index. It shipped with a wildcard grant to get the launch out. 1. **Resource.** It reads one prefix of one store and writes one index. Scoping the resource to that prefix means a stolen credential reads published catalogue media and nothing else — not the billing exports, not the customer uploads, not the backups sitting in the same account. This is the largest single reduction available and usually the safest, because the set of things the workload touches is knowable from its own configuration. 2. **Action.** The job reads and lists; it never deletes and never changes permissions. Dropping every other verb means the same stolen credential cannot destroy what it can read. Deletion and permission-changing verbs are the two families worth removing first, because they are the ones whose damage a backup or a rollback does not undo cheaply. 3. **Condition.** The job runs inside the private network on a schedule. A condition requiring the call to arrive over the private route, over an encrypted transport, means a credential pasted into a laptop terminal on a café network does not work at all. Note the direction carefully: the private route by itself does not authorize anybody — routing and permission are separate mechanisms. It is the **condition in the grant** that turns the route into an access requirement. ## What survives each narrowing A useful way to check your own work is to ask what an attacker holding the credential can still do after each step: - After action-only narrowing: read every byte in the account. Enough for a data-exposure incident on its own. - After resource-only narrowing: delete or overwrite the catalogue media and the index, and change what the search tier serves. - After both: read and list published catalogue media from anywhere, at any time, for as long as the credential lives. - After all three: use the credential only from inside the environment it was meant for — which converts a credential leak into an intrusion that first has to get inside. ## Where each axis quietly fails - **Actions are not equally dangerous.** A narrow list containing one permission-changing verb can be broader in effect than a long list of read verbs. Count consequence, not entries. - **Resource patterns drift.** A pattern that matched one prefix at launch matches a new sibling prefix a team adds later. A pattern is a rule about the future, not a snapshot. - **Conditions can be met by the attacker.** A condition is only worth what it is expensive to satisfy. "Comes from inside the private network" stops a stolen credential used from outside; it stops nothing once the attacker has any foothold inside. - **Conditions break quietly.** A time-of-day condition on a job that is later rescheduled produces a failure nobody attributes to the grant. ## Which one first On a live grant the order that minimises both risk and breakage is resource, then action, then condition. Resource is verifiable from the workload's configuration and buys the most. Actions are next because the workload's code tells you which verbs it issues. Conditions go last because they are the axis most likely to fail in a way that is hard to debug at three in the morning — the call is refused, the workload logs a permission failure, and nothing in that failure says "a condition did not hold".
- The indexer only ever touches one prefix of one store. Why bother listing the actions at all once the resource is scoped that tightly?Because the resource scope says nothing about the verbs. With the resource pinned and the action left wildcard, a stolen credential can still delete the catalogue media, overwrite it, or change the permissions sitting on it. Scoping the resource bounds what is exposed; scoping the action bounds what can be destroyed. They answer different questions and a real incident asks both.
- Which axis would you narrow first on a grant you cannot afford to break, and why that one?Resource. It buys the largest reduction in exposure, and the set of things a workload touches is usually knowable from its own configuration, so the change is verifiable before it ships. Actions come second because the code tells you which verbs it issues. Conditions come last: they are the axis most likely to fail in a way that is hard to diagnose during an incident.
- What does a condition requiring calls to arrive over the private route actually protect against?A credential used from outside the environment — pasted into a laptop, lifted from a log, or exercised by an attacker who has the secret but no foothold. It protects against nothing once the attacker is running code inside the network the condition names, so it is a useful layer rather than a boundary you can lean on alone.
A building pass can be limited by which doors it opens, which floors it reaches, and which hours it works. Taking away the hours still opens every door on every floor.
saying these in an interview costs you the question
- Says least privilege means one narrow grant, without naming which axis was narrowed
- Treats a wildcard resource as safe because the actions are read-only
- Assumes narrowing the resource also narrows which operations are allowed on it
- Believes a condition on the caller network makes a wildcard resource acceptable
- Claims the private network route itself decides who may call the service
- Counts permissions by entry, ignoring that one verb can outrank fifty