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

Kubernetes ValidatingWebhookConfiguration

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

Mwandishi wa awali wa ukurasa huu ni Guillaume

Definition

ValidatingWebhookConfiguration ni rasilimali ya Kubernetes inayosajili validating admission webhooks moja au zaidi. Webhooks hizi hupokea maombi ya AdmissionReview kutoka kwa API server baada ya authentication na authorization, lakini kabla ya object kuhifadhiwa.

Validating webhooks zinaweza kukataa ombi. Mutating webhooks, zilizosanidiwa kwa MutatingWebhookConfiguration, zinaweza kubadilisha object kwanza. Security reviews kwa kawaida zinapaswa kukagua rasilimali zote mbili kwa sababu mutating webhook hasidi au dhaifu inaweza kuandika upya workloads, wakati validating webhook au policy engine inaweza kuzuia au kuziruhusu.

Purpose

Lengo la ValidatingWebhookConfiguration ni kufafanua API server inapaswa kuita validating webhook lini na jinsi inavyopaswa kushughulikia matokeo ya webhook. Swali muhimu la usalama si tu "policy imewekwa?", bali pia:

• Ni API groups, resources, operations, na scopes zipi inalingana nazo?
• Ni namespaces au objects zipi zimeondolewa kwa selectors?
• Je, matchConditions inaruka aina zozote za maombi?
• Je, failurePolicy inafail open kwa Ignore au fail closed kwa Fail?
• Je, huduma ya webhook inapatikana, inaaminika na caBundle iliyosanidiwa, na inaendeshwa na service account yenye priviliji nyingi?
• Je, policy engine pia inatoa exception resources, excluded users, au excluded groups?

Example

Huu hapa ni mfano wa 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"]

Tofauti kuu kati ya ValidatingWebhookConfiguration na policies :

Kyverno.png

• ValidatingWebhookConfiguration (VWC) : Rasilimali ya Kubernetes inayofafanua validating webhook, ambayo ni sehemu ya upande wa server inayohakiki maombi yanayoingia ya Kubernetes API dhidi ya seti ya sheria na vikwazo vilivyobainishwa awali.
• Kyverno ClusterPolicy: Ufafanuzi wa policy unaobainisha seti ya sheria na vikwazo kwa ajili ya kuhakiki na kutekeleza rasilimali za Kubernetes, kama vile pods, deployments, na 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

Fields to inspect:

• rules: Angalia API groups, versions, resources, subresources, operations, na scope zilizofunikwa.
• namespaceSelector / objectSelector: Tafuta namespaces au labels zinazoondoa resources kutoka kwenye policy.
• matchConditions: CEL expressions zinaweza kwa makusudi au kwa bahati ku-skip requests.
• failurePolicy: Ignore huacha requests ziendelee ikiwa webhook itashindwa; Fail huzizuia.
• sideEffects: Webhooks zenye side effects huenda zisikubali dry-run testing.
• timeoutSeconds: timeouts fupi sana zikiunganishwa na Ignore zinaweza kuwa fail-open behavior.
• clientConfig: Kagua kama webhook inaelekeza kwa in-cluster Service au external URL, na kagua backing workload na service account.
• reinvocationPolicy: Mutating webhooks zinaweza kuitishwa tena wakati mutation ya baadaye inabadilisha object.

Native CEL admission policies

Modern clusters zinaweza pia kutekeleza admission logic kwa native policy objects ndani ya admissionregistration.k8s.io, si kwa webhook configurations pekee. ValidatingAdmissionPolicy ni in-process CEL-based alternative to validating webhooks na huwa active tu wakati ValidatingAdmissionPolicyBinding inai-select. MutatingAdmissionPolicy ni stable katika Kubernetes v1.36 na huwashwa na MutatingAdmissionPolicyBinding kwa CEL-generated mutations.

Enumerate them with:

kubectl api-resources --api-group=admissionregistration.k8s.io -o wide
kubectl get validatingadmissionpolicies,validatingadmissionpolicybindings
kubectl get mutatingadmissionpolicies,mutatingadmissionpolicybindings 2>/dev/null || true
kubectl get validatingadmissionpolicy <name> -o yaml
kubectl get validatingadmissionpolicybinding <name> -o yaml

Security checks:

• A policy without a binding does not enforce anything.
• validationActions on the binding decides whether validation failures are denied, warned, audited, or only recorded.
• failurePolicy: Ignore lets CEL evaluation errors or misconfiguration fail open.
• matchConstraints, matchConditions, namespaceSelector, and objectSelector can exclude sensitive requests.
• paramKind and paramRef can make ConfigMaps or CRD-backed parameter objects part of the policy boundary; check who can modify those parameter objects.
• Writes to policies, bindings, and parameter resources should be treated like privileged admission-control changes.

Abusing Kyverno and Gatekeeper VWC

Kama tunavyoona, all operators zilizosakinishwa zina angalau moja ValidatingWebHookConfiguration(VWC).

Kyverno na Gatekeeper zote mbili ni Kubernetes policy engines zinazotoa framework ya kufafanua na kutekeleza policies ndani ya cluster.

Exceptions hurejelea rules au conditions maalum zinazoruhusu policy kupuuzwa au kubadilishwa chini ya circumstances fulani, lakini hii si njia pekee !

Kwa kyverno, mara tu kunapokuwepo validating policy, webhook kyverno-resource-validating-webhook-cfg hujazwa.

Kwa Gatekeeper, kuna gatekeeper-validating-webhook-configuration YAML file.

Zote huja na default values, lakini Administrator teams huenda wakawa wamezibadilisha hizo faili 2.

Use Case

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

Tafadhali toa matokeo yafuatayo:

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

Hapa, kubernetes.io/metadata.name inarejelea label ya jina la namespace. Namespaces zenye majina yaliyo kwenye orodha ya values zitaondolewa kwenye policy:

Angalia uwepo wa namespaces. Wakati mwingine, kutokana na automation au misconfiguration, baadhi ya namespaces huenda hazijaundwa. Ikiwa una ruhusa ya kuunda namespace, unaweza kuunda namespace yenye jina lililo kwenye orodha ya values na policies hazitatumika kwenye namespace yako mpya.

Lengo la shambulio hili ni kutumia misconfiguration ndani ya VWC ili kupita vikwazo vya operators kisha kuongeza privileges zako kwa kutumia techniques nyingine

Mifumo mingine ya kawaida ya bypass au abuse:

• objectSelector inayowaruhusu users kuongeza opt-out label kwenye objects zao wenyewe.
• failurePolicy: Ignore kwenye validation muhimu ya security, hasa wakati webhook Service haina endpoints au networking isiyoaminika.
• Policy engine exceptions kwa users, groups, service accounts, namespaces, au roles ambazo ni pana zaidi kuliko ilivyokusudiwa.
• Kukosekana kwa coverage kwa workload controller templates, pods/ephemeralcontainers, pods/exec, custom resources, au update operations.
• Write access kwa validatingwebhookconfigurations, mutatingwebhookconfigurations, Gatekeeper constraints, Kyverno policies, au exception resources.
• Mutating webhook mbaya inayodunga containers, kubadilisha images, kuweka mounts za secrets, kuongeza tolerations, au kubadilisha uteuzi wa service account kabla ya validation.

Kumbuka kwamba admission hulinda tu requests zinazopita kupitia API server admission chain. Static Pods, node-local runtime socket access, direct kubelet abuse, na direct etcd access ni trust paths tofauti na zinahitaji hardening na monitoring tofauti.

{{#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/
• https://kubernetes.io/docs/reference/access-authn-authz/mutating-admission-policy/
• https://kubernetes.io/docs/reference/using-api/cel/

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