Kubernetes Admission Plugin Management

Kubernetes Admission Plugin Management is the practice of selecting, enabling, configuring, and maintaining the built-in admission plugins compiled directly into the kube-apiserver binary, as distinct from externally registered webhooks. These plugins implement foundational cluster behaviors — resource defaulting, quota enforcement, pod security, node restriction — and because they run in-process rather than over a network call, they carry different operational characteristics and management concerns than webhook-based admission.

Enabling and Disabling Plugins

The Enable and Disable Flags

Plugins are activated through --enable-admission-plugins and deactivated through --disable-admission-plugins, and because Kubernetes ships with a version-specific default set already enabled, administrators need to consult the default list for their cluster's version before assuming a plugin's on/off state.

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

Plugins That Cannot Be Disabled

Certain plugins, such as ServiceAccount and NamespaceLifecycle, are effectively mandatory for correct cluster operation and either cannot be disabled or should never be disabled in practice, since doing so breaks fundamental cluster behaviors like automatic service account token provisioning or protection against operations on terminating namespaces.

Key Built-In Plugins and Their Purpose

NodeRestriction

Limits a kubelet's ability to modify API objects to only those related to its own node and the pods scheduled on it, preventing a compromised node from tampering with objects belonging to other nodes.

PodSecurity

Enforces the Pod Security Standards (privileged, baseline, restricted) based on labels applied to each Namespace, replacing the deprecated PodSecurityPolicy mechanism as the built-in method for enforcing pod-level security baselines.

metadata:
  labels:
    pod-security.kubernetes.io/enforce: baseline

ResourceQuota and LimitRanger

ResourceQuota enforces aggregate consumption limits within a namespace (total CPU, memory, object counts); LimitRanger enforces default and maximum values for individual objects, ensuring every container receives sensible resource requests and limits even if its manifest omits them.

apiVersion: v1
kind: LimitRange
metadata:
  namespace: payments
spec:
  limits:
  - default:
      memory: "512Mi"
      cpu: "500m"
    type: Container

MutatingAdmissionWebhook and ValidatingAdmissionWebhook

These two plugins are themselves the mechanism by which externally registered webhooks are invoked at all; disabling either one disables all webhook-based mutating or validating admission cluster-wide, making them foundational infrastructure rather than optional policy plugins.

Operational Management Practices

Version-Aware Configuration

Because the default set of enabled plugins, and occasionally plugin behavior itself, changes between Kubernetes minor versions, reviewing the admission plugin configuration as part of every cluster upgrade prevents an assumed-active plugin from silently being replaced, renamed, or defaulted differently after an upgrade.

Testing Plugin Changes in Isolation

Enabling a new plugin (or changing an existing plugin's configuration, such as ResourceQuota scope selectors) against a staging cluster first, and observing its effect on representative workloads, avoids an unexpected admission rejection or resource default appearing for the first time in production.

Ordering Awareness

Built-in plugins execute in a fixed, Kubernetes-defined order regardless of the order they appear in the enable flag; understanding this order matters when plugin effects are interdependent, such as LimitRanger needing to apply defaults before ResourceQuota evaluates consumption against them.

Auditing the Active Plugin Set

Confirming What Is Actually Enabled

kube-apiserver --help (or inspecting the running process's flags) reveals the exact set of enabled and disabled plugins for a given cluster, which should be treated as authoritative over any documentation or assumption about defaults, since defaults change across versions and cluster-specific overrides are common.

ps aux | grep kube-apiserver | grep -o -- '--enable-admission-plugins=[^ ]*'

Relationship to Webhook-Based Policy

Because MutatingAdmissionWebhook and ValidatingAdmissionWebhook are themselves plugins in this same chain, a complete picture of a cluster's admission behavior requires reviewing built-in plugin configuration and registered webhook configurations together, since neither alone represents the full enforcement surface.