native admission policy

2025-11-27 native admission policy

Overview

A guide to Kubernetes native admission policies.

Starting from Kubernetes 1.30, ValidatingAdmissionPolicy became GA (Generally Available), enabling native resource validation policies without external policy engines like Kyverno or OPA.

CEL-based Admission Policy

Kubernetes uses CEL (Common Expression Language) to write ValidatingAdmissionPolicy (VAP) and MutatingAdmissionPolicy (MAP).

---
title: How Admission Policies Work
---
flowchart LR 
    subgraph cluster["Kubernetes Cluster"]
        subgraph cp["Control Plane"]
            api["`**Pod**
            kube-apiserver`"]
            etcd["`**Pod**
            etcd`"]
        end
        map["MutatingAdmissionPolicy"]
        vap["ValidatingAdmissionPolicy"]
    end

    req["API Request"] --> api
    api --> map
    api --> vap
    api --> etcd

    style map fill:goldenrod, color:white
    style vap fill:goldenrod, color:white

Available Policy Types

Two types of native admission policies are available:

ValidatingAdmissionPolicy (VAP): Became stable in Kubernetes 1.30. Allows you to validate resources using CEL expressions.
MutatingAdmissionPolicy (MAP): Reached beta in Kubernetes 1.34. Enables resource mutation through CEL-based rules.

⚠️ Managed Kubernetes Limitation: MutatingAdmissionPolicy was alpha in Kubernetes 1.32 and became beta in Kubernetes 1.34. In managed Kubernetes services like EKS, GKE, or AKS, users do not have control over control plane feature gates, making alpha features practically unavailable until they reach beta or stable status.

Comparison with Kyverno

With ValidatingAdmissionPolicy becoming GA and MutatingAdmissionPolicy reaching beta, many ask whether they can fully replace Kyverno.

ValidatingAdmissionPolicy: Supports resource validation (GA)
MutatingAdmissionPolicy: Supports resource mutation (Beta in 1.34+)
Kyverno: Supports Validate, Mutate, Generate, VerifyImage, and Cleanup policies

While Kubernetes native admission policies now cover both validation and mutation, Kyverno still offers additional features like Generate, VerifyImage, and Cleanup policies that are not available natively.

For more details, see the related discussion on Reddit.

Helm Chart

Policy manifests are managed as a Helm chart in a separate charts repository:

younsl/charts - admission-policies

Best Practices

Policy Management

Managing all resources through Helm charts rather than directly applying YAML manifests with kubectl is a fundamental best practice for Kubernetes resource management. This practice provides significant advantages in versioning, rollback capabilities, templating, and maintaining configuration consistency across multiple clusters.

For production environments, consider adopting GitOps workflows using tools like ArgoCD or Flux. GitOps ensures that cluster state is declaratively defined in Git, enabling audit trails, peer reviews through pull requests, and automated synchronization between desired and actual cluster state.

Conclusion

For simple policies, use Kubernetes native admission policies instead of Kyverno or OPA. Native policies run inside kube-apiserver, so you don't need to install extra pods, keep them running, or worry about slow webhooks. Less stuff to manage, less stuff to break.

References

Kubernetes Documentation

Related Posts

Kyverno