Kubernetes ValidatingWebhookConfiguration

The original author of this page is Guillaume

Definition

ValidatingWebhookConfiguration is a Kubernetes resource that defines a validating webhook, which is a server-side component that validates incoming Kubernetes API requests against a set of predefined rules and constraints.

Purpose

The purpose of a ValidatingWebhookConfiguration is to define a validating webhook that will enforce a set of predefined rules and constraints on incoming Kubernetes API requests. The webhook will validate the requests against the rules and constraints defined in the configuration, and will return an error if the request does not conform to the rules.

Example

Here is an example of a ValidatingWebhookConfiguration:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: example-validation-webhook
  namespace: default
webhook:
  name: example-validation-webhook
  clientConfig:
    url: https://example.com/webhook
    serviceAccountName: example-service-account
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - "*"
    operations:
    - CREATE
    - UPDATE
    resources:
    - pods

The main difference between a ValidatingWebhookConfiguration and policies :

Kyverno.png

• ValidatingWebhookConfiguration (VWC) : A Kubernetes resource that defines a validating webhook, which is a server-side component that validates incoming Kubernetes API requests against a set of predefined rules and constraints.

• Kyverno ClusterPolicy: A policy definition that specifies a set of rules and constraints for validating and enforcing Kubernetes resources, such as pods, deployments, and services

Enumeration

$ kubectl get ValidatingWebhookConfiguration

Abusing Kyverno and Gatekeeper VWC

As we can see all operators installed have at least one ValidatingWebHookConfiguration(VWC).

Kyverno and Gatekeeper are both Kubernetes policy engines that provide a framework for defining and enforcing policies across a cluster.

Exceptions refer to specific rules or conditions that allow a policy to be bypassed or modified under certain circumstances but this is not the only way !

For kyverno, as you as there is a validating policy, the webhook kyverno-resource-validating-webhook-cfg is populated.

For Gatekeeper, there is gatekeeper-validating-webhook-configuration YAML file.

Both come from with default values but the Administrator teams might updated those 2 files.

Use Case

$ kubectl get validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg -o yaml

Now, identify the following output :

namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - default
      - TEST
      - YOYO
      - kube-system
      - MYAPP

Here, kubernetes.io/metadata.name label refers to the namespace name. Namespaces with names in the values list will be excluded from the policy :

Check namespaces existence. Sometimes, due to automation or misconfiguration, some namespaces might have not been created. If you have permission to create namespace, you could create a namespace with a name in the values list and policies won't apply your new namespace.

The goal of this attack is to exploit misconfiguration inside VWC in order to bypass operators restrictions and then elevate your privileges with other techniques

Abusing Roles/ClusterRoles in Kubernetes

References

• https://github.com/open-policy-agent/gatekeeper

• https://kyverno.io/

• https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/