Kubernetes Admission and Policy

Kubernetes Admission and Policy is the stage of request processing that runs after authentication and authorization have already approved a request, but before it is persisted to etcd, during which the cluster can validate, modify, or reject the object being created or updated based on rules that go beyond simple identity-based access control. Where RBAC answers "is this identity allowed to perform this verb on this resource type," admission and policy answer "does this specific object satisfy the organization's requirements," enabling governance over the shape and content of cluster configuration itself.

The Admission Control Pipeline

Position in the Request Lifecycle

A request that has already passed authentication and authorization proceeds through a defined pipeline: mutating admission controllers run first, potentially altering the object; the modified object is validated against the API schema; validating admission controllers then run, which may reject the request outright; only after all of this succeeds is the object persisted to etcd.

Built-in Admission Controllers

The API server ships with a set of built-in admission controllers that can be enabled or disabled by cluster operators, covering common concerns such as ResourceQuota enforcement, LimitRanger default injection, NamespaceLifecycle protection against operating in terminating namespaces, and DefaultStorageClass assignment for PersistentVolumeClaims that omit one.

Webhook-Based Admission

Mutating Admission Webhooks

A mutating admission webhook is an external HTTP service the API server calls during the mutating phase, capable of modifying the incoming object before it proceeds further, commonly used to inject default resource requests, sidecar containers, or standardized labels without requiring every manifest author to include them manually.

Validating Admission Webhooks

A validating admission webhook is called during the validating phase and can only accept or reject a request, optionally with a human-readable reason, used to enforce organizational policy such as requiring specific labels, disallowing privileged containers, or rejecting images from untrusted registries.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: codartium-image-policy
webhooks:
  - name: trusted-registry.codartium.io
    rules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
    clientConfig:
      service:
        name: image-policy-webhook
        namespace: codartium-security
        path: /validate
    failurePolicy: Fail
    admissionReviewVersions: ["v1"]
    sideEffects: None

Failure Policy

The failurePolicy field determines what happens if a webhook is unreachable or times out: Fail rejects the request, prioritizing policy enforcement over availability, while Ignore allows the request through, prioritizing cluster availability over strict enforcement, a tradeoff that must be chosen deliberately for each policy's risk profile.

Policy-as-Code Engines

Open Policy Agent and Gatekeeper

Open Policy Agent (OPA) is a general-purpose policy engine using the Rego language to express policy rules; Gatekeeper packages OPA as a Kubernetes-native admission controller, allowing policies to be defined declaratively as ConstraintTemplate and Constraint custom resources rather than as standalone webhook services that must be built and deployed independently.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-team-label
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["team"]

Kyverno

Kyverno is a policy engine designed specifically for Kubernetes, expressing policies as native YAML resources rather than a separate policy language, supporting validation, mutation, and image verification rules directly against the familiar structure of Kubernetes manifests.

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

ValidatingAdmissionPolicy

In-Process Policy Evaluation

ValidatingAdmissionPolicy allows validation rules to be expressed using the Common Expression Language (CEL) directly within the API server, evaluated in-process rather than through an external webhook call, reducing latency and eliminating the availability dependency on a separate policy service for the covered rules.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-non-root
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
  validations:
    - expression: "object.spec.securityContext.runAsNonRoot == true"
      message: "Pods must run as a non-root user."

Common Policy Domains

Security Hardening

Policies frequently enforce that containers do not run as root, do not request privilege escalation, drop unnecessary Linux capabilities, and use read-only root filesystems, translating an organization's security baseline into automatically enforced, unbypassable constraints on every Pod created in the cluster.

Resource and Cost Governance

Policies can require every workload to declare resource requests and limits, restrict which StorageClasses or node pools may be used, or cap the size of PersistentVolumeClaims a team may request, tying policy enforcement directly to cost and capacity management goals.

Compliance and Labeling

Policies can require specific labels or annotations, such as a cost center, data classification, or environment tag, on every object, ensuring downstream tooling that depends on that metadata, billing reports, backup schedules, compliance audits, always has the information it needs.

kubectl get validatingwebhookconfigurations
kubectl get constrainttemplates
kubectl get clusterpolicies

Testing and Rollout of Policy

Because a misconfigured validating policy can block legitimate workloads cluster-wide, policy engines commonly support a dry-run or audit mode, reporting violations without rejecting requests, allowing new policies to be evaluated against real cluster traffic before being switched to enforcing mode.