Kubernetes Admission Control Management

Kubernetes Admission Control Management is the operational practice of configuring, enabling, monitoring, and evolving the admission plugins and webhooks that intercept API requests after authorization but before persistence. It covers choosing which built-in plugins to enable on the API server, registering and maintaining external webhook configurations, and ensuring the overall admission chain remains available, correct, and understandable as the cluster and its policy requirements grow.

Configuring the Admission Plugin Chain

Enabling and Disabling Plugins

The API server's admission chain is configured through --enable-admission-plugins and --disable-admission-plugins, and because certain plugins are enabled by default, an administrator managing admission control needs to know the effective default set for the cluster's Kubernetes version before assuming a given plugin is active or inactive.

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

Plugin Ordering

Admission plugins execute in a fixed internal order determined by Kubernetes itself, not by the order flags are listed; understanding this ordering matters when plugins interact — for instance, LimitRanger setting default resource values must run before ResourceQuota evaluates consumption against those defaults for the change to be reflected correctly.

Managing Webhook-Based Admission

Registering Webhook Configurations

MutatingWebhookConfiguration and ValidatingWebhookConfiguration objects are themselves cluster resources, meaning their creation, modification, and removal should go through the same reviewed, version-controlled process as any other identity or policy-relevant object, given their direct effect on which objects the cluster accepts.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: image-provenance
webhooks:
- name: provenance.supplychain.example.com
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    operations: ["CREATE"]
    resources: ["pods"]
  clientConfig:
    service:
      name: provenance-checker
      namespace: supply-chain
      path: /validate
  admissionReviewVersions: ["v1"]
  sideEffects: None
  timeoutSeconds: 5
  failurePolicy: Fail

Timeout and Failure Policy Tuning

Every webhook has a timeoutSeconds setting bounding how long the API server waits for a response, and a failurePolicy determining behavior if the webhook is unreachable or times out; setting these appropriately balances strict enforcement against the availability risk of the API server's request path depending on an external service's uptime.

Operating the Admission Layer Reliably

Monitoring Webhook Health

Because a failing or slow admission webhook directly affects every matching API request cluster-wide, admission control management includes monitoring webhook service latency and error rates as a first-class operational concern, not merely a concern of the team that owns the policy logic itself.

Staged Rollout of New Policies

Introducing a new validating webhook with failurePolicy: Ignore and dryRun-style logging initially, then tightening to Fail once confidence in the policy's correctness is established, avoids an untested policy unexpectedly blocking legitimate production traffic the moment it is registered.

Avoiding Circular Dependencies

A webhook service that itself runs as a pod in the cluster it polices can create a bootstrapping problem if the webhook's own namespace is subject to its enforcement; excluding the webhook's own namespace via namespaceSelector, or ensuring the webhook service does not depend on the very admission chain it participates in, avoids this circularity.

namespaceSelector:
  matchExpressions:
  - key: kubernetes.io/metadata.name
    operator: NotIn
    values: ["supply-chain"]

Auditing and Change Management

Enumerating the Active Chain

kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations combined with the API server's configured built-in plugin list gives the complete picture of what currently participates in admission control, which should be periodically reconciled against what is actually intended to be enforced.

Testing Changes Before Production

Applying admission configuration changes to a staging cluster first, and exercising representative request patterns against it, catches unintended rule-matching overlap or performance regressions before the change reaches a production API server's request path.

Versioning Admission Review Payloads

Webhook configurations declare which admissionReviewVersions they support; keeping this aligned with the versions the API server can send, and updating it deliberately during Kubernetes version upgrades, prevents a webhook from silently failing to receive requests it expects to intercept after a cluster upgrade.