Enforcing security policies across a fleet of Kubernetes clusters often presents a significant operational challenge. Administrators frequently encounter a frustrating chicken-and-egg problem where admission policies are API objects that do not exist until created, leaving a window of vulnerability during cluster bootstrap. Furthermore, there is no mechanism to prevent a privileged user from deleting these policies once they are active. Kubernetes v1.36 addresses these critical gaps by introducing an alpha feature known as manifest-based admission control. This capability allows you to define admission webhooks and CEL-based policies as files on disk, which the API server loads at startup before serving any requests.
Eliminating the Bootstrap Gap
Current Kubernetes policy enforcement relies heavily on the API. You typically create a ValidatingAdmissionPolicy or a webhook configuration as an API object, and the admission controller picks it up dynamically. While this approach functions well in a steady-state environment, it introduces fundamental limitations during critical moments. Specifically, there is a distinct gap between when the API server starts serving requests and when your policies are created and become active. If you are restoring from a backup or recovering from an etcd failure, this gap can be significant, potentially allowing unauthorized operations to slip through before your safeguards are in place.
The new manifest-based approach fundamentally changes this workflow. Instead of creating policy objects via the API, you place configuration files in a designated directory. When the API server initializes, it scans these files and loads the defined webhooks and policies immediately. This ensures that your security posture is established from the very first request, effectively closing the window of opportunity for attackers or misconfigurations during the cluster initialization phase.
Self-Protection and Circular Dependencies
A second major limitation in the existing architecture is the self-protection problem. Admission webhooks and policies cannot intercept operations on their own configuration resources. Kubernetes explicitly skips invoking webhooks on types like ValidatingWebhookConfiguration to avoid circular dependencies. This means that if an attacker or a compromised process attempts to modify the webhook configuration itself, the webhook cannot block the request because it is not yet active or is being bypassed by design.
Manifest-based admission control mitigates this risk by decoupling the policy definition from the API object lifecycle. By loading policies from disk, the system establishes a baseline of trust that is independent of the API's current state. This architectural shift ensures that even if an attacker gains access to the API server, they cannot easily disable the admission controls by manipulating the API objects, as the controls are derived from immutable file sources loaded at boot time.
Operational Implications for Engineers
For DevOps professionals and cloud engineers preparing for certifications like the Kubernetes certifications, understanding this shift is crucial. The transition from dynamic API objects to static manifest files represents a move toward more robust and predictable security architectures. This feature is particularly relevant for organizations managing large-scale fleets where consistency and immediate enforcement are paramount.
When implementing this feature, you must ensure that your file management strategy is secure. The files loaded by the API server should be stored in a location with restricted permissions, accessible only to the API server process. Additionally, you should consider version control integration to track changes to these manifests, ensuring that any updates to admission policies are auditable and reproducible.
While this feature is currently in alpha, it signals a significant direction for Kubernetes security. As the feature matures, it will likely become the standard for policy enforcement, rendering the traditional API-based method obsolete for critical security controls. Engineers should begin experimenting with manifest-based configurations in non-production environments to understand the operational overhead and benefits.
What This Means For You
The introduction of manifest-based admission control in Kubernetes v1.36 marks a pivotal moment for cluster security. It resolves the inherent latency and vulnerability associated with API-based policy creation. By defining policies as files, you gain immediate enforcement capabilities and protection against self-modification attacks. As you plan your cluster upgrades, consider how this feature aligns with your security compliance requirements and operational procedures. Staying ahead of these architectural changes will ensure your infrastructure remains resilient against evolving threats.