Kubernetes Admission Policy Guidelines

Kubernetes Admission Policy Guidelines describe the practices for validating and mutating cluster objects at the moment they are submitted to the API server, before they are persisted, using admission controllers, ValidatingAdmissionPolicy, and webhook-based policy engines — the mechanism that lets a cluster enforce organizational standards (security posture, resource discipline, naming conventions) as hard requirements rather than as guidelines that depend on every author remembering to follow them.

The Admission Control Pipeline

Where Admission Fits in Request Processing

Every write request to the API server passes through authentication, authorization (RBAC), then admission control, before being persisted to etcd. Admission is the last checkpoint where a request can still be rejected or modified, making it the enforcement point for rules that RBAC — which only governs who can act, not what the object they submit looks like — cannot express.

Mutating vs. Validating Admission

Mutating admission webhooks run first and can modify an object before it's persisted (injecting a sidecar container, adding a default label); validating admission webhooks run afterward and can only accept or reject the object as submitted. Running mutation before validation ensures that validation rules evaluate the object's final, fully-mutated form rather than its original submitted form.

Built-In Admission Mechanisms

Pod Security Admission

Pod Security Admission, the built-in successor to the deprecated PodSecurityPolicy, enforces one of three predefined security profiles (privileged, baseline, restricted) at the namespace level via labels, rejecting or warning on Pods that violate the assigned profile's constraints — non-root enforcement, capability restrictions, host namespace usage. This is the lowest-effort, most broadly applicable mechanism for baseline container security posture and should be the default starting point before reaching for more complex custom policy.

ValidatingAdmissionPolicy

ValidatingAdmissionPolicy, evaluated in-process using CEL (Common Expression Language) expressions, allows custom validation rules without deploying and operating a separate webhook service — reducing both the latency and the operational failure surface compared to an external webhook, since there's no separate service to keep available and low-latency for every applicable API request.

Custom Policy Engines

OPA Gatekeeper and Kyverno

For policy needs beyond what built-in mechanisms cover — complex cross-resource validation, organization-specific naming and labeling standards, custom mutation logic — a dedicated policy engine (OPA Gatekeeper using Rego, or Kyverno using a more Kubernetes-native YAML policy syntax) provides a declarative, centrally managed policy layer. Kyverno is generally more approachable for teams without existing Rego expertise; Gatekeeper's Rego foundation is shared with broader OPA usage outside Kubernetes.

Common Policy Categories

Typical policies enforced this way include: requiring resource requests/limits on every container, disallowing the latest image tag, requiring images to come from an approved registry, enforcing required labels for cost allocation and ownership tracking, and disallowing privileged or host-namespace-using Pods beyond what Pod Security Admission alone captures.

Failure Mode Design

failurePolicy: Fail vs. Ignore

A webhook's failurePolicy determines what happens if the webhook itself is unreachable or errors: Fail blocks the request (safe by default, but couples cluster-wide object creation to the webhook's own availability), Ignore allows the request through unvalidated (available, but silently bypasses policy during an outage). Security-critical policies generally warrant Fail, paired with genuinely high availability for the webhook service itself so that coupling doesn't become a routine source of cluster-wide disruption.

Namespace and Object Exclusions

Webhook configurations should explicitly exclude the kube-system namespace and other control-plane-critical namespaces unless the policy is specifically intended to apply there, since an overly broad webhook scope risks blocking the cluster's own control components during an outage or bootstrap sequence — a self-inflicted failure that can be difficult to recover from if the same webhook is also what's needed to fix it.

Timeout Configuration

Webhook timeoutSeconds should be set conservatively low (the API server has its own overall admission timeout budget shared across all applicable webhooks), and the webhook service itself must be resourced and scaled to respond well within that budget, since a slow webhook degrades the latency of every API write request it applies to, not just the ones it ultimately rejects.

Rollout Strategy for New Policies

Audit Mode Before Enforcement

New policies should generally be deployed in an audit/dry-run mode first (reporting violations without blocking them) to surface how much existing traffic would be rejected, before flipping to enforcing mode — deploying a new policy directly in blocking mode risks discovering, in production, that a large fraction of legitimate existing workloads violate a rule nobody had previously measured against.

Staged Rollout by Namespace

Enforcing a new policy incrementally, namespace by namespace or team by team, rather than cluster-wide simultaneously, limits the blast radius of an unexpectedly broad policy and gives teams time to remediate violations found during the audit phase before enforcement reaches them.

Example Configuration

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-resource-limits
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
  validations:
    - expression: >
        object.spec.containers.all(c,
          has(c.resources.limits) && has(c.resources.requests))
      message: "All containers must declare resource requests and limits."
---
apiVersion: v1
kind: Namespace
metadata:
  name: codartium
  labels:
    pod-security.kubernetes.io/enforce: restricted

Practical Consequences

A well-designed admission policy layer produces a cluster where security and operational baselines are enforced automatically at the point of submission, independent of whether any individual author remembered them, and where policy violations are caught before they ever run rather than discovered later during an audit. Neglecting this layer, or deploying it carelessly with an overly broad blocking scope and no audit phase, results in either a cluster where standards exist only as documentation nobody consistently follows, or a self-inflicted outage where a misconfigured enforcing webhook blocks legitimate traffic — including, in the worst case, the traffic needed to fix the webhook itself.