# Kubernetes ValidatingWebhookConfiguration

{{#include ../../banners/hacktricks-training.md}}

**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

## Definizione

`ValidatingWebhookConfiguration` è una risorsa di Kubernetes che registra uno o più validating admission webhooks. Questi webhooks ricevono richieste AdmissionReview dal API server dopo authentication e authorization, ma prima che l'oggetto venga persistito.

I validating webhooks possono rifiutare una richiesta. I mutating webhooks, configurati con `MutatingWebhookConfiguration`, possono prima modificare l'oggetto. Le security review dovrebbero di solito ispezionare entrambe le risorse perché un mutating webhook malevolo o debole può riscrivere i workload, mentre un validating webhook o un policy engine può bloccarli o consentirli.

## Scopo

Lo scopo di un `ValidatingWebhookConfiguration` è definire quando il API server dovrebbe chiamare un validating webhook e come dovrebbe gestire il risultato del webhook. La domanda di sicurezza importante non è solo "è installata una policy?", ma anche:

- Quali API groups, resources, operations e scopes corrisponde?
- Quali namespaces o oggetti sono esclusi dai selector?
- `matchConditions` salta qualche classe di richiesta?
- `failurePolicy` fallisce aperto con `Ignore` o fallisce chiuso con `Fail`?
- Il servizio webhook è raggiungibile, trusted dal `caBundle` configurato e viene eseguito da un service account con privilegi elevati?
- Il policy engine espone anche exception resources, excluded users o excluded groups?

**Esempio**

Ecco un esempio di un ValidatingWebhookConfiguration:
```yaml
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: example-validation-webhook
webhooks:
- name: pods.example.local
admissionReviewVersions: ["v1"]
sideEffects: None
failurePolicy: Fail
timeoutSeconds: 5
clientConfig:
service:
namespace: webhook-system
name: example-validation-webhook
path: /validate
caBundle: <base64-ca-bundle>
rules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["pods"]
scope: "Namespaced"
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values: ["kube-system"]
```
La differenza principale tra una ValidatingWebhookConfiguration e i policies :

<figure><img src="../../images/Kyverno.png" alt=""><figcaption><p>Kyverno.png</p></figcaption></figure>

- **ValidatingWebhookConfiguration (VWC)** : Una risorsa Kubernetes che definisce un validating webhook, cioè un componente lato server che valida le richieste Kubernetes API in ingresso rispetto a un insieme di regole e vincoli predefiniti.
- **Kyverno ClusterPolicy**: Una definizione di policy che specifica un insieme di regole e vincoli per validare e applicare la enforcement delle risorse Kubernetes, come pod, deployment e services

## Enumeration
```
$ kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations
$ kubectl get validatingwebhookconfiguration <name> -o yaml
$ kubectl get mutatingwebhookconfiguration <name> -o yaml
$ kubectl get svc,deploy,pod -A | grep -i webhook
```
Fields to inspect:

- `rules`: Controlla API groups, versions, resources, subresources, operations e scope coperti.
- `namespaceSelector` / `objectSelector`: Cerca namespaces o labels che escludono risorse dalla policy.
- `matchConditions`: Le espressioni CEL possono saltare richieste intenzionalmente o per errore.
- `failurePolicy`: `Ignore` lascia proseguire le richieste se il webhook fallisce; `Fail` le blocca.
- `sideEffects`: I webhook con side effects potrebbero non supportare il testing dry-run.
- `timeoutSeconds`: Timeout molto brevi combinati con `Ignore` possono diventare comportamento fail-open.
- `clientConfig`: Verifica se il webhook punta a un Service in-cluster o a un URL esterno, e ispeziona il workload di supporto e il service account.
- `reinvocationPolicy`: I mutating webhooks possono essere reinvocati quando una mutation successiva cambia l'oggetto.

### Abusing Kyverno and Gatekeeper VWC

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

**Kyverno** e **Gatekeeper** sono entrambi Kubernetes policy engines che forniscono un framework per definire e applicare policy su un cluster.

Le exceptions si riferiscono a regole o condizioni specifiche che permettono di bypassare o modificare una policy in determinate circostanze, ma non è questo l'unico modo !

Per **kyverno**, come si vede, dato che c'è una validating policy, il webhook `kyverno-resource-validating-webhook-cfg` viene popolato.

Per Gatekeeper, c'è il file YAML `gatekeeper-validating-webhook-configuration`.

Entrambi partono con valori predefiniti, ma i team Administrator potrebbero aver aggiornato questi 2 file.

### Use Case
```bash
$ kubectl get validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg -o yaml
```
Per favore, incolla l’output da identificare.
```yaml
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- default
- TEST
- YOYO
- kube-system
- MYAPP
```
Qui, `kubernetes.io/metadata.name` si riferisce al label del nome del namespace. I namespace con nomi nella lista `values` saranno esclusi dalla policy:

Verifica l'esistenza dei namespace. A volte, a causa di automation o misconfiguration, alcuni namespace potrebbero non essere stati creati. Se hai il permesso di creare namespace, potresti creare un namespace con un nome nella lista `values` e le policy non si applicheranno al tuo nuovo namespace.

L'obiettivo di questo attacco è sfruttare la **misconfiguration** all'interno di VWC per bypassare le restrizioni degli operatori e poi elevare i tuoi privilegi con altre tecniche

Altri pattern comuni di bypass o abuse:

- Un `objectSelector` che permette agli utenti di aggiungere un label opt-out ai propri oggetti.
- `failurePolicy: Ignore` su validazione security-critical, specialmente quando il webhook Service non ha endpoints o il networking è unreliable.
- Eccezioni del policy engine per users, groups, service accounts, namespaces o roles più ampie del previsto.
- Copertura mancante per template di workload controller, `pods/ephemeralcontainers`, `pods/exec`, custom resources o operazioni di update.
- Accesso in scrittura a `validatingwebhookconfigurations`, `mutatingwebhookconfigurations`, restrizioni di Gatekeeper, policy di Kyverno o risorse di eccezione.
- Un mutating webhook malevolo che inietta containers, cambia immagini, monta secrets, aggiunge tolerations o modifica la selezione del service account prima della validation.

Ricorda che admission protegge solo le richieste che passano attraverso la catena di admission dell'API server. Static Pods, accesso al runtime socket locale del node, abuso diretto di kubelet e accesso diretto a etcd sono diversi trust paths e richiedono hardening e monitoring separati.

{{#ref}}
abusing-roles-clusterroles-in-kubernetes/
{{#endref}}

## References

- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
- [https://kyverno.io/](https://kyverno.io/)
- [https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)
- [https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/](https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/)
- [https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)



{{#include ../../banners/hacktricks-training.md}}