Translated ['src/pentesting-ci-cd/ansible-tower-awx-automation-controlle

2025-12-28 13:43:24 -08:00 · 2025-08-01 10:17:06 +00:00
parent 66a462aa95
commit 83bb7cf26a
47 changed files with 591 additions and 409 deletions
--- a/src/pentesting-cloud/openshift-pentesting/README.md
+++ b/src/pentesting-cloud/openshift-pentesting/README.md
@@ -1,5 +1,7 @@
 # OpenShift Pentesting

+{{#include ../../banners/hacktricks-training.md}}
+
 ## 基本情報

 {{#ref}}
@@ -17,3 +19,7 @@ openshift-scc.md
 {{#ref}}
 openshift-privilege-escalation/
 {{#endref}}
+
+
+
+{{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/openshift-pentesting/openshift-basic-information.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-basic-information.md
@@ -1,5 +1,7 @@
 # OpenShift - 基本情報

+{{#include ../../banners/hacktricks-training.md}}
+
 ## Kubernetesの基本知識 <a href="#a94e" id="a94e"></a>

 OpenShiftを使用する前に、Kubernetes環境に慣れていることを確認してください。OpenShiftの章全体は、Kubernetesの前提知識があることを前提としています。
@@ -8,11 +10,11 @@ OpenShiftを使用する前に、Kubernetes環境に慣れていることを確

 ### はじめに

-OpenShiftは、Kubernetes機能のスーパーセットを提供するRed Hatのコンテナアプリケーションプラットフォームです。OpenShiftは、より厳格なセキュリティポリシーを持っています。たとえば、コンテナをrootとして実行することは禁止されています。また、セキュリティを強化するためのデフォルトで安全なオプションも提供しています。OpenShiftには、ワンタッチログインページを含むWebコンソールがあります。
+OpenShiftは、Kubernetesの機能のスーパーセットを提供するRed Hatのコンテナアプリケーションプラットフォームです。OpenShiftは、より厳格なセキュリティポリシーを持っています。たとえば、rootとしてコンテナを実行することは禁止されています。また、セキュリティを強化するためのデフォルトで安全なオプションも提供しています。OpenShiftには、ワンタッチログインページを含むWebコンソールがあります。

 #### CLI

-OpenShiftには独自のCLIがあり、ここで見つけることができます：
+OpenShiftには独自のCLIがあり、ここにあります：

 {{#ref}}
 https://docs.openshift.com/container-platform/4.11/cli_reference/openshift_cli/getting-started-cli.html
@@ -25,7 +27,7 @@ oc login -s=<server> --token=<bearer token>
 ```
 ### **OpenShift - セキュリティコンテキスト制約** <a href="#a94e" id="a94e"></a>

-ユーザーが何をできるかを制御する[RBACリソース](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization)に加えて、OpenShift Container Platformはポッドが実行できるアクションとアクセスできる能力を制御する_セキュリティコンテキスト制約_（SCC）を提供します。
+ユーザーが何をできるかを制御する[RBACリソース](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization)に加えて、OpenShift Container Platformはポッドが実行できるアクションとアクセスできるものを制御する_セキュリティコンテキスト制約_（SCC）を提供します。

 SCCは、プラットフォームに対応するルールを持つRBACとは異なり、インフラストラクチャ自体に対応する特別なルールを持つポリシーオブジェクトです。これにより、コンテナが要求/実行できるLinuxアクセス制御機能を定義するのに役立ちます。例：Linux Capabilities、SECCOMPプロファイル、ローカルホストディレクトリのマウントなど。

@@ -36,3 +38,7 @@ openshift-scc.md
 {{#ref}}
 https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints
 {{#endref}}
+
+
+
+{{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md
@@ -1,12 +1,14 @@
 # OpenShift - Jenkins

+{{#include ../../../banners/hacktricks-training.md}}
+
 **このページの元の著者は** [**Fares**](https://www.linkedin.com/in/fares-siala/)

 このページでは、OpenShift（またはKubernetes）クラスターで実行されているJenkinsインスタンスを攻撃する方法についてのいくつかのポイントを示します。

 ## 免責事項

-Jenkinsインスタンスは、OpenShiftまたはKubernetesクラスターの両方にデプロイできます。あなたのコンテキストに応じて、表示されているペイロード、yaml、または技術を適応させる必要があるかもしれません。Jenkinsを攻撃する方法についての詳細は、[このページ](../../../pentesting-ci-cd/jenkins-security/)を参照してください。
+Jenkinsインスタンスは、OpenShiftまたはKubernetesクラスターの両方にデプロイできます。あなたのコンテキストに応じて、表示されているペイロード、yaml、または技術を適応させる必要があるかもしれません。Jenkinsを攻撃する方法についての詳細は、[このページ](../../../pentesting-ci-cd/jenkins-security/index.html)を参照してください。

 ## 前提条件

@@ -26,14 +28,16 @@ Jenkinsインスタンスは、OpenShiftまたはKubernetesクラスターの両

 1. JenkinsへのUIアクセスがある

-非常に簡単で便利な方法は、既存のビルドのリプレイ機能を使用することです。これにより、以前に実行されたビルドをリプレイしながら、groovyスクリプトを更新できます。これにはJenkinsフォルダーに対する権限と、事前定義されたパイプラインが必要です。ステルス性が必要な場合は、十分な権限があればトリガーしたビルドを削除できます。
+非常に簡単で便利な方法は、既存のビルドのリプレイ機能を使用することです。これにより、以前に実行されたビルドをリプレイしながら、groovyスクリプトを更新できます。これにはJenkinsフォルダーに対する権限と、事前に定義されたパイプラインが必要です。ステルス性が必要な場合は、十分な権限があればトリガーしたビルドを削除できます。

 2. SCMへの書き込みアクセスがあり、自動ビルドがWebhookを介して構成されている

-ビルドスクリプト（Jenkinsfileなど）を編集し、コミットしてプッシュするだけです（ビルドがPRマージ時のみトリガーされる場合は、最終的にPRを作成します）。この方法は非常に騒がしいことを覚えておいてください。足跡を消すには、昇格した権限が必要です。
+ビルドスクリプト（Jenkinsfileなど）を編集し、コミットしてプッシュするだけです（ビルドがPRマージ時のみトリガーされる場合は、最終的にPRを作成します）。この方法は非常に騒がしく、足跡を消すためには高い権限が必要です。

 ## JenkinsビルドポッドYAMLオーバーライド

 {{#ref}}
 openshift-jenkins-build-overrides.md
 {{#endref}}
+
+{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/openshift-jenkins-build-overrides.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/openshift-jenkins-build-overrides.md
@@ -1,10 +1,12 @@
 # Jenkins in Openshift - build pod overrides

+{{#include ../../../banners/hacktricks-training.md}}
+
 **このページの元の著者は** [**Fares**](https://www.linkedin.com/in/fares-siala/)

 ## Kubernetes plugin for Jenkins
-このプラグインは、openshift/kubernetes クラスター内の Jenkins コア機能の主な責任を担っています。公式ドキュメントは [こちら](https://plugins.jenkins.io/kubernetes/)です。
-開発者が jenkins ビルドポッドのいくつかのデフォルト設定をオーバーライドする能力など、いくつかの機能を提供します。
+このプラグインは、openshift/kubernetes クラスター内の Jenkins コア機能を主に担当しています。公式ドキュメントは [here](https://plugins.jenkins.io/kubernetes/) です。
+開発者が jenkins ビルドポッドのデフォルト設定をオーバーライドする機能など、いくつかの機能を提供します。

 ## Core functionnality

@@ -36,7 +38,7 @@ sh 'mvn -B -ntp clean install'
 ```
 ## 一部のポッド YAML オーバーライドを利用した悪用

-ただし、Kali Linux のようなアクセス可能なイメージを使用し、そのイメージからプリインストールされたツールを使用して任意のコマンドを実行するために悪用される可能性があります。  
+ただし、Kali Linux のようなアクセス可能なイメージを使用し、そのイメージにプリインストールされたツールを使用して任意のコマンドを実行するために悪用される可能性があります。  
 以下の例では、実行中のポッドの serviceaccount トークンを抽出できます。
 ```groovy
 podTemplate(yaml: '''
@@ -180,7 +182,7 @@ sh 'env'

 ### 可能な権限昇格/ピボットシナリオ

-評価中に、すべてのjenkinsビルドが_worker-ns_という名前空間内で実行されていることがわかったと仮定しましょう。ビルドポッドには_default-sa_というデフォルトのサービスアカウントがマウントされていることがわかりましたが、いくつかのリソースに対する読み取りアクセスを除いて、それほど多くの権限はありませんでしたが、_master-sa_という既存のサービスアカウントを特定することができました。
+評価中に、すべてのjenkinsビルドが_worker-ns_という名前空間内で実行されていることがわかったと仮定しましょう。ビルドポッドには_default-sa_というデフォルトのサービスアカウントがマウントされていることがわかりましたが、いくつかのリソースに対する読み取りアクセスを除いてそれほど多くの権限はありませんでしたが、_master-sa_という既存のサービスアカウントを特定することができました。
 また、実行中のビルドコンテナ内にocコマンドがインストールされていると仮定しましょう。

 以下のビルドスクリプトを使用すると、_master-sa_サービスアカウントを制御し、さらに列挙することができます。
@@ -216,15 +218,15 @@ sh 'oc --token=$token whoami'
 }
 }
 ```
-アクセスに応じて、ビルドスクリプトから攻撃を続ける必要があるか、実行中のクラスターでこのsaとして直接ログインできます。
+アクセスに応じて、ビルドスクリプトから攻撃を続ける必要があるか、実行中のクラスターでこのsaとして直接ログインできます:
 ```bash
 oc login --token=$token --server=https://apiserver.com:port
 ```
-この sa に十分な権限（pod/exec など）がある場合、同じ名前空間内で実行されている場合、マスターノードポッド内でコマンドを実行することによって、全体の jenkins インスタンスを制御することもできます。このポッドは、その名前と jenkins データを保存するために使用される PVC（永続ボリュームクレーム）をマウントしている必要があるため、簡単に特定できます。
+この sa に十分な権限（pod/exec など）がある場合、同じ名前空間内で実行されているマスターノードポッド内でコマンドを実行することにより、Jenkins インスタンス全体を制御することもできます。このポッドは、その名前と Jenkins データを保存するために使用される PVC（永続ボリュームクレーム）をマウントしている必要があるため、簡単に特定できます。
 ```bash
 oc rsh pod_name -c container_name
 ```
-マスターノードポッドがワーカーと同じ名前空間で実行されていない場合、マスターネームスペースをターゲットにして同様の攻撃を試みることができます。これを _jenkins-master_ と呼ぶと仮定します。serviceAccount master-sa が _jenkins-master_ 名前空間に存在する必要があることを忘れないでください（_worker-ns_ 名前空間には存在しない可能性があります）。
+マスターノードポッドがワーカーと同じ名前空間内で実行されていない場合、マスターネームスペースをターゲットにして同様の攻撃を試みることができます。これを _jenkins-master_ と呼ぶと仮定します。serviceAccount master-sa が _jenkins-master_ 名前空間に存在する必要があることを忘れないでください（おそらく _worker-ns_ 名前空間には存在しません）。
 ```groovy
 pipeline {
 stages {
@@ -258,3 +260,7 @@ sh 'env'
 }
 }
 }
+
+
+
+{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/README.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/README.md
@@ -1,4 +1,6 @@
-# OpenShift - 権限昇格
+# OpenShift - 特権昇格
+
+{{#include ../../../banners/hacktricks-training.md}}

 ## サービスアカウントの欠如

@@ -17,3 +19,7 @@ openshift-tekton.md
 {{#ref}}
 openshift-scc-bypass.md
 {{#endref}}
+
+
+
+{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-missing-service-account.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-missing-service-account.md
@@ -1,14 +1,16 @@
 # OpenShift - Missing Service Account

+{{#include ../../../banners/hacktricks-training.md}}
+
 ## Missing Service Account

 クラスターが事前に設定されたテンプレートでデプロイされ、まだ作成されていないサービスアカウントに対して自動的にRoles、RoleBindings、さらにはSCCが設定されることがあります。これにより、これらを作成できる場合に特権昇格が発生する可能性があります。この場合、新しく作成されたSAのトークンと関連するロールまたはSCCを取得できるようになります。同様のケースは、欠落しているSAが欠落しているプロジェクトの一部である場合にも発生します。この場合、プロジェクトを作成し、その後SAを作成できれば、関連するRolesとSCCを取得できます。

 <figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>

-前のグラフでは、Roles BindingsやSCCに表示されるがまだクラスターに作成されていない複数のAbsentProjectを示しています。同様に、AbsentServiceAccountもあります。
+前のグラフでは、Roles BindingsやSCCに表示されているがまだクラスターに作成されていない複数のAbsentProjectを示しています。同様に、AbsentServiceAccountもあります。

-プロジェクトとその中の欠落しているSAを作成できる場合、SAはAbsentServiceAccountをターゲットにしていたRoleまたはSCCを継承します。これにより、特権昇格が発生する可能性があります。
+プロジェクトとその中の欠落しているSAを作成できる場合、SAはAbsentServiceAccountをターゲットにしていたRoleまたはSCCから継承されます。これにより、特権昇格が発生する可能性があります。

 以下の例は、node-exporter SCCが付与された欠落しているSAを示しています：

@@ -21,3 +23,5 @@
 {{#ref}}
 https://github.com/maxDcb/OpenShiftGrapher
 {{#endref}}
+
+{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md
@@ -1,5 +1,7 @@
 # Openshift - SCC バイパス

+{{#include ../../../banners/hacktricks-training.md}}
+
 **このページの元の著者は** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

 ## 特権名前空間
@@ -28,17 +30,17 @@ yes
 $ oc auth can-i patch namespaces
 yes
 ```
-特定のラベル `openshift.io/run-level` は、ユーザーがアプリケーションのためにSCCを回避することを可能にします。RedHatのドキュメントによると、このラベルが使用されると、その名前空間内のすべてのポッドに対してSCCが適用されず、実質的に制限が解除されます。
+特定のラベル `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ファイルを通じてラベルを持つネームスペースを作成するには:
 ```yaml
 apiVersion: v1
 kind: Namespace
@@ -47,13 +49,13 @@ name: evil
 labels:
 openshift.io/run-level: 0
 ```
-今、名前空間で作成されたすべての新しいポッドにはSCCがないはずです。
+今、新しく作成されたすべてのポッドは、名前空間に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がない場合、ポッド定義に制限はありません。これは、悪意のあるポッドがホストシステムに逃げるために簡単に作成できることを意味します。
+SCCがない場合、ポッド定義に制限はありません。これは、悪意のあるポッドがホストシステムに簡単に逃げることができることを意味します。
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -94,7 +96,7 @@ path:

 ### カスタムラベル

-さらに、ターゲットのセットアップに基づいて、前の攻撃シナリオと同様にカスタムラベル/アノテーションが使用される場合があります。作成されていなくても、ラベルは特定のリソースに対して権限を付与したり、制限したりするために使用される可能性があります。
+さらに、ターゲットのセットアップに基づいて、前の攻撃シナリオと同様にカスタムラベル/アノテーションが使用される場合があります。作成されていなくても、ラベルは特定のリソースに対して権限を与えたり、制限したりするために使用される可能性があります。

 いくつかのリソースを読むことができる場合は、カスタムラベルを探してみてください。以下は興味深いリソースのリストです：

@@ -107,11 +109,11 @@ path:
 $ 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の設計に固有のものです。

@@ -119,8 +121,12 @@ OpenShiftでは、前述のように、`openshift.io/run-level`ラベルを持

 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}}
--- a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md
@@ -1,14 +1,16 @@
 # OpenShift - Tekton

+{{#include ../../../banners/hacktricks-training.md}}
+
 **このページの元の著者は** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)

 ### tektonとは

-ドキュメントによると：_Tektonは、開発者がクラウドプロバイダーやオンプレミスシステム全体でビルド、テスト、デプロイを行うことを可能にする、強力で柔軟なオープンソースのCI/CDシステムを作成するためのフレームワークです。_ JenkinsとTektonの両方を使用してアプリケーションをテスト、ビルド、デプロイできますが、TektonはCloud Nativeです。&#x20;
+ドキュメントによると：_Tektonは、CI/CDシステムを作成するための強力で柔軟なオープンソースフレームワークであり、開発者がクラウドプロバイダーやオンプレミスシステムでビルド、テスト、デプロイを行うことを可能にします。_ JenkinsとTektonの両方を使用してアプリケーションをテスト、ビルド、デプロイできますが、TektonはCloud Nativeです。

 Tektonでは、すべてがYAMLファイルで表現されます。開発者は`Pipelines`タイプのカスタムリソース（CR）を作成し、実行したい複数の`Tasks`を指定できます。Pipelineを実行するには、`PipelineRun`タイプのリソースを作成する必要があります。

-tektonがインストールされると、各ネームスペースにpipelineというサービスアカウント（sa）が作成されます。Pipelineが実行されると、YAMLファイルで定義されたタスクを実行するために、このsaを使用して`pipeline`と呼ばれるポッドが生成されます。
+tektonがインストールされると、各ネームスペースに`pipeline`というサービスアカウント（sa）が作成されます。Pipelineが実行されると、YAMLファイルで定義されたタスクを実行するために、このsaを使用して`pipeline`という名前のポッドが生成されます。

 {{#ref}}
 https://tekton.dev/docs/getting-started/pipelines/
@@ -34,7 +36,7 @@ default: "pipelines-scc"

 ### 誤設定

-問題は、パイプラインSAが使用できるデフォルトのSCCがユーザーによって制御可能であることです。これは、名前空間定義のラベルを使用して行うことができます。たとえば、次のyaml定義を使用して名前空間を作成できる場合：
+問題は、パイプラインSAが使用できるデフォルトのSCCがユーザーによって制御可能であることです。これは、名前空間定義のラベルを使用して行うことができます。たとえば、次のYAML定義で名前空間を作成できる場合:
 ```yaml
 apiVersion: v1
 kind: Namespace
@@ -45,7 +47,7 @@ operator.tekton.dev/scc: privileged
 ```
 テクトンオペレーターは、`test-namespace`のパイプラインサービスアカウントにscc privilegedを使用する権限を与えます。これにより、ノードのマウントが可能になります。

-### 修正方法
+### 修正

 Tektonは、`TektonConfig`オブジェクトにラベルを追加することでsccのオーバーライドを制限する方法について文書化しています。

@@ -68,4 +70,4 @@ scc:
 default: "restricted-v2"
 maxAllowed: "privileged"
 ```
-
+{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/openshift-pentesting/openshift-scc.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-scc.md
@@ -1,10 +1,12 @@
 # Openshift - SCC

+{{#include ../../banners/hacktricks-training.md}}
+
 **このページの元の著者は** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

 ## 定義

-OpenShiftの文脈において、SCCは**Security Context Constraints**を指します。Security Context Constraintsは、OpenShiftクラスター上で実行されるポッドの権限を制御するポリシーです。これらは、ポッドが実行されることを許可されるセキュリティパラメータを定義し、どのようなアクションを実行できるか、どのリソースにアクセスできるかを含みます。
+OpenShiftの文脈において、SCCは**Security Context Constraints**を指します。Security Context Constraintsは、OpenShiftクラスター上で実行されるポッドの権限を制御するポリシーです。これらは、ポッドが実行される際のセキュリティパラメータを定義し、どのようなアクションを実行できるか、どのリソースにアクセスできるかを含みます。

 SCCは、管理者がクラスター全体でセキュリティポリシーを強制するのに役立ち、ポッドが適切な権限で実行され、組織のセキュリティ基準に従っていることを保証します。これらの制約は、ポッドのセキュリティのさまざまな側面を指定できます。例えば：

@@ -13,7 +15,7 @@ SCCは、管理者がクラスター全体でセキュリティポリシーを
 3. Read-only root filesystem: 特定のディレクトリ内のファイルをコンテナが変更するのを防ぎます。
 4. Allowed host directories and volumes: ポッドがマウントできるホストディレクトリとボリュームを指定します。
 5. Run as UID/GID: コンテナプロセスが実行されるユーザーおよびグループIDを指定します。
-6. Network policies: ポッドのネットワークアクセスを制御し、エグレストラフィックを制限します。
+6. Network policies: ポッドのネットワークアクセスを制御し、出口トラフィックを制限します。

 SCCを構成することで、管理者はポッドが適切なレベルのセキュリティ隔離とアクセス制御で実行されることを保証し、クラスター内のセキュリティ脆弱性や不正アクセスのリスクを減少させることができます。

@@ -37,7 +39,7 @@ $ oc auth can-i --list | grep securitycontextconstraints #Which scc user can use

 $ oc describe scc $SCC #Check SCC definitions
 ```
-すべてのユーザーは、最も厳格なSCCであるデフォルトのSCC "**restricted**" と "**restricted-v2**" にアクセスできます。
+すべてのユーザーはデフォルトのSCC "**restricted**" および "**restricted-v2**" にアクセスできます。これは最も厳格なSCCです。

 ## SCCの使用

@@ -60,3 +62,7 @@ openshift-privilege-escalation/openshift-scc-bypass.md
 ## 参考文献

 - [https://www.redhat.com/en/blog/managing-sccs-in-openshift](https://www.redhat.com/en/blog/managing-sccs-in-openshift)
+
+
+
+{{#include ../../banners/hacktricks-training.md}}