What does a single broker grant have to name before the cluster can decide whether a request is allowed?
answer
- a lookup, not a login
- one rule, several columns
- identity, verb, named target
- plus permit or refuse
- and what an unmatched request gets
basics
~20 sA grant names four things: the principal making the request, the operation attempted, the named resource it is attempted on, and whether that combination is permitted or refused. Leave any one loose and the rule decides more than intended.
solid answer
~50 sAuthorization on a broker is a lookup, not a login. By the time a request arrives the cluster already holds a `principal` for the connection, whatever mechanism established it; the remaining question is whether anything in the grant table binds that principal to this operation on this named resource, with an effect of permit or refuse. Those four parts are the whole unit, and each one is a place where a rule quietly widens: a shared principal used by six services cannot be narrowed to one of them, a coarse operation stands in for writing and deleting alike, and a resource written as a name fragment covers names nobody has created yet. What happens when nothing matches varies by platform - most refuse once enforcement is switched on, while several ship permissive until an operator enables it, so "we have grants" and "the grants are enforced" are two different claims.
go deeper
Recall the four parts in order - which identity, doing what, to which named resource, permitted or refused - and remember that connecting successfully is a separate step from being allowed to act.
Explain how each part widens in practice: a shared identity, a coarse operation, a name fragment as the resource. Say that the unmatched-request default varies between platforms rather than asserting one.
Demonstrate that you check enforcement, not just the table: whether authorization is switched on, what an unmatched request actually gets, and whether a refusal is distinguishable from a missing stream.
Frame the four parts as the estate's vocabulary. If teams cannot describe a rule in those terms, grants will be issued per team rather than per operation, and no cluster in the estate will be comparable to another.
## The question a broker is actually answering When a client asks a broker to append a record, read from a stream, or create one, the cluster is not asking *who are you* - that was settled when the connection was established and left the broker holding a **principal**, an identity string it can compare against rules. Every later request reduces to one lookup: **is there anything in the grant table that lets this principal perform this operation on this named resource?** A **grant** is the unit that makes that lookup possible, and the reason interviewers ask about its shape is that each of its parts is a place where real systems leak. ## The four parts - **The principal** - the identity the broker holds after the connection is established. It may have come from a password-style exchange, a certificate, an issuer-signed short-lived token, or from the platform the client runs on vouching for it; the grant does not care which. It cares that the identity is *specific enough to narrow*. A single identity shared by six deployments is a ceiling on how tight any rule can ever be. - **The operation** - the verb being attempted. Brokers distinguish far more than reading and writing, and a grant that names a coarse operation is a grant to everything that coarse operation covers. - **The resource** - the named thing the operation acts on: a stream, a namespace, sometimes the cluster itself. A resource can be written as an exact name, as a **prefix grant** over a name fragment, or as a match-all. The last two are evaluated against whatever names exist at the moment of the request, not the names that existed when the rule was written. - **The effect** - whether this combination is permitted or refused. Most grant tables are written entirely in permits, with refusal being the absence of a match; some platforms also let you write an explicit refusal. | Part | What it answers | What goes wrong when it is left loose | |---|---|---| | Principal | who is asking | one shared identity behind several workloads, so no rule can be narrowed to one of them | | Operation | what they are attempting | one broad right standing in for appending, creating, altering and deleting | | Resource | on what name | a fragment or match-all that reaches names created long afterwards | | Effect | permit or refuse | rules written as documentation that nothing actually evaluates | ## What happens when nothing matches This is where platforms genuinely differ, and a candidate who states one behaviour as universal is describing the product they happen to know. Designs vary along two axes worth naming: 1. **The default.** Most brokers refuse anything no grant covers once authorization is enabled - but on several, enforcement is itself something an operator turns on, and until then every request is permitted regardless of what the table says. A cluster can therefore have a carefully written grant table and be wide open. 2. **What the client is told.** Some platforms report a refusal distinctly from a missing stream; others answer identically on purpose, so that an unauthorised caller cannot map what exists. A client-side error message is evidence, not proof. ## Where the rule lives, and who evaluates it The four parts survive either arrangement. The broker may hold its own grant table and evaluate it itself, or it may delegate the decision to the surrounding platform, which evaluates its own rules and answers permit or refuse. A rented cluster may only offer you the second. Either way the same four questions are being asked; what changes is who can change a rule, how finely the operations can be expressed, and what happens when the deciding system is unreachable. ## Why this is a first-screen question Because the failures it predicts are the ones interviewers have lived through. A team that cannot say what a grant names will write one grant per team rather than per operation, will hand out a fragment resource because it saves a ticket, and will read a short grant table and conclude the cluster is tight. Knowing the shape is what turns "we have security on the cluster" into four checkable questions: *which identity, doing what, to which names, permitted or refused.*
- If the grant table is empty, is the cluster open or closed?It depends on the platform, and that is the point. Most brokers refuse anything no grant covers once authorization is enforced, so an empty table means nobody but the unrestricted setup identity can do anything. But on several platforms enforcement is a switch an operator must throw, and until it is thrown the table is inert and every request succeeds. Confirm which state the cluster is in rather than inferring it from the rules.
- Why is a grant written over a client's network address a weaker rule than one written over a principal?An address says where a connection came from, not who is on it. Addresses are reassigned, shared behind a gateway, and reused by the next workload scheduled onto the same host, so the rule silently transfers to whoever inherits the address. A principal is derived from a credential the caller had to present, so the rule follows the identity rather than the location. Address rules are useful as a coarse extra filter, never as the identity.
saying these in an interview costs you the question
- Says a successful connection means the request will be allowed
- Treats reading and writing as the only operations a grant can name
- Assumes every broker permits anything no grant mentions
- Writes grants over a network address instead of a principal
- Believes a rule that exists in the table is necessarily being enforced