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

Kubernetes ValidatingWebhookConfiguration

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

इस पेज का मूल लेखक है Guillaume

परिभाषा

ValidatingWebhookConfiguration एक Kubernetes resource है जो एक या अधिक validating admission webhooks register करता है। ये webhooks authentication और authorization के बाद, लेकिन object persist होने से पहले, API server से AdmissionReview requests प्राप्त करते हैं।

Validating webhooks request को reject कर सकते हैं। MutatingWebhookConfiguration के साथ configured mutating webhooks, पहले object को बदल सकते हैं। Security reviews में आमतौर पर दोनों resources की जांच करनी चाहिए क्योंकि एक malicious या कमजोर mutating webhook workloads को rewrite कर सकता है, जबकि एक validating webhook या policy engine उन्हें block या allow कर सकता है।

उद्देश्य

ValidatingWebhookConfiguration का उद्देश्य यह परिभाषित करना है कि API server कब एक validating webhook को call करे और webhook result को कैसे handle करे। महत्वपूर्ण security सवाल केवल यह नहीं है कि "क्या कोई policy installed है?", बल्कि यह भी है:

• यह किन API groups, resources, operations, और scopes से match करता है?
• selectors द्वारा कौन से namespaces या objects exclude किए गए हैं?
• क्या matchConditions किसी request classes को skip करता है?
• क्या failurePolicy Ignore के साथ fail open करता है या Fail के साथ fail closed?
• क्या webhook service reachable है, configured caBundle द्वारा trusted है, और एक highly privileged service account द्वारा run की जाती है?
• क्या policy engine exception resources, excluded users, या excluded groups भी expose करता है?

उदाहरण

यहाँ एक ValidatingWebhookConfiguration का example है:

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"]

एक ValidatingWebhookConfiguration और policies के बीच मुख्य अंतर :

Kyverno.png

• ValidatingWebhookConfiguration (VWC) : एक Kubernetes resource जो एक validating webhook को परिभाषित करता है, जो एक server-side component है जो आने वाली Kubernetes API requests को predefined rules और constraints के set के against validate करता है।
• Kyverno ClusterPolicy: एक policy definition जो Kubernetes resources, जैसे pods, deployments, और services, को validate और enforce करने के लिए rules और constraints का एक set specify करती है

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: कवर किए गए API groups, versions, resources, subresources, operations, और scope की जांच करें।
• namespaceSelector / objectSelector: उन namespaces या labels को देखें जो policy से resources को exclude करते हैं।
• matchConditions: CEL expressions जानबूझकर या गलती से requests को skip कर सकते हैं।
• failurePolicy: Ignore अगर webhook fail हो जाए तो requests को जारी रहने देता है; Fail उन्हें block करता है।
• sideEffects: side effects वाले Webhooks dry-run testing को support नहीं कर सकते।
• timeoutSeconds: Ignore के साथ बहुत short timeouts fail-open behavior बन सकते हैं।
• clientConfig: Review करें कि webhook in-cluster Service या external URL की ओर point करता है या नहीं, और backing workload तथा service account की जांच करें।
• reinvocationPolicy: Mutating webhooks को फिर से invoke किया जा सकता है जब बाद की mutation object को बदल देती है।

Native CEL admission policies

Modern clusters admission logic को native policy objects in admissionregistration.k8s.io के साथ भी enforce कर सकते हैं, सिर्फ webhook configurations के साथ नहीं। ValidatingAdmissionPolicy validating webhooks का in-process CEL-based alternative है और केवल तब active होता है जब ValidatingAdmissionPolicyBinding इसे select करता है। MutatingAdmissionPolicy Kubernetes v1.36 में stable है और CEL-generated mutations के लिए MutatingAdmissionPolicyBinding द्वारा activated होता है।

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:

• एक policy बिना binding के कुछ भी enforce नहीं करती।
• binding पर validationActions तय करता है कि validation failures deny हों, warn हों, audit हों, या केवल record हों।
• failurePolicy: Ignore CEL evaluation errors या misconfiguration को fail open होने देता है।
• matchConstraints, matchConditions, namespaceSelector, और objectSelector sensitive requests को exclude कर सकते हैं।
• paramKind और paramRef ConfigMaps या CRD-backed parameter objects को policy boundary का हिस्सा बना सकते हैं; देखें कि उन parameter objects को कौन modify कर सकता है।
• policies, bindings, और parameter resources पर writes को privileged admission-control changes की तरह treat करना चाहिए।

Abusing Kyverno and Gatekeeper VWC

जैसा कि हम देख सकते हैं, install किए गए सभी operators में कम से कम एक ValidatingWebHookConfiguration(VWC) है।

Kyverno और Gatekeeper दोनों Kubernetes policy engines हैं जो पूरे cluster में policies को define और enforce करने का framework देते हैं।

Exceptions किसी policy को bypass या modify करने के लिए specific rules या conditions को refer करते हैं जब कुछ खास परिस्थितियाँ हों, लेकिन यह एकमात्र तरीका नहीं है !

kyverno के लिए, जैसे ही एक validating policy होती है, webhook kyverno-resource-validating-webhook-cfg populate हो जाता है।

Gatekeeper के लिए, gatekeeper-validating-webhook-configuration YAML file है।

दोनों default values के साथ आते हैं, लेकिन Administrator teams इन दोनों files को update कर सकती हैं।

Use Case

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

मुझे अनुवाद के लिए मूल अंग्रेज़ी सामग्री नहीं मिली। कृपया src/pentesting-cloud/kubernetes-security/kubernetes-validatingwebhookconfiguration.md का टेक्स्ट भेजें, और मैं उसे वही markdown/HTML syntax रखते हुए हिन्दी में अनुवाद कर दूँगा।

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

Here, kubernetes.io/metadata.name namespace name label को संदर्भित करता है। values list में नाम वाले namespaces policy से exclude किए जाएंगे:

Namespaces की existence check करें। कभी-कभी, automation या misconfiguration के कारण, कुछ namespaces create नहीं हुए होते। अगर आपके पास namespace create करने की permission है, तो आप values list में दिए गए नाम से एक namespace बना सकते हैं और policies आपके नए namespace पर लागू नहीं होंगी।

इस attack का goal VWC के अंदर misconfiguration का exploit करना है ताकि operators restrictions bypass की जा सकें और फिर दूसरी techniques से अपनी privileges elevate की जा सकें

Other common bypass or abuse patterns:

• एक objectSelector जो users को अपने objects पर opt-out label जोड़ने की अनुमति देता है।
• security-critical validation पर failurePolicy: Ignore, खासकर जब webhook Service के पास endpoints न हों या networking unreliable हो।
• users, groups, service accounts, namespaces, या roles के लिए policy engine exceptions जो intended से ज़्यादा broad हों।
• workload controller templates, pods/ephemeralcontainers, pods/exec, custom resources, या update operations के लिए coverage missing होना।
• validatingwebhookconfigurations, mutatingwebhookconfigurations, Gatekeeper constraints, Kyverno policies, या exception resources पर write access।
• एक malicious mutating webhook जो validation से पहले containers inject करता है, images बदलता है, secrets mount करता है, tolerations जोड़ता है, या service account selection बदलता है।

याद रखें कि admission केवल उन requests को protect करता है जो API server admission chain से pass होती हैं। Static Pods, node-local runtime socket access, direct kubelet abuse, और direct etcd access अलग trust paths हैं और उनके लिए अलग hardening और monitoring की जरूरत होती है।

{{#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}}