Kubernetes ValidatingWebhookConfiguration

L'auteur original de cette page est Guillaume

Définition

ValidatingWebhookConfiguration est une ressource Kubernetes qui définit un webhook de validation, qui est un composant côté serveur qui valide les requêtes API Kubernetes entrantes par rapport à un ensemble de règles et de contraintes prédéfinies.

Objectif

L'objectif d'un ValidatingWebhookConfiguration est de définir un webhook de validation qui appliquera un ensemble de règles et de contraintes prédéfinies sur les requêtes API Kubernetes entrantes. Le webhook validera les requêtes par rapport aux règles et contraintes définies dans la configuration, et renverra une erreur si la requête ne respecte pas les règles.

Exemple

Voici un exemple de 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 différence entre un ValidatingWebhookConfiguration et des politiques :

Kyverno.png

• ValidatingWebhookConfiguration (VWC) : Une ressource Kubernetes qui définit un webhook de validation, qui est un composant côté serveur qui valide les requêtes API Kubernetes entrantes par rapport à un ensemble de règles et de contraintes prédéfinies.

• Kyverno ClusterPolicy : Une définition de politique qui spécifie un ensemble de règles et de contraintes pour valider et appliquer les ressources Kubernetes, telles que les pods, les déploiements et les services.

Énumération

$ kubectl get ValidatingWebhookConfiguration

Abuser de Kyverno et Gatekeeper VWC

Comme nous pouvons le voir, tous les opérateurs installés ont au moins une ValidatingWebHookConfiguration (VWC).

Kyverno et Gatekeeper sont tous deux des moteurs de politique Kubernetes qui fournissent un cadre pour définir et appliquer des politiques à travers un cluster.

Les exceptions se réfèrent à des règles ou conditions spécifiques qui permettent à une politique d'être contournée ou modifiée dans certaines circonstances, mais ce n'est pas la seule façon !

Pour kyverno, dès qu'il y a une politique de validation, le webhook kyverno-resource-validating-webhook-cfg est peuplé.

Pour Gatekeeper, il y a le fichier YAML gatekeeper-validating-webhook-configuration.

Les deux proviennent de valeurs par défaut, mais les équipes administratrices peuvent mettre à jour ces 2 fichiers.

Cas d'utilisation

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

Maintenant, identifiez la sortie suivante :

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

Ici, le label kubernetes.io/metadata.name fait référence au nom de l'espace de noms. Les espaces de noms avec des noms dans la liste values seront exclus de la politique :

Vérifiez l'existence des espaces de noms. Parfois, en raison de l'automatisation ou d'une mauvaise configuration, certains espaces de noms peuvent ne pas avoir été créés. Si vous avez la permission de créer un espace de noms, vous pourriez créer un espace de noms avec un nom dans la liste values et les politiques ne s'appliqueront pas à votre nouvel espace de noms.

L'objectif de cette attaque est d'exploiter la mauvaise configuration à l'intérieur de VWC afin de contourner les restrictions des opérateurs et ensuite d'élever vos privilèges avec d'autres techniques.

Abusing Roles/ClusterRoles in Kubernetes

Références

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

• https://kyverno.io/

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