Kubernetes v1.36 delivers a breakthrough for cloud native security by allowing admission policies to be defined as static manifests loaded at API server startup, preventing unauthorized deletion and ensuring consistent enforcement from cluster bootstrap onward.
- Admission policies now load from static manifest files at API server startup
- Prevents deletion or modification of critical policies via API, improving platform self-protection
- Reduces bootstrap and recovery risk by enforcing policies before serving any requests
Infrastructure signal
Kubernetes v1.36 introduces manifest-based admission control as an alpha feature to address a long-standing security and availability gap in cluster admission policy enforcement. Previously, admission policies such as ValidatingAdmissionPolicy and webhook configurations were defined and managed as API objects, which only became active after their creation. This lag created a vulnerability window during cluster bootstrap and recovery periods where policies could be absent or removed by privileged users.
By enabling admission policies and webhooks to be defined as filesystem manifests loaded by the API server at startup, this release ensures policies are enforced consistently from the moment the cluster begins serving requests. This approach also allows these policies to protect themselves, intercepting operations on admission configuration resources and preventing unauthorized deletions or modifications, which was impossible in the prior API-managed model.
Developer impact
Developers and platform engineers gain improved stability and security guarantees for their admission controls. Manifest-based policies cannot be deleted via the Kubernetes API, reducing the risk of accidental or malicious policy removals that could expose clusters to configuration drift or security breaches. Since the policies are defined locally on disk and loaded before the API server handles requests, developers can rely on immutable baseline enforcement throughout cluster lifecycle events, including bootstrap, backup restores, and disaster recovery.
The manifest format has some constraints: no references to cluster API resources, limited binding scopes within the same manifest set, and webhook URLs must be static rather than Service-based. While these introduce some trade-offs in policy flexibility, they are necessary design decisions to ensure zero dependency on cluster state, enabling resilient startup and recovery without circular webhook invocation issues.
What teams should watch
Cluster platform and security teams managing shared Kubernetes infrastructure should prioritize adopting and testing manifest-based admission policies once this feature stabilizes. It provides a mechanism to protect critical security policies from privileged user tampering and guarantees continuous enforcement after restarts or recovery workflows, enhancing overall cloud cost predictability by reducing incident-driven mitigation.
Observability improvements arise as the manifest-based policies use a distinct naming suffix ('.static.k8s.io'), allowing teams to differentiate policy decision sources in audit logs and metrics quickly. This clarity is valuable for incident diagnosis and compliance reporting, helping maintain security posture across global cloud-native environments. Teams will need to plan migration paths from existing API-defined admission policies and adjust deployment pipelines to manage policy resources as part of cluster bootstrap procedures.