hacktricks-cloud/src/pentesting-cloud/kubernetes-security/kubernetes-validatingwebhookconfiguration.md

Kubernetes ValidatingWebhookConfiguration

{{#include ../../banners/hacktricks-training.md}}

O autor original desta página é Guillaume

Definition

ValidatingWebhookConfiguration é um recurso do Kubernetes que registra um ou mais validating admission webhooks. Esses webhooks recebem requests AdmissionReview do API server após authentication e authorization, mas antes de o object ser persistido.

Validating webhooks podem rejeitar uma request. Mutating webhooks, configurados com MutatingWebhookConfiguration, podem change o object primeiro. Security reviews normalmente devem inspecionar ambos os resources porque um mutating webhook malicioso ou fraco pode reescrever workloads, enquanto um validating webhook ou policy engine pode bloqueá-los ou permiti-los.

Purpose

O propósito de um ValidatingWebhookConfiguration é definir quando o API server deve chamar um validating webhook e como ele deve lidar com o resultado do webhook. A questão importante de security não é apenas "uma policy está instalada?", mas também:

• Quais API groups, resources, operations e scopes ele corresponde?
• Quais namespaces ou objects são excluídos por selectors?
• matchConditions ignora algum tipo de request?
• failurePolicy falha aberto com Ignore ou falha fechado com Fail?
• O webhook service está acessível, confiável pelo caBundle configurado e executado por um service account com privilégios elevados?
• O policy engine também expõe exception resources, excluded users ou excluded groups?

Example

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

A principal diferença entre uma ValidatingWebhookConfiguration e policies :

Kyverno.png

• ValidatingWebhookConfiguration (VWC) : Um recurso do Kubernetes que define um validating webhook, que é um componente do lado do servidor que valida requisições recebidas da API do Kubernetes com base em um conjunto de regras e restrições predefinidas.
• Kyverno ClusterPolicy: Uma definição de policy que especifica um conjunto de regras e restrições para validar e impor Kubernetes resources, como pods, deployments, 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

Campos a inspecionar:

• rules: Verifique os API groups, versions, resources, subresources, operations e scope cobertos.
• namespaceSelector / objectSelector: Procure namespaces ou labels que excluam recursos da policy.
• matchConditions: Expressões CEL podem, intencionalmente ou por engano, pular requests.
• failurePolicy: Ignore deixa as requests continuarem se o webhook falhar; Fail as bloqueia.
• sideEffects: Webhooks com side effects podem não suportar testes dry-run.
• timeoutSeconds: Timeouts muito curtos combinados com Ignore podem virar comportamento fail-open.
• clientConfig: Revise se o webhook aponta para um Service in-cluster ou URL externa, e inspecione o workload de suporte e a service account.
• reinvocationPolicy: Mutating webhooks podem ser reinvocados quando uma mutação posterior altera o objeto.

Abusing Kyverno and Gatekeeper VWC

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

Kyverno e Gatekeeper são ambos Kubernetes policy engines que fornecem um framework para definir e aplicar policies em um cluster.

Exceções se referem a regras ou condições específicas que permitem que uma policy seja contornada ou modificada sob certas circunstâncias, mas esta não é a única forma !

Para kyverno, assim que há uma validating policy, o webhook kyverno-resource-validating-webhook-cfg é populado.

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

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

Use Case

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

ValidatingWebhookConfiguration

ValidatingWebhookConfiguration is a resource in Kubernetes used to register webhooks that validate requests to the API server before they are accepted. When a resource is created, updated, or deleted, the API server can send the request to an external service for validation.

This object lets you enforce custom policies, such as:

• blocking forbidden images,
• requiring labels or annotations,
• rejecting unsafe configurations.

Main points

• It is defined under the admissionregistration.k8s.io API group.
• It can contain one or more webhooks.
• Each webhook specifies:
  • rules for which operations/resources it applies to,
  • clientConfig pointing to the service or URL,
  • caBundle for TLS trust,
  • failurePolicy to decide what happens if the webhook is unavailable.

Example

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: example-webhook
webhooks:
  - name: validate.example.com
    clientConfig:
      service:
        name: webhook-service
        namespace: default
        path: /validate
      caBundle: <base64-encoded-ca>
    rules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments"]

Security note

If an attacker can modify a ValidatingWebhookConfiguration, they may be able to:

• bypass validation,
• disable security controls,
• or redirect admission traffic to a malicious service.

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

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

Verifique a existência dos namespaces. Às vezes, devido à automação ou a uma misconfiguration, alguns namespaces podem não ter sido criados. Se você tiver permissão para criar namespace, você poderia criar um namespace com um nome na lista values e as policies não se aplicariam ao seu novo namespace.

O objetivo deste ataque é explorar misconfiguration dentro de VWC para contornar as restrições dos operators e então elevar seus privilégios com outras técnicas

Outros padrões comuns de bypass ou abuse:

• Um objectSelector que permite aos usuários adicionar um rótulo de opt-out aos seus próprios objects.
• failurePolicy: Ignore em validação crítica de segurança, especialmente quando o webhook Service não tem endpoints ou a rede é instável.
• Exceções do policy engine para users, groups, service accounts, namespaces ou roles mais amplas do que o pretendido.
• Cobertura ausente para templates de workload controller, pods/ephemeralcontainers, pods/exec, custom resources ou operações de update.
• Acesso de escrita a validatingwebhookconfigurations, mutatingwebhookconfigurations, Gatekeeper constraints, Kyverno policies ou exception resources.
• Um mutating webhook malicioso que injeta containers, altera images, monta secrets, adiciona tolerations ou muda a seleção de service account antes da validação.

Lembre-se de que admission protege apenas requests que passam pela cadeia de admission do API server. Static Pods, acesso ao socket de runtime local do node, abuse direto do kubelet e acesso direto ao etcd são caminhos de confiança diferentes e exigem hardening e monitoramento separados.

{{#ref}} abusing-roles-clusterroles-in-kubernetes/ {{#endref}}

References

• https://github.com/open-policy-agent/gatekeeper
• https://kyverno.io/
• https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/
• https://kubernetes.io/docs/concepts/cluster-administration/admission-webhooks-good-practices/
• https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/

{{#include ../../banners/hacktricks-training.md}}