# Kubernetes v1.36: Admission Policies That Can't Be Deleted

DevFeed: [Kubernetes v1.36: Admission Policies That Can't Be Deleted](<https://devfeed.tech/articles/kubernetes-v1-36-admission-policies-that-can-t-be-deleted-4545.md>)

Original publisher: [Read original article](<https://kubernetes.io/blog/2026/05/04/kubernetes-v1-36-manifest-based-admission-control/>)

Author: Anish Ramasekar; Benjamin Elder

Published: 2026-05-04T18:35:00Z

Content type: article

Language: en

Sources: [Kubernetes Blog](<https://devfeed.tech/sources/kubernetes-blog.md>)

Topics: [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Security](<https://devfeed.tech/topics/security.md>), [configuration](<https://devfeed.tech/topics/configuration.md>), [API](<https://devfeed.tech/topics/api.md>), [Authorization](<https://devfeed.tech/topics/authorization.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [manifest](<https://devfeed.tech/tags/manifest.md>), [operations](<https://devfeed.tech/tags/operations.md>), [policy](<https://devfeed.tech/tags/policy.md>), [resources](<https://devfeed.tech/tags/resources.md>), [security](<https://devfeed.tech/tags/security.md>), [server](<https://devfeed.tech/tags/server.md>)

## AI overview

Kubernetes v1.36 introduces an alpha manifest-based admission control feature. Admission webhooks and CEL-based policies can be stored as files, loaded by the API server at startup, and applied before it serves requests. The approach addresses bootstrap gaps and helps prevent privileged users from deleting critical admission configuration.

## Source excerpt

If you've ever tried to enforce a security policy across a fleet of Kubernetes clusters, you've probably run into a frustrating chicken-and-egg problem. Your admission policies are API objects, which means they don't exist until someone creates them, and they can be deleted by anyone with the right permissions. There's always a window during cluster bootstrap where your policies aren't active yet, and there's no way to prevent a privileged user from removing them. Kubernetes v1.36 introduces an alpha feature that addresses this: manifest-based admission control. It lets you define admission webhooks and CEL-based policies as files on disk, loaded by the API server at startup, before it serves any requests. The gap we're closing Most Kubernetes policy enforcement today works through the API. You create a ValidatingAdmissionPolicy or a webhook configuration as an API object, and the admission controller picks it up. This works well in steady state, but it has some fundamental limitations. During cluster bootstrap, there's a gap between when the API server starts serving requests and when your policies are created and active. If you're restoring from a backup or recovering from an etcd failure, that gap can be significant. There's also a self-protection problem. Admission webhooks and policies can't intercept operations on their own configuration resources. Kubernetes skips invoking webhooks on types like ValidatingWebhookConfiguration to avoid circular dependencies. That means a sufficiently privileged user can delete your critical admission policies, and there's nothing in the admission chain to stop them. We - Kubernetes SIG API Machinery - wanted a way to say "these policies are always on, full stop." How it works You add a staticManifestsDir field to the AdmissionConfiguration file that you already pass to the API server via --admission-control-config-file. Point it at a directory, drop your policy YAML files in there, and the API server loads them before it start