skip to content

For a store many teams share, should rights follow the branch of names a value sits under, or its labels and owner?

level: principalimportance: nice to knowfreq 27%

answer

  1. position versus description
  2. one hierarchy only
  3. renaming moves the permission
  4. labels depend on whoever writes them
  5. unlabelled must default to refused

basics

~20 s

Name-tree rules make the boundary visible and let a new value inherit a scope automatically, but encode only one hierarchy and turn a rename into a permission change. Label rules express cross-cutting scopes at the cost of depending on data a writer sets.

solid answer

~50 s

Both are real designs and they fail differently. A rule over a **branch of names** makes the scope readable at a glance, matches values created later without a rule change, and puts the boundary where everyone can see it — but the tree encodes exactly one hierarchy, so the moment a scope cuts across it (all production credentials, everything a given service consumes) you either duplicate names or bolt on exceptions, and moving a value becomes a permission change. Rules by **label and owner** express those cross-cutting scopes directly and survive renames, but the grant now depends on attributes some writer sets, so a mislabelled or unlabelled value changes who can read it with no rule edited and no review. Most estates end up hybrid: the tree carries the coarse tenant boundary, labels carry the exceptions, and unlabelled defaults to refused.

code

yaml · 12 lines
yaml
byName:
  grantedTo: search-indexer
  rights: [read]
  nameMatch: "teams/search/prod/**"   # scope is wherever the value sits in the tree

byLabel:
  grantedTo: search-indexer
  rights: [read]
  select:
    owner: team-search
    environment: prod                  # scope is whatever carries these labels
  unlabelled: deny                     # a value missing either label matches nothing

go deeper

for a junior

Know that a rule identifies its values either by where the name sits or by attributes the value carries, and that both are real designs.

for a middle

Explain the concrete consequences: a new value inherits a branch rule immediately, while a label rule matches nothing until the value is labelled.

for a senior

Show the operational edges — a rename as a permission change, an unlabelled default, and duplicated values created because the second axis was expensive.

for a principal

Choose the convention for the estate and state the cost you accepted: which axis is the boundary, what defaults to refused, and how the audit question gets answered.

## Two ways to say the same scope A rule has to identify the values it covers. There are two families of answer, and a lead choosing the convention for a store many teams will share is really choosing which failure mode the estate lives with. - **By name.** The rule carries a pattern over the name space: everything under `teams/search/prod/`. The value's position *is* its permission. - **By label and owner.** The value carries attributes — an owner, an environment, a sensitivity, a consuming system — and the rule selects on them. The value's description is its permission. | | rule over a branch of names | rule by label and owner | |---|---|---| | where the scope lives | in the name, visible in any listing | in attributes attached to the value | | a new value | inherits the rule from where it is created | matches only once it is labelled | | a cross-cutting scope | awkward: one hierarchy only | natural: select on the attribute | | renaming or moving | changes who may read it | changes nothing | | who can alter the scope | whoever can write rules | also whoever can set the attributes | | answering *who may read this* | read the tree and the patterns | run a query over rules and attributes | ## What the name tree buys, and what it costs It buys legibility and inheritance. A reviewer reads the pattern and knows the scope; a team adds a value under its branch and the right service can read it with no rule change. The boundary between tenants is a segment everyone can see, and that visibility is most of why it works in practice. The cost is that a tree encodes **one** hierarchy. Whichever axis you put first — owner, environment, system — becomes the cheap one to scope on, and every other axis becomes expensive. *All production credentials* is trivial if environment is the first segment and a mess if it is third. Teams resolve that by duplicating values into a second location, which is how one credential quietly becomes three copies with three different rules. And because position is permission, **moving or renaming a value is a permission change**: a restructure that touches no rule text can move values across boundaries. ## What labels and owner buy, and what they cost They buy cross-cutting scopes and stability under renames. *Everything owned by the payments team in production*, *everything consumed by the indexing service*, *everything marked highest sensitivity* are each one rule, and they keep working when names change. The cost is that the grant now depends on data rather than on structure: - A value created **without** the labels matches no rule, so the default for the unlabelled has to be decided deliberately — refused is the only safe answer, and it means new values fail until labelled. - A value **mislabelled**, by accident or otherwise, changes who may read it without any rule being edited or reviewed. - Whoever may set a label is, in effect, adjusting scope, so the ability to set labels needs its own thought. - *Who can read this value* stops being something you read off a tree and becomes a query across rules and attributes, which the store may or may not answer for you. ## What a lead actually standardises 1. **The boundary segment.** Which axis is first in the name, and that the first segment is the tenant boundary nothing crosses. 2. **The default.** Names outside the convention, and values missing their labels, are refused rather than falling into someone's pattern. 3. **Enumeration.** List is denied at the shared root and granted per branch, because a convention that carries meaning also discloses it. 4. **Which axes are labels.** The cross-cutting ones — sensitivity, consuming system, lifecycle — rather than re-encoding them as extra name segments. 5. **The answer to the audit question.** How, concretely, the estate answers *who could have read this value*, given whichever model it chose. ## The hybrid most estates land on In practice the coarse boundary goes in the tree, where it is visible and hard to get wrong, and the cross-cutting exceptions go in labels, where they are cheap to express. That hybrid is defensible as long as the two are not allowed to contradict: a label must never widen a scope the tree refuses, or the visible boundary stops being the boundary. ## What breaks later The convention nobody enforces (documented layout, no deny at the root); the `shared/` branch that grows until it is the estate's real permission model; a reorganisation that invalidates the owner axis the whole tree was built on; and the slow accumulation of values duplicated because the second axis was expensive. None of these are avoidable by picking the other model — they are the running cost of whichever you pick, and a principal-level answer says which cost it is accepting and why.

  • Why is moving a value between branches a permission change under the name model?
    Because the rules select on names. The value's new name is matched by a different set of patterns, so its readers change the instant it moves — without any rule being edited. That is why a name-space restructure has to be reviewed as an authorization change, not as housekeeping.
  • What must be true before label-based rules are safe to rely on?
    Unlabelled values must default to refused rather than falling through to a broad rule; setting a label must be treated as adjusting scope; and the estate must have a way to answer which values a given rule currently selects, since that set changes whenever anyone edits an attribute.
  • Which axis should be first in the name tree?
    The one that is also your boundary — usually the owning team, because that is what must never be crossed and what changes least often. Environment second, system third. Whichever goes first becomes the cheap scope to express and the others become exceptions, so put the boundary where the cheapness is worth most.

saying these in an interview costs you the question

  • Calls one model correct without naming its cost
  • Assumes labels need no default for the unlabelled
  • Treats a rename as housekeeping, not a scope change
  • Believes a name tree can carry every permission axis
  • Forgets that whoever sets a label is adjusting scope