Looking at Kubernetes’ Admission Webhook and Kyverno’s policy management structure, some resources cannot be validated or modified by Kyverno policies. The prime examples are ValidatingWebhookConfiguration and MutatingWebhookConfiguration.
This article deeply explores the reasons for this phenomenon, why such a design is necessary, and what practical alternatives can be considered.
https://kyverno.io/docs/introduction/how-kyverno-works/
𧩠First, what is an Admission Controller?
All requests entering the Kubernetes API server go through several stages.
Typically, these processes include:
- Authentication β Who made the request?
- Authorization β Is the request allowed?
- Admission Control β Can the request content be modified (mutated) or validated?
The Admission Controller stage has two important subsystems:
- Mutating Admission Webhook: Can “mutate” requested resources
- Validating Admission Webhook: “Validates” the validity of requested resources
π In other words, from the API server’s perspective, when a resource is created or updated, it calls an external webhook to ask, “Is this resource okay?” or “Should I fill in the necessary fields?”
π§ What is Kyverno?
Kyverno is a Kubernetes-native policy engine that controls resources in three ways:
- Validation Policy: Validates whether resources adhere to cluster policies
- Mutation Policy: Automatically modifies resource requests
- Generation Policy: Creates other resources when specific events occur
Kyverno internally operates as an Admission Webhook.
That is, Kyverno itself registers separate MutatingWebhookConfiguration and ValidatingWebhookConfiguration resources, inserting itself into the flow of all resource requests.
π« But the problem: Kyverno cannot manage Kyverno’s webhooks?
This is where the “circular dependency” problem arises.
In the Kubernetes Admission stage, for specific resource types, namely
ValidatingWebhookConfiguration and MutatingWebhookConfiguration resources,
Admission Webhook calls are skipped.
In other words, the API server does not send webhook-related resources to another webhook.
The reason is simple but very important.
βοΈ Design Reason: Preventing Circular Webhook Invocation
If an Admission Webhook configuration itself could be validated or modified by another Admission Webhook, situations like this could occur:
- Kyverno tries to modify a new webhook configuration
- But that action itself triggers another Kyverno webhook call
- As a result, the webhook call continuously triggers itself
- Ultimately leading to an infinite recursion π₯
Kubernetes designers prevented this by designing the API server not to forward ValidatingWebhookConfiguration and MutatingWebhookConfiguration resource requests to webhooks.
That is, these two resources are completely exception-handled at the Admission stage.
Consequently, Kyverno cannot even “see” these resources.
π Security Reasons Also Exist
From a security perspective, this decision is also very important.
If an Admission Webhook could modify other webhook configurations, it would create a possibility for injecting malicious configurations.
For example, if an attacker could automatically create their own webhook through Kyverno policies or another MutatingWebhook, it would be possible to intercept all API requests to the cluster.
This could lead to vulnerabilities at the level of Cluster compromise.
Therefore, preventing such “self-mutation” at the source is a core design philosophy for maintaining system stability and security.
π How does it actually work?
When you actually create or modify a MutatingWebhookConfiguration with kubectl apply, the kube-apiserver performs only the following steps:
- Performs basic schema validation before etcd storage
- Checks the list of registered Admission Webhooks (skips calls for MutatingWebhookConfiguration, ValidatingWebhookConfiguration types)
- Commits the resource to etcd
During this process, Kyverno does not get an opportunity to observe or modify this request.
Looking at Kyverno’s logs, other resources (Deployment, Pod etc.) appear as webhook requests,
but WebhookConfiguration-related events are not detected at all.
𧩠So, is it completely impossible to control with policies?
It’s impossible with Kyverno alone. However, there are alternatives.
β Method 1: Use an External Admission Controller
You can implement your own Admission Webhook to monitor WebhookConfiguration resources. However, due to K8s’ inherent design, “blocking changes” is not possible, and it is limited to audit-only purposes.
β Method 2: Controller-level Monitoring
Instead of Kyverno, a Controller or Operator can monitor events after kube-apiserver stores them in etcd, and immediately mitigate any detected inappropriate Webhook configurations.
Example: Building a “webhook-config watcher” with a Go application based on Controller Runtime, Kubernetes Informer.
β Method 3: Protect with RBAC
This is the most practical and secure method.
Since MutatingWebhookConfiguration and ValidatingWebhookConfiguration resources are ClusterScope objects, access control for administrators should be applied by minimizing the permissions (Role, ClusterRole) that can edit them.
β οΈ Caution for DevOps Operations
When operating a cluster and using Kyverno as an automation tool in a CI/CD pipeline, you may occasionally see the following error:
text
Error: Policy cannot be applied to resource type MutatingWebhookConfiguration
In this case, it’s not a problem but normal behavior π
Kyverno is ignoring restricted resources as designed, and you should not try to force changes.
π‘ In summary
ItemDescriptionKyverno Policy Application Status
| Deployment / Pod | General Resource | β Possible |
|---|---|---|
| Namespace | General Cluster Resource | β Possible |
| CustomResourceDefinition (CRD) | Resource Definition | β οΈ Restricted (Special configuration required) |
| MutatingWebhookConfiguration | Admission System Configuration | β Impossible |
| ValidatingWebhookConfiguration | Admission System Configuration | β Impossible |
—
π Conclusion: Separation of Trust over Control
Kubernetes’ core philosophy emphasizes “Separation of Trust” more than “Control.”
Since Admission Webhooks intervene in the heart of the cluster, if another Webhook were to control or validate this component, it could threaten the system’s integrity.
Therefore, Kyverno’s inability to manage Webhook configuration resources is not merely a limitation,
but an essential defense line for system stability and security.
Leave a Reply