Kubernetes Admission and Policy Areas

Kubernetes Admission and Policy Areas groups together the mechanisms that intervene between a request passing authorization and that request's object being persisted to the cluster's state store, covering both the built-in admission control machinery and the broader ecosystem of policy engines that extend it. This area governs not who can act, but what shape their actions must take — enforcing defaults, resource constraints, security baselines, and organization-specific rules that RBAC alone has no mechanism to express.

The Admission Control Pipeline

Mutating Then Validating

Every request that reaches admission control passes first through mutating admission plugins and webhooks, which can alter the submitted object, and then through validating admission plugins and webhooks, which can only accept or reject the (possibly already mutated) object. This ordering ensures validation always evaluates the final form of an object rather than an intermediate one.

Built-In Admission Plugins

The API server ships with a substantial set of built-in plugins controlled via --enable-admission-plugins and --disable-admission-plugins, including NamespaceLifecycle (preventing operations on terminating namespaces), LimitRanger (enforcing default and maximum resource constraints), ResourceQuota (enforcing namespace-level consumption caps), and PodSecurity (enforcing Pod Security Standards).

kube-apiserver \
  --enable-admission-plugins=NodeRestriction,PodSecurity,ResourceQuota,LimitRanger

Extending Admission With Webhooks

MutatingWebhookConfiguration and ValidatingWebhookConfiguration

Beyond built-in plugins, the API server supports arbitrary external admission logic through webhook configurations, each specifying which resources and operations to intercept and which external service to call for a decision.

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: inject-sidecar
webhooks:
- name: sidecar.mesh.example.com
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    operations: ["CREATE"]
    resources: ["pods"]
  clientConfig:
    service:
      name: sidecar-injector
      namespace: mesh-system
      path: /mutate
  admissionReviewVersions: ["v1"]
  sideEffects: None

Policy-as-Code Engines

General-purpose policy engines such as OPA Gatekeeper and Kyverno register as webhooks but allow policy to be authored declaratively (Kyverno) or through a dedicated policy language (Gatekeeper's Rego via OPA constraints), decoupling policy authorship from the mechanics of webhook registration itself.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-limits
    match:
      resources:
        kinds: ["Pod"]
    validate:
      message: "Resource limits are required."
      pattern:
        spec:
          containers:
          - resources:
              limits:
                memory: "?*"
                cpu: "?*"

Major Policy Areas Enforced Through Admission

Pod Security Standards

PodSecurity admission enforces the privileged, baseline, and restricted standards at the namespace level, blocking or warning about pods that violate the configured standard — for example, rejecting privileged containers or host namespace usage in a namespace labeled restricted.

Resource Governance

LimitRanger and ResourceQuota together ensure that every container receives sensible default resource requests and limits, and that a namespace's total consumption stays within organizationally defined bounds, preventing a single misconfigured workload from monopolizing cluster capacity.

Image and Supply Chain Policy

Custom policies commonly enforce that container images originate only from approved registries, carry required signatures, or meet vulnerability scanning thresholds, implemented as validating webhooks that inspect the image reference and, where integrated with an external verification service, its associated attestations.

Configuration Hygiene

Policies enforcing required labels, disallowing the latest image tag, requiring liveness and readiness probes, or preventing the use of the default service account are common examples of organizational configuration standards implemented through admission rather than left to manual review.

Operational Considerations

Failure Policy and Availability

Because validating webhooks sit in the request path, their availability directly affects the cluster's ability to accept new or modified objects; failurePolicy: Fail enforces strict policy at the cost of blocking legitimate requests during a webhook outage, while failurePolicy: Ignore preserves availability at the cost of allowing policy violations through unchecked.

Performance Impact

Every matching request incurs the latency of a webhook call, so admission and policy configuration should be scoped precisely to the resources and operations that genuinely need it, avoiding broad rule matchers that route large volumes of unrelated traffic through policy evaluation unnecessarily.

Auditing Coverage

Reviewing the full set of active admission plugins and webhook configurations together — rather than any single policy engine in isolation — is necessary to understand the cluster's true admission and policy enforcement surface, since gaps often exist between the union of what each individual mechanism believes it covers.