Kubernetes ValidatingWebhookConfiguration

O autor original desta página é Guillaume

Definição

ValidatingWebhookConfiguration é um recurso do Kubernetes que define um webhook de validação, que é um componente do lado do servidor que valida as solicitações da API do Kubernetes recebidas contra um conjunto de regras e restrições predefinidas.

Propósito

O propósito de um ValidatingWebhookConfiguration é definir um webhook de validação que aplicará um conjunto de regras e restrições predefinidas nas solicitações da API do Kubernetes recebidas. O webhook validará as solicitações de acordo com as regras e restrições definidas na configuração e retornará um erro se a solicitação não estiver em conformidade com as regras.

Exemplo

Aqui está um exemplo de um 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

A principal diferença entre um ValidatingWebhookConfiguration e políticas :

Kyverno.png

• ValidatingWebhookConfiguration (VWC) : Um recurso do Kubernetes que define um webhook de validação, que é um componente do lado do servidor que valida as solicitações da API do Kubernetes recebidas contra um conjunto de regras e restrições predefinidas.

• Kyverno ClusterPolicy: Uma definição de política que especifica um conjunto de regras e restrições para validar e impor recursos do Kubernetes, como pods, implantações e serviços

Enumeração

$ kubectl get ValidatingWebhookConfiguration

Abusando do Kyverno e do Gatekeeper VWC

Como podemos ver, todos os operadores instalados têm pelo menos uma ValidatingWebHookConfiguration (VWC).

Kyverno e Gatekeeper são ambos mecanismos de política do Kubernetes que fornecem uma estrutura para definir e impor políticas em um cluster.

Exceções referem-se a regras ou condições específicas que permitem que uma política seja contornada ou modificada em certas circunstâncias, mas essa não é a única maneira!

Para kyverno, assim que há uma política de validação, o webhook kyverno-resource-validating-webhook-cfg é populado.

Para o Gatekeeper, há o arquivo YAML gatekeeper-validating-webhook-configuration.

Ambos vêm com valores padrão, mas as equipes de Administradores podem ter atualizado esses 2 arquivos.

Caso de Uso

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

Agora, identifique a seguinte saída:

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

Aqui, o rótulo kubernetes.io/metadata.name refere-se ao nome do namespace. Namespaces com nomes na lista values serão excluídos da política:

Verifique a existência de namespaces. Às vezes, devido à automação ou má configuração, alguns namespaces podem não ter sido criados. Se você tiver permissão para criar namespaces, poderá criar um namespace com um nome na lista values e as políticas não se aplicarão ao seu novo namespace.

O objetivo deste ataque é explorar má configuração dentro do VWC para contornar as restrições dos operadores e, em seguida, elevar seus privilégios com outras técnicas.

Abusing Roles/ClusterRoles in Kubernetes

Referências

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

• https://kyverno.io/

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