Kubernetes ValidatingWebhookConfiguration

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, non appena c'è una politica di validazione, il webhook kyverno-resource-validating-webhook-cfg viene popolato.

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

Entrambi provengono con valori predefiniti, ma i team di amministrazione 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

Riferimenti

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

• https://kyverno.io/

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