Kubernetes ValidatingWebhookConfiguration
Reading time: 2 minutes
L'autore originale di questa pagina è Guillaume
Definizione
ValidatingWebhookConfiguration è una risorsa Kubernetes che definisce un webhook di validazione, che è un componente lato server che convalida le richieste API Kubernetes in arrivo rispetto a un insieme di regole e vincoli predefiniti.
Scopo
Lo scopo di un ValidatingWebhookConfiguration è definire un webhook di validazione che applicherà un insieme di regole e vincoli predefiniti sulle richieste API Kubernetes in arrivo. Il webhook convaliderà le richieste rispetto alle regole e ai vincoli definiti nella configurazione e restituirà un errore se la richiesta non è conforme alle regole.
Esempio
Ecco un esempio di un 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
La principale differenza tra un ValidatingWebhookConfiguration e le politiche :

Kyverno.png
- ValidatingWebhookConfiguration (VWC) : Una risorsa Kubernetes che definisce un webhook di validazione, che è un componente lato server che convalida le richieste API Kubernetes in arrivo rispetto a un insieme di regole e vincoli predefiniti.
- Kyverno ClusterPolicy: Una definizione di politica che specifica un insieme di regole e vincoli per convalidare e applicare le risorse Kubernetes, come pod, deployment e servizi
Enumerazione
$ kubectl get ValidatingWebhookConfiguration
Abusare di Kyverno e Gatekeeper VWC
Come possiamo vedere, tutti gli operatori installati hanno almeno una ValidatingWebHookConfiguration(VWC).
Kyverno e Gatekeeper sono entrambi motori di policy Kubernetes che forniscono un framework per definire e applicare politiche in un cluster.
Le eccezioni si riferiscono a regole o condizioni specifiche che consentono a una politica di essere bypassata o modificata in determinate circostanze, ma questo non è l'unico modo!
Per kyverno, poiché esiste una politica di validazione, il webhook kyverno-resource-validating-webhook-cfg
è popolato.
Per Gatekeeper, c'è il file YAML gatekeeper-validating-webhook-configuration
.
Entrambi provengono con valori predefiniti, ma i team di amministratori potrebbero aver aggiornato questi 2 file.
Caso d'uso
$ kubectl get validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg -o yaml
Ora, identifica il seguente output:
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: NotIn
values:
- default
- TEST
- YOYO
- kube-system
- MYAPP
Qui, l'etichetta kubernetes.io/metadata.name
si riferisce al nome del namespace. I namespace con nomi nella lista values
saranno esclusi dalla policy:
Controlla l'esistenza dei namespace. A volte, a causa di automazione o misconfigurazione, alcuni namespace potrebbero non essere stati creati. Se hai il permesso di creare un 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 misconfigurazione all'interno del VWC per eludere le restrizioni degli operatori e poi elevare i tuoi privilegi con altre tecniche.
Abusing Roles/ClusterRoles in Kubernetes