Kyverno Wildcard Guardrail Behavior Anomaly
Kyverno, a widely-used Kubernetes policy engine, exhibited unexpected behavior in version v1.19.1 concerning wildcard matching for DELETE operations on Custom Resource Definitions (CRDs). Specifically, a wildcard guardrail configured with kinds: ["*/*"] and operations: [DELETE] failed to trigger for post-policy CRDs. This meant that custom resources defined by these post-policy CRDs could be deleted without triggering the intended policy enforcement. The anomaly persisted until the Kyverno admission controller was restarted.
This behavior was observed during testing as part of the "When It Runs" series, specifically in Run Report #RR05. The testing focused on Kyverno's cluster-wide wildcard matching capabilities and the internal policy cache mechanism within the admission controller. The version under scrutiny was Kyverno v1.19.1, released on September 10, 2026, and confirmed as current on September 13, 2026. The installation was performed using the official Helm chart kyverno/kyverno version 3.9.1, pulling the admission-controller image reg.kyverno.io/kyverno/kyverno:v1.19.1.
In contrast, pre-policy CRDs behaved as expected. DELETE operations on resources managed by pre-policy CRDs were correctly denied by the wildcard guardrail both before and after the admission controller restart, indicating the issue was specific to the timing and nature of post-policy CRDs within the Kyverno processing pipeline.
Technical Details of the Anomaly
The core of the problem lies in the interaction between Kyverno's crdWatcher, its policy cache, and the handling of admission requests for post-policy CRDs. When a DELETE request arrives for a resource associated with a post-policy CRD, Kyverno's admission controller, with the crdWatcher enabled, was not correctly identifying or matching the active wildcard policy. The error message observed was "no policies matched admission request". This suggests that the policy lookup mechanism, particularly for dynamically discovered CRDs (post-policy CRDs), was failing to engage the relevant wildcard guardrail.
Post-policy CRDs are defined after Kyverno itself is installed. This means that when Kyverno starts, it might not initially be aware of these CRDs or their associated resources. The crdWatcher is designed to detect these new CRDs and update Kyverno's internal state to include them in policy evaluations. However, in this specific scenario with wildcard DELETE policies, the watcher's update mechanism or the subsequent policy matching logic was apparently not robust enough to incorporate the new CRD's resources into the wildcard's scope until a full restart forced a re-initialization of the admission controller and its caches.
The fact that pre-policy CRDs were unaffected is a crucial distinction. Pre-policy CRDs are present in the cluster when Kyverno starts. Therefore, their resources are known to the admission controller from the outset, and wildcard policies can be applied consistently. The failure to apply to post-policy CRDs points to a timing issue or a bug in how Kyverno dynamically integrates newly discovered CRD resources into its wildcard policy evaluation context.
Implications for Cluster Administrators and Security
This bug has significant implications for organizations relying on Kyverno for enforcing deletion policies across their Kubernetes clusters. The inability of wildcard guardrails to prevent the deletion of sensitive resources defined by post-policy CRDs creates a security loophole. Attackers or even accidental user actions could lead to the removal of critical infrastructure components, application data, or configuration settings without triggering any alerts or blocks.
The requirement for a restart to rectify the issue is particularly problematic. In a live, dynamic Kubernetes environment, restarting the admission controller is a disruptive operation. It requires careful planning and can lead to brief periods where admission control is unavailable, potentially impacting cluster stability and availability. For security teams, this means a constant risk exposure for any post-policy CRDs until an administrator manually intervenes by restarting the controller. This is not a sustainable or secure operational posture.
The unexpected resilience of pre-policy CRDs to this bug, while post-policy CRDs are vulnerable, suggests that the issue is not with the wildcard matching logic itself, but rather with how dynamically registered CRD information is processed and integrated into the active policy evaluation set. This could be related to event handling for CRD updates or the refresh cycle of the policy cache.
What Remains Unanswered
While the specific version and conditions leading to this failure are documented, the precise root cause within Kyverno's admission controller code remains unaddressed in the provided information. Understanding whether this is a race condition, a flaw in the crdWatcher's event handling, or an issue with how the policy cache invalidates and repopulates for newly discovered CRD types is crucial for a complete fix. Furthermore, the long-term impact on Kyverno's ability to enforce policies dynamically on all types of CRDs, especially in large, rapidly evolving clusters, warrants further investigation. What happens to the performance and accuracy of wildcard policies as the number of CRDs and custom resources grows significantly over time?