Kubernetes Admission and Policy Scope

Kubernetes Admission and Policy Scope defines the range of objects, operations, and moments in the API request lifecycle where admission control and policy enforcement can intervene, sitting after authentication and authorization but before an object is persisted to etcd. While RBAC decides whether a request is permitted at all, admission and policy scope governs what shape that request's object must take, what defaults it receives, and what mutations or additional validations apply before the cluster accepts it.

Where Admission Fits in the Request Pipeline

After Authorization, Before Persistence

Once a request passes authentication and RBAC authorization, it proceeds to the admission control phase, which runs a chain of mutating and then validating admission plugins against the object before it is written to etcd. A request can be authorized by RBAC and still be rejected at this stage if it fails validation or violates a configured policy.

Mutating and Validating Phases

Mutating admission webhooks and plugins run first and can modify the incoming object — injecting a sidecar container, setting a default resource limit, adding a label. Validating admission webhooks and plugins run afterward against the (possibly mutated) object and can only accept or reject it, never modify it further, which keeps the final validation step working against a stable, fully-formed object.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: enforce-resource-limits
webhooks:
- name: limits.policy.example.com
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    operations: ["CREATE", "UPDATE"]
    resources: ["pods"]
  admissionReviewVersions: ["v1"]
  sideEffects: None
  clientConfig:
    service:
      name: policy-webhook
      namespace: policy-system
      path: /validate

Scoping Admission by Resource and Operation

Rule Matching

Both webhook configurations and built-in admission plugins scope their effect through rule matchers specifying API groups, versions, resources, and operations (CREATE, UPDATE, DELETE, CONNECT). A webhook configured to match only pods on CREATE never intercepts updates to existing pods or operations on unrelated resource types, which keeps policy enforcement narrowly targeted to the situations it was designed for.

Namespace Selectors

namespaceSelector and objectSelector fields let a webhook's scope be further restricted to namespaces or objects matching specific labels, commonly used to exempt system namespaces (kube-system) from policies designed for application workloads, or to apply stricter policy only to namespaces explicitly labeled as production.

namespaceSelector:
  matchExpressions:
  - key: environment
    operator: In
    values: ["production"]

Policy Enforcement Mechanisms Within This Scope

Built-In Admission Plugins

Plugins such as LimitRanger, ResourceQuota, PodSecurity, and NamespaceLifecycle are compiled into the API server and enabled via --enable-admission-plugins, each scoped to a specific concern — resource limits, quota enforcement, pod security standards, and namespace state respectively.

Pod Security Admission

The built-in PodSecurity admission controller enforces the Pod Security Standards (privileged, baseline, restricted) at the namespace level, using labels on the Namespace object itself to determine which standard applies and whether violations are enforced, audited, or only warned about.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted

Custom Policy Engines

External policy engines such as OPA Gatekeeper or Kyverno register as validating (and optionally mutating) webhooks, extending the built-in admission scope with organization-defined policy written in a dedicated policy language, evaluated against the same rule-matching scope as any other admission webhook.

Failure Modes and Their Scope

failurePolicy Determines Behavior on Webhook Unavailability

A webhook's failurePolicy field determines whether an unreachable policy service causes matching requests to be rejected (Fail) or allowed through unchecked (Ignore); the choice directly affects whether the admission scope's enforcement is strict or best-effort during an outage of the policy service itself.

Scope Gaps From Incomplete Rule Coverage

A policy intended to apply cluster-wide but configured with rules matching only apps/v1 Deployments will silently fail to catch equivalent risky configuration submitted through a DaemonSet, StatefulSet, or bare Pod — admission scope must be defined broadly enough to cover every resource type through which a given risk can actually be introduced.

Reviewing Admission and Policy Scope

Auditing What Is Actually Covered

Enumerating every ValidatingWebhookConfiguration, MutatingWebhookConfiguration, and enabled built-in plugin, alongside the specific resources and operations each one's rules match, reveals the actual enforcement surface of the cluster — often narrower than assumed, since a policy believed to be cluster-wide may in practice exempt several resource types or namespaces through its selector configuration.