# Kubernetes ValidatingWebhookConfiguration

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

**O autor original desta página é** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

## 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:
```yaml
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 :

<figure><img src="../../images/Kyverno.png" alt=""><figcaption><p>Kyverno.png</p></figcaption></figure>

- **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
```bash
$ 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
```yaml
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.
```yaml
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://github.com/open-policy-agent/gatekeeper)
- [https://kyverno.io/](https://kyverno.io/)
- [https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/](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/concepts/cluster-administration/admission-webhooks-good-practices/)
- [https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)



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