Kubernetes ValidatingWebhookConfiguration

The original author of this page is Guillaume

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:

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 :

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

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

Per favore, incolla l’output da identificare.

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}}

7.6 KiB Raw Blame History Unescape Escape