skip to content

In Kubernetes, what does scoping an admission rule by objectSelector rather than namespaceSelector grant a developer?

level: seniorimportance: should knowfreq 44%

answer

  1. who writes the label you are matching on
  2. the exemption arrives with the thing being exempted
  3. RBAC has no field-level granularity
  4. inclusion good, exclusion dangerous
  5. namespace labels are only safer if gated

basics

~20 s

Scoping by objectSelector grants a self-service opt-out. Labels live on the submitted object, so anyone allowed to create that object can also set the label that puts it out of scope, in the same manifest the rule would have judged.

solid answer

~40 s

The two selectors read label sets with different owners. `objectSelector` reads labels on the object being admitted, written by whoever submits it — so a scope that skips anything labelled `policy-exempt: true` is a waiver available to every account with create rights on that resource, taken at submission time and recorded nowhere but the object. `namespaceSelector` reads labels on the Namespace, and where namespaces are provisioned by the platform, an exclusion there needs an action by someone other than the person being excluded. That is an authorization decision disguised as a scoping choice. RBAC cannot patch over it either: it grants verbs on resources, not permission to set one label, so policing the label needs a second admission rule — one that must not be exemptible the same way.

go deeper

for a junior

Know that a scope keyed on labels is only as trustworthy as the people who can write those labels, and that object labels come from whoever submits the object.

for a middle

Explain the difference between the two label sets and their owners, and that objectSelector is evaluated against the old object too, so the label-adding update is still intercepted.

for a senior

Show the authorization reasoning: name who can write each label in your cluster, explain why RBAC cannot restrict a single label, and put the carve-out where the carved-out party cannot reach it.

for a principal

Own the framing that scoping is delegation. Every selector hands the power to be out of scope to whoever controls its input, and that allocation should be a deliberate, written decision rather than a side effect of which stanza was easier.

## The concrete situation You operate the engine. The rule is: *every Deployment with more than one replica must carry the labels a PodDisruptionBudget can select.* It is right for tenant services and wrong for infrastructure, so it needs a carve-out. Two obvious ways to express it: - **objectSelector**: intercept only objects that do **not** carry `policy.example.com/pdb-exempt: "true"`. - **namespaceSelector**: intercept only namespaces carrying `platform.example.com/tenant: "true"`, or exclude a named list of infrastructure namespaces. Both are one stanza. They differ entirely in who can move the boundary. ## Who writes the label Object labels are part of the object. They arrive in the same request the rule exists to judge, written by the same account. If your scope keys on one, then every principal with `create` on Deployments in that namespace can exempt their own Deployment by adding two lines to the manifest — no ticket, no second party, no review, and no artefact anywhere except the label itself. The guardrail has not been bypassed by a bug; it has been used exactly as configured. Namespace labels are usually different, but only *usually*, and this is where a good answer separates itself. The property you are relying on is not "it is a namespace selector", it is "only the platform team can write these labels". If teams self-serve namespace creation, or if a namespace's labels are managed in the same repository the team owns, a `namespaceSelector` exclusion is exactly as self-service as an object one — worse, in fact, since one label now exempts everything in the namespace at once. Check who can write the label before you claim the property. ## Why RBAC does not rescue you The instinct is to say "we will just not grant permission to set that label". Kubernetes RBAC grants verbs on resources; it has no field-level granularity, so there is no rule that permits patching a Deployment while forbidding one label on it. The only way to police the label is another admission rule — one that rejects writes setting `pdb-exempt` unless the requester is in an approved group, checked through a CEL condition on the request's user or groups. Which is fine, and is what mature setups do, with one condition: that second rule must not itself be scoped by an object label, or you have built a lock whose key is taped to the door. ## Where objectSelector is the right tool None of this makes object selectors bad; it makes them directional. They are the right choice for **inclusion**, where the client asking to be in scope is exactly the semantics you want: a pilot programme that only evaluates workloads labelled into it, or a rule that applies to objects a trusted controller stamps. They are a poor choice for **exclusion** of a rule anyone would prefer not to face. A useful review question: *if the population this selector removes could choose to remove itself, would I mind?* ## One mechanic worth knowing An `objectSelector` is evaluated against both the incoming object and the old one on an update, and matches if either matches. So with an exclusion keyed on `DoesNotExist`, the update that first adds the exemption label is still intercepted — the old object lacks the label, so the rule runs on that request. The escape route is therefore creation, not mutation: an object created already carrying the label is out of scope from its first moment. Do not present the update behaviour as protection; it closes one door and leaves the front one open. ## What to do instead For the carve-out this rule actually needs, put the boundary where the party being carved out cannot reach it: - exclude the infrastructure namespaces by name through the automatic `kubernetes.io/metadata.name` label, so the list of exempt places is a short, reviewable line in the policy's own scope rather than a property scattered across hundreds of objects; - if genuine per-workload exemptions are needed, express them through a CEL condition on the requesting identity, or as data the engine holds and the developer cannot write; - and keep the exclusions visible in one place. An exclusion in the match block is one artefact a reviewer can read in full; an exemption label is a claim that has to be discovered by querying the cluster.

  • Someone adds the exemption label to an existing Deployment. Does the rule run on that update?
    Yes. objectSelector is evaluated against both the incoming object and the old one and matches if either does, so the update that adds the label is still intercepted; the exemption takes effect from the next write onward. That is not a defence, though — creating the object already labelled skips evaluation from the very first request, and creation is the path anyone routing around a rule would take.
  • Can't you just deny permission to set that one label?
    Not with RBAC. It grants verbs on resources and has no field-level granularity, so there is no way to allow patching a Deployment while forbidding one label on it. Policing the label needs a second admission rule that rejects writes setting it unless the requester is in an approved group — checked against the request's user or groups in a CEL condition — and that rule must not be scoped by an object label itself.
  • Is a namespaceSelector automatically safer?
    Only if namespace labels are gated. The property doing the work is who can write the label, not which selector reads it. In clusters where teams self-serve namespaces or manage namespace manifests in their own repository, a namespace label is just as writable by the excluded party — and it exempts every object in the namespace at once, which is a larger blast radius than a per-object label.
  • When is an objectSelector the right choice?
    When opting in is the intent. Scoping a pilot to workloads that carry an enrolment label, or to objects a trusted controller stamps, uses exactly the property that makes it unsafe for exclusions. The review test is simple: if the population this selector removes from scope could choose to remove itself, would that be acceptable?

A guest list where guests write their own names, versus one held at the door. Both are lists; only one is a control.

saying these in an interview costs you the question

  • Treats labels as inert metadata that cannot affect enforcement
  • Claims RBAC can forbid setting a single label on a resource
  • Says an exemption label is fine because it lives in git
  • Assumes the platform owns namespace labels without checking
  • Presents the update-time match behaviour as real protection

context

resolving links…