Kubernetes Admission Manifest Management

Kubernetes Admission Manifest Management is the practice of defining and maintaining every admission-related object — MutatingWebhookConfiguration, ValidatingWebhookConfiguration, ValidatingAdmissionPolicy, ValidatingAdmissionPolicyBinding, parameter custom resources, and third-party policy engine rules — as version-controlled declarative manifests, applying the same infrastructure-as-code discipline to policy configuration that is applied to application workloads.

Organizing Admission Manifests

Repository Structure

A common structure separates admission manifests by concern — webhook configurations, ValidatingAdmissionPolicy definitions, and policy-engine-specific constraints — often in a dedicated platform or policy repository distinct from application manifests, reflecting that these objects are typically owned and reviewed by a different set of people than application teams.

admission/
  webhooks/
    mutating/
      sidecar-injector.yaml
    validating/
      image-provenance.yaml
  validating-admission-policies/
    require-resource-limits.yaml
    require-resource-limits-binding.yaml
  gatekeeper-constraints/
    require-team-label.yaml

Co-Locating Related Objects

Grouping a policy and its bindings, or a webhook configuration and its parameter resources, in the same file or adjacent files keeps the full picture of a single policy's behavior reviewable in one place, rather than requiring a reviewer to cross-reference several separate files scattered throughout the repository.

Review and Change Control

Requiring Elevated Review for Admission Changes

Because admission manifests govern what every workload in the cluster is permitted to do, changes to them — particularly failurePolicy settings, validationActions, and rule scoping — warrant a review process at least as rigorous as RBAC manifest changes, often requiring sign-off from a dedicated platform or security team rather than the team whose workloads happen to be affected.

Diffing Policy Changes Clearly

A pull request modifying an admission manifest should make the practical effect of the change legible in the diff itself — a change from Audit to Deny, a widened matchResources selector, a new exemption — since these changes can silently expand or contract enforcement scope in ways that are easy to overlook in a large diff.

Applying and Reconciling Manifests

GitOps-Driven Application

Continuously reconciling admission manifests from a Git repository, the same way application manifests are managed, ensures that any direct, out-of-band modification to a webhook configuration or policy object made against the live cluster is detected and corrected, keeping the repository as the authoritative source of truth for enforcement configuration.

kubectl apply -f admission/ --prune -l app.kubernetes.io/managed-by=gitops

Managing Apply Order and Dependencies

Because a ValidatingAdmissionPolicyBinding depends on its referenced ValidatingAdmissionPolicy already existing, and a parameter resource depends on its CustomResourceDefinition being registered, manifest management tooling needs to apply objects in the correct dependency order, or rely on a reconciliation tool that retries until dependencies are satisfied.

Validating Manifests Before Deployment

Schema and Dry-Run Validation

Running every admission manifest through kubectl apply --dry-run=server in a CI pipeline catches schema errors, invalid CEL expressions, and structural mistakes before they reach a live cluster, providing the same safety net for policy manifests that build and test pipelines provide for application code.

kubectl apply --dry-run=server -f admission/validating-admission-policies/

Policy-of-Policies Checks

Some organizations layer a meta-policy over their admission manifests themselves — for example, requiring every ValidatingWebhookConfiguration to set an explicit failurePolicy rather than relying on a default, or requiring every new policy to include a namespaceSelector excluding system namespaces — catching common configuration mistakes automatically rather than relying on manual reviewer vigilance for every change.

Lifecycle and Cleanup

Removing Deprecated Policies Cleanly

When a policy is retired, removing its manifest from the source repository and allowing the GitOps reconciliation process to delete the corresponding cluster objects avoids the common failure mode of a policy being disabled informally (by removing its binding, for instance) while its underlying definition and any associated parameter resources are left behind indefinitely.

Tracking Manifest History as an Audit Trail

Because every admission manifest change is recorded in version control with an associated author, timestamp, and review record, the repository's commit history becomes a durable audit trail of the cluster's enforcement posture over time, complementing the runtime audit logs that record individual admission decisions.