Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe

src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/README.md

@@ -1,18 +1,18 @@
-# OpenShift - Privilege Escalation
+# OpenShift - विशेषाधिकार वृद्धि
 
-## Missing Service Account
+## सेवा खाता गायब
 
 {{#ref}}
 openshift-missing-service-account.md
 {{#endref}}
 
-## Tekton
+## टेकटन
 
 {{#ref}}
 openshift-tekton.md
 {{#endref}}
 
-## SCC Bypass
+## SCC बायपास
 
 {{#ref}}
 openshift-scc-bypass.md

src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-missing-service-account.md

@@ -2,13 +2,13 @@
 
 ## Missing Service Account
 
-यह होता है कि क्लस्टर एक पूर्व-निर्धारित टेम्पलेट के साथ तैनात किया गया है जो स्वचालित रूप से Roles, RoleBindings और यहां तक कि SCC को उस सेवा खाते के लिए सेट करता है जो अभी तक बनाया नहीं गया है। यदि आप उन्हें बना सकते हैं तो यह विशेषाधिकार वृद्धि का कारण बन सकता है। इस मामले में, आप नए बनाए गए SA का टोकन और संबंधित भूमिका या SCC प्राप्त कर सकेंगे। वही मामला तब होता है जब गायब SA एक गायब प्रोजेक्ट का हिस्सा होता है, इस मामले में यदि आप प्रोजेक्ट बना सकते हैं और फिर SA बना सकते हैं, तो आप संबंधित Roles और SCC प्राप्त करते हैं।
+यह होता है कि क्लस्टर को पूर्व-निर्धारित टेम्पलेट के साथ तैनात किया गया है जो स्वचालित रूप से Roles, RoleBindings और यहां तक कि SCC को सेवा खाते के लिए सेट करता है जो अभी तक बनाया नहीं गया है। यदि आप उन्हें बना सकते हैं तो यह विशेषाधिकार वृद्धि का कारण बन सकता है। इस मामले में, आप नए बनाए गए SA का टोकन और संबंधित भूमिका या SCC प्राप्त कर सकेंगे। समान मामला तब होता है जब गायब SA एक गायब प्रोजेक्ट का हिस्सा होता है, इस मामले में यदि आप प्रोजेक्ट बना सकते हैं और फिर SA बना सकते हैं, तो आप संबंधित Roles और SCC प्राप्त करते हैं।
 
 <figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
 
-पिछले ग्राफ में हमें कई AbsentProject मिले, जिसका अर्थ है कि कई प्रोजेक्ट जो Roles Bindings या SCC में दिखाई देते हैं लेकिन अभी तक क्लस्टर में बनाए नहीं गए हैं। उसी संदर्भ में हमें एक AbsentServiceAccount भी मिला।
+पिछले ग्राफ में हमारे पास कई AbsentProject हैं जिसका अर्थ है कि कई प्रोजेक्ट हैं जो Roles Bindings या SCC में दिखाई देते हैं लेकिन अभी तक क्लस्टर में बनाए नहीं गए हैं। उसी संदर्भ में हमारे पास एक AbsentServiceAccount भी है।
 
-यदि हम एक प्रोजेक्ट और उसमें गायब SA बना सकते हैं, तो SA उस भूमिका या SCC से विरासत में मिलेगा जो AbsentServiceAccount को लक्षित कर रहे थे। जो विशेषाधिकार वृद्धि का कारण बन सकता है।
+यदि हम एक प्रोजेक्ट और उसमें गायब SA बना सकते हैं, तो SA उस भूमिका या SCC से विरासत में मिलेगा जो AbsentServiceAccount को लक्षित कर रहा था। जो विशेषाधिकार वृद्धि का कारण बन सकता है।
 
 निम्नलिखित उदाहरण एक गायब SA को दिखाता है जिसे node-exporter SCC दिया गया है:
 
@@ -16,7 +16,7 @@
 
 ## Tools
 
-इस समस्या को सूचीबद्ध करने और सामान्य रूप से एक OpenShift क्लस्टर को ग्राफ करने के लिए निम्नलिखित उपकरण का उपयोग किया जा सकता है:
+इस समस्या को सूचीबद्ध करने और सामान्य रूप से OpenShift क्लस्टर को ग्राफ करने के लिए निम्नलिखित उपकरण का उपयोग किया जा सकता है:
 
 {{#ref}}
 https://github.com/maxDcb/OpenShiftGrapher

src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md

@@ -2,7 +2,7 @@
 
 **इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
 
-## विशेषाधिकार प्राप्त नामस्थान
+## Privileged Namespaces
 
 डिफ़ॉल्ट रूप से, SCC निम्नलिखित परियोजनाओं पर लागू नहीं होता है:
 
@@ -13,14 +13,14 @@
 - **openshift-infra**
 - **openshift**
 
-यदि आप इन नामस्थानों में से किसी एक में पॉड्स तैनात करते हैं, तो कोई SCC लागू नहीं होगा, जिससे विशेषाधिकार प्राप्त पॉड्स की तैनाती या होस्ट फ़ाइल प्रणाली को माउंट करने की अनुमति मिलती है।
+यदि आप इन नामस्थान में पॉड्स तैनात करते हैं, तो कोई SCC लागू नहीं होगा, जिससे विशेषाधिकार प्राप्त पॉड्स की तैनाती या होस्ट फ़ाइल सिस्टम को माउंट करने की अनुमति मिलेगी।
 
-## नामस्थान लेबल
+## Namespace Label
 
-RedHat दस्तावेज़ के अनुसार, आपके पॉड पर SCC आवेदन को अक्षम करने का एक तरीका है। आपको निम्नलिखित में से कम से कम एक अनुमति होनी चाहिए:
+RedHat दस्तावेज़ के अनुसार, आपके पॉड पर SCC एप्लिकेशन को अक्षम करने का एक तरीका है। आपको निम्नलिखित में से कम से कम एक अनुमति होनी चाहिए:
 
-- एक नामस्थान बनाना और इस नामस्थान पर एक पॉड बनाना
-- एक नामस्थान संपादित करना और इस नामस्थान पर एक पॉड बनाना
+- एक Namespace बनाना और इस Namespace पर एक Pod बनाना
+- एक Namespace को संपादित करना और इस Namespace पर एक Pod बनाना
 ```bash
 $ oc auth can-i create namespaces
 yes
@@ -28,7 +28,7 @@ yes
 $ oc auth can-i patch namespaces
 yes
 ```
-विशिष्ट लेबल `openshift.io/run-level` उपयोगकर्ताओं को अनुप्रयोगों के लिए SCCs को दरकिनार करने की अनुमति देता है। RedHat दस्तावेज़ के अनुसार, जब इस लेबल का उपयोग किया जाता है, तो उस नामस्थान के भीतर सभी पॉड्स पर कोई SCCs लागू नहीं होते, प्रभावी रूप से किसी भी प्रतिबंध को हटा दिया जाता है।
+विशिष्ट लेबल `openshift.io/run-level` उपयोगकर्ताओं को अनुप्रयोगों के लिए SCCs को दरकिनार करने की अनुमति देता है। RedHat दस्तावेज़ के अनुसार, जब इस लेबल का उपयोग किया जाता है, तो उस नामस्थान के सभी पॉड्स पर कोई SCCs लागू नहीं होते हैं, प्रभावी रूप से किसी भी प्रतिबंध को हटा देते हैं।
 
 <figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
 
@@ -38,7 +38,7 @@ yes
 ```bash
 $ oc label ns MYNAMESPACE openshift.io/run-level=0
 ```
-एक YAML फ़ाइल के माध्यम से लेबल के साथ एक नामस्थान बनाने के लिए:
+YAML फ़ाइल के माध्यम से लेबल के साथ एक नामस्थान बनाने के लिए:
 ```yaml
 apiVersion: v1
 kind: Namespace
@@ -86,7 +86,7 @@ volumes:
 hostPath:
 path:
 ```
-अब, होस्ट सिस्टम तक पहुँचने के लिए विशेषाधिकारों को बढ़ाना और इसके बाद पूरे क्लस्टर पर नियंत्रण प्राप्त करना, 'cluster-admin' विशेषाधिकार प्राप्त करना आसान हो गया है। निम्नलिखित पृष्ठ में **Node-Post Exploitation** भाग देखें:
+अब, होस्ट सिस्टम तक पहुंच के लिए विशेषाधिकार बढ़ाना और इसके बाद पूरे क्लस्टर पर नियंत्रण प्राप्त करना, 'cluster-admin' विशेषाधिकार प्राप्त करना आसान हो गया है। निम्नलिखित पृष्ठ में **Node-Post Exploitation** भाग देखें:
 
 {{#ref}}
 ../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
@@ -94,9 +94,9 @@ path:
 
 ### कस्टम लेबल
 
-इसके अलावा, लक्षित सेटअप के आधार पर, कुछ कस्टम लेबल / एनोटेशन का उपयोग पिछले हमले के परिदृश्य के समान किया जा सकता है। भले ही इसे इसके लिए नहीं बनाया गया हो, लेबल का उपयोग अनुमतियाँ देने, किसी विशेष संसाधन को प्रतिबंधित करने या न करने के लिए किया जा सकता है।
+इसके अलावा, लक्षित सेटअप के आधार पर, कुछ कस्टम लेबल / एनोटेशन का उपयोग पिछले हमले के परिदृश्य के समान किया जा सकता है। भले ही इसे इसके लिए नहीं बनाया गया हो, लेबल का उपयोग अनुमतियों को देने, किसी विशेष संसाधन को प्रतिबंधित करने या नहीं करने के लिए किया जा सकता है।
 
-यदि आप कुछ संसाधनों को पढ़ सकते हैं तो कस्टम लेबल की तलाश करें। यहाँ कुछ दिलचस्प संसाधनों की सूची है:
+यदि आप कुछ संसाधनों को पढ़ सकते हैं तो कस्टम लेबल की तलाश करने का प्रयास करें। यहाँ कुछ दिलचस्प संसाधनों की सूची है:
 
 - Pod
 - Deployment
@@ -113,11 +113,11 @@ $ oc get project -o yaml | grep 'run-level' -b5
 ```
 ## Advanced exploit
 
-OpenShift में, जैसा कि पहले दिखाया गया, `openshift.io/run-level` लेबल के साथ एक नामस्थान में एक पॉड को तैनात करने की अनुमति होने से क्लस्टर का सीधा अधिग्रहण हो सकता है। क्लस्टर सेटिंग्स के दृष्टिकोण से, यह कार्यक्षमता **निष्क्रिय नहीं की जा सकती**, क्योंकि यह OpenShift के डिज़ाइन में अंतर्निहित है।
+OpenShift में, जैसा कि पहले दिखाया गया है, एक namespace में `openshift.io/run-level` लेबल के साथ pod को तैनात करने की अनुमति होना क्लस्टर का सीधा अधिग्रहण करने की ओर ले जा सकता है। क्लस्टर सेटिंग्स के दृष्टिकोण से, यह कार्यक्षमता **अक्षम नहीं की जा सकती**, क्योंकि यह OpenShift के डिज़ाइन में अंतर्निहित है।
 
 हालांकि, **Open Policy Agent GateKeeper** जैसी शमन उपाय उपयोगकर्ताओं को इस लेबल को सेट करने से रोक सकते हैं।
 
-GateKeeper के नियमों को बायपास करने और क्लस्टर अधिग्रहण को निष्पादित करने के लिए इस लेबल को सेट करने के लिए, **हमलावरों को वैकल्पिक तरीकों की पहचान करने की आवश्यकता होगी।**
+GateKeeper के नियमों को बायपास करने और क्लस्टर अधिग्रहण को निष्पादित करने के लिए इस लेबल को सेट करने के लिए, **हमलावरों को वैकल्पिक तरीकों की पहचान करनी होगी।**
 
 ## References
 

src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md

@@ -4,11 +4,11 @@
 
 ### Tekton क्या है
 
-दस्तावेज़ के अनुसार: _Tekton एक शक्तिशाली और लचीला ओपन-सोर्स ढांचा है जो CI/CD सिस्टम बनाने के लिए है, जिससे डेवलपर्स क्लाउड प्रदाताओं और ऑन-प्रिमाइस सिस्टम पर निर्माण, परीक्षण और तैनाती कर सकते हैं।_ Jenkins और Tekton दोनों का उपयोग एप्लिकेशन का परीक्षण, निर्माण और तैनाती के लिए किया जा सकता है, हालाँकि Tekton क्लाउड नेटिव है। 
+दस्तावेज़ के अनुसार: _Tekton एक शक्तिशाली और लचीला ओपन-सोर्स ढांचा है जो CI/CD सिस्टम बनाने के लिए है, जिससे डेवलपर्स क्लाउड प्रदाताओं और ऑन-प्रिमाइस सिस्टम पर निर्माण, परीक्षण और तैनाती कर सकते हैं।_ Jenkins और Tekton दोनों का उपयोग अनुप्रयोगों का परीक्षण, निर्माण और तैनाती के लिए किया जा सकता है, हालाँकि Tekton क्लाउड नेटिव है। 
 
 Tekton के साथ सब कुछ YAML फ़ाइलों द्वारा दर्शाया जाता है। डेवलपर्स `Pipelines` प्रकार के कस्टम संसाधन (CR) बना सकते हैं और उनमें कई `Tasks` निर्दिष्ट कर सकते हैं जिन्हें वे चलाना चाहते हैं। एक Pipeline चलाने के लिए `PipelineRun` प्रकार के संसाधन बनाए जाने चाहिए।
 
-जब tekton स्थापित किया जाता है, तो हर namespace में एक सेवा खाता (sa) बनाया जाता है जिसे pipeline कहा जाता है। जब एक Pipeline चलाई जाती है, तो YAML फ़ाइल में परिभाषित कार्यों को चलाने के लिए इस sa का उपयोग करके एक pod उत्पन्न किया जाएगा जिसे `pipeline` कहा जाता है।
+जब tekton स्थापित होता है, तो हर namespace में एक सेवा खाता (sa) बनाया जाता है जिसे pipeline कहा जाता है। जब एक Pipeline चलाई जाती है, तो YAML फ़ाइल में परिभाषित कार्यों को चलाने के लिए इस sa का उपयोग करके एक pod उत्पन्न किया जाएगा जिसे `pipeline` कहा जाता है।
 
 {{#ref}}
 https://tekton.dev/docs/getting-started/pipelines/
@@ -16,7 +16,7 @@ https://tekton.dev/docs/getting-started/pipelines/
 
 ### Pipeline सेवा खाता क्षमताएँ
 
-डिफ़ॉल्ट रूप से, pipeline सेवा खाता `pipelines-scc` क्षमता का उपयोग कर सकता है। यह tekton की वैश्विक डिफ़ॉल्ट कॉन्फ़िगरेशन के कारण है। वास्तव में, tekton की वैश्विक कॉन्फ़िगरेशन भी एक YAML है जो एक openshift ऑब्जेक्ट में `TektonConfig` कहा जाता है जिसे आप क्लस्टर में कुछ रीडर भूमिकाएँ होने पर देख सकते हैं।
+डिफ़ॉल्ट रूप से, pipeline सेवा खाता `pipelines-scc` क्षमता का उपयोग कर सकता है। यह tekton की वैश्विक डिफ़ॉल्ट कॉन्फ़िगरेशन के कारण है। वास्तव में, tekton की वैश्विक कॉन्फ़िगरेशन भी एक YAML है जो एक openshift ऑब्जेक्ट में है जिसे `TektonConfig` कहा जाता है जिसे आप क्लस्टर में कुछ रीडर भूमिकाएँ होने पर देख सकते हैं।
 ```yaml
 apiVersion: operator.tekton.dev/v1alpha1
 kind: TektonConfig
@@ -43,17 +43,17 @@ name: test-namespace
 annotations:
 operator.tekton.dev/scc: privileged
 ```
-The tekton operator will give to the pipeline service account in `test-namespace` the ability to use the scc privileged. This will allow the mounting of the node.
+tekton ऑपरेटर `test-namespace` में पाइपलाइन सेवा खाते को scc privileged का उपयोग करने की क्षमता देगा। इससे नोड को माउंट करने की अनुमति मिलेगी।
 
-### The fix
+### समाधान
 
-Tekton documents about how to restrict the override of scc by adding a label in the `TektonConfig` object.
+Tekton दस्तावेज़ों में `TektonConfig` ऑब्जेक्ट में लेबल जोड़कर scc के ओवरराइड को प्रतिबंधित करने के बारे में बताया गया है।
 
 {{#ref}}
 https://tekton.dev/docs/operator/sccconfig/
 {{#endref}}
 
-This label is called `max-allowed` 
+इस लेबल को `max-allowed` कहा जाता है।
 ```yaml
 apiVersion: operator.tekton.dev/v1alpha1
 kind: TektonConfig