Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe

2025-12-28 13:43:24 -08:00 · 2025-01-02 00:09:15 +00:00
parent 3c2f3f44a7
commit e3d971b096
225 changed files with 2036 additions and 2044 deletions
--- a/src/pentesting-cloud/openshift-pentesting/openshift-basic-information.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-basic-information.md
@@ -1,6 +1,6 @@
 # OpenShift - 基本情報

-## Kubernetesに関する基本知識 <a href="#a94e" id="a94e"></a>
+## Kubernetesの基本知識 <a href="#a94e" id="a94e"></a>

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

@@ -8,7 +8,7 @@ OpenShiftを使用する前に、Kubernetes環境に慣れていることを確

 ### はじめに

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

 #### CLI

@@ -25,7 +25,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プロファイル、ローカルホストディレクトリのマウントなど。

--- a/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md
@@ -6,7 +6,7 @@

 ## 免責事項

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

 ## 前提条件

@@ -18,7 +18,7 @@ Jenkinsインスタンスは、OpenShiftまたはKubernetesクラスターの両

 ### ビルド

-ビルドがトリガーされると、最初にJenkinsマスターノードによって管理/オーケストレーションされ、その後エージェント/スレーブ/ワーカーに委任されます。このコンテキストでは、マスターノードは単に名前空間内で実行されている通常のポッドです（ワーカーが実行されているものとは異なる場合があります）。ワーカー/スレーブにも同様のことが当てはまりますが、ビルドが終了すると破棄されるのに対し、マスターは常に稼働し続けます。あなたのビルドは通常、Jenkins管理者によって定義されたデフォルトのポッドテンプレートを使用してポッド内で実行されます。
+ビルドがトリガーされると、最初にJenkinsマスターノードによって管理/オーケストレーションされ、その後エージェント/スレーブ/ワーカーに委任されます。このコンテキストでは、マスターノードは単に名前空間内で実行されている通常のポッドです（ワーカーが実行されているものとは異なる場合があります）。ワーカー/スレーブについても同様ですが、ビルドが終了すると破棄されるのに対し、マスターは常に稼働しています。あなたのビルドは通常、Jenkins管理者によって定義されたデフォルトのポッドテンプレートを使用してポッド内で実行されます。

 ### ビルドのトリガー

--- 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
@@ -3,8 +3,8 @@
 **このページの元の著者は** [**Fares**](https://www.linkedin.com/in/fares-siala/)

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

 ## Core functionnality

@@ -34,10 +34,10 @@ sh 'mvn -B -ntp clean install'
 }
 }
 ```
-## Some abuses leveraging pod yaml override
+## 一部のポッド YAML オーバーライドを利用した悪用

-しかし、Kali Linuxのようなアクセス可能なイメージを使用し、そのイメージからプリインストールされたツールを使って任意のコマンドを実行するために悪用される可能性があります。  
-以下の例では、実行中のポッドのserviceaccountトークンを抽出することができます。
+ただし、Kali Linux のようなアクセス可能なイメージを使用し、そのイメージからプリインストールされたツールを使用して任意のコマンドを実行するために悪用される可能性があります。  
+以下の例では、実行中のポッドの serviceaccount トークンを抽出できます。
 ```groovy
 podTemplate(yaml: '''
 apiVersion: v1
@@ -128,7 +128,7 @@ sh 'env'
 }
 }
 ```
-別の例は、名前に基づいてサービスアカウントをマウントしようとします（これは、ビルドを実行しているデフォルトのものよりも多くの権限を持っている可能性があります）。最初に既存のサービスアカウントを推測または列挙する必要があるかもしれません。
+別の例として、名前に基づいてサービスアカウントをマウントしようとするものがあります（これは、ビルドを実行しているデフォルトのものよりも多くの権限を持っている可能性があります）。最初に既存のサービスアカウントを推測または列挙する必要があるかもしれません。
 ```groovy
 pipeline {
 stages {
@@ -165,7 +165,7 @@ sh 'env'

 ## さらに進む

-これに慣れてきたら、JenkinsとKubernetes/Openshiftに関する知識を活用して、誤設定や悪用を見つけてください。
+これに慣れてきたら、JenkinsとKubernetes/Openshiftに関する知識を使って、誤設定や悪用を見つけてください。

 次の質問を自問してください：

@@ -216,15 +216,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 {
--- 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
@@ -2,15 +2,15 @@

 ## Missing Service Account

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

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

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

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

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

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

--- 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,4 +1,4 @@
-# Openshift - SCC bypass
+# Openshift - SCC バイパス

 **このページの元の著者は** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)

@@ -17,7 +17,7 @@

 ## 名前空間ラベル

-RedHatのドキュメントによると、ポッドに対するSCCの適用を無効にする方法があります。以下のいずれかの権限を持っている必要があります：
+RedHatのドキュメントによると、ポッド上でSCCの適用を無効にする方法があります。以下のいずれかの権限を持っている必要があります：

 - 名前空間を作成し、この名前空間にポッドを作成する
 - 名前空間を編集し、この名前空間にポッドを作成する
@@ -28,13 +28,13 @@ 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
 ```
@@ -47,7 +47,7 @@ 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>$
@@ -86,7 +86,7 @@ volumes:
 hostPath:
 path:
 ```
-今では、ホストシステムへの特権昇格が容易になり、その結果、クラスタ全体を掌握し、「cluster-admin」特権を取得することができます。次のページで**Node-Post Exploitation**部分を探してください：
+今では、ホストシステムへの特権昇格が容易になり、その結果、クラスタ全体を掌握し、「cluster-admin」権限を取得することができます。次のページの**Node-Post Exploitation**部分を探してください：

 {{#ref}}
 ../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
@@ -94,9 +94,9 @@ path:

 ### カスタムラベル

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

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

 - Pod
 - Deployment
@@ -107,11 +107,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,7 +119,7 @@ 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)
--- a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md
@@ -2,13 +2,13 @@

 **このページの元の著者は** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)

-### Tektonとは
+### tektonとは

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

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

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

 {{#ref}}
 https://tekton.dev/docs/getting-started/pipelines/
@@ -16,7 +16,7 @@ https://tekton.dev/docs/getting-started/pipelines/

 ### Pipelineサービスアカウントの機能

-デフォルトでは、pipelineサービスアカウントは`pipelines-scc`機能を使用できます。これは、Tektonのグローバルデフォルト設定によるものです。実際、Tektonのグローバル設定も、クラスター内でいくつかのリーダーロールを持っている場合に見ることができる`TektonConfig`というOpenShiftオブジェクトのYAMLです。
+デフォルトでは、pipelineサービスアカウントは`pipelines-scc`機能を使用できます。これは、tektonのグローバルデフォルト設定によるものです。実際、tektonのグローバル設定も、クラスター内でいくつかのリーダーロールを持っている場合に見ることができる`TektonConfig`というオープンシフトオブジェクトのYAMLです。
 ```yaml
 apiVersion: operator.tekton.dev/v1alpha1
 kind: TektonConfig
@@ -34,7 +34,7 @@ default: "pipelines-scc"

 ### 誤設定

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

 ### 修正方法

--- a/src/pentesting-cloud/openshift-pentesting/openshift-scc.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-scc.md
@@ -4,18 +4,18 @@

 ## 定義

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

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

-1. Linuxの能力：特権アクションを実行する能力など、コンテナに利用可能な能力を制限します。
-2. SELinuxコンテキスト：コンテナのSELinuxコンテキストを強制し、プロセスがシステム上のリソースとどのように相互作用するかを定義します。
-3. 読み取り専用のルートファイルシステム：特定のディレクトリ内のファイルをコンテナが変更するのを防ぎます。
-4. 許可されたホストディレクトリとボリューム：ポッドがマウントできるホストディレクトリとボリュームを指定します。
-5. UID/GIDとして実行：コンテナプロセスが実行されるユーザーおよびグループIDを指定します。
-6. ネットワークポリシー：ポッドのネットワークアクセスを制御し、出口トラフィックを制限します。
+1. Linux capabilities: 特権アクションを実行する能力など、コンテナに利用可能な能力を制限します。
+2. SELinux context: コンテナのSELinuxコンテキストを強制し、プロセスがシステム上のリソースとどのように相互作用するかを定義します。
+3. Read-only root filesystem: 特定のディレクトリ内のファイルをコンテナが変更するのを防ぎます。
+4. Allowed host directories and volumes: ポッドがマウントできるホストディレクトリとボリュームを指定します。
+5. Run as UID/GID: コンテナプロセスが実行されるユーザーおよびグループIDを指定します。
+6. Network policies: ポッドのネットワークアクセスを制御し、エグレストラフィックを制限します。

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

 基本的に、ポッドデプロイメントが要求されるたびに、次のような入場プロセスが実行されます：

@@ -46,7 +46,7 @@ $ oc describe scc $SCC #Check SCC definitions
 $ oc get pod MYPOD -o yaml | grep scc
 openshift.io/scc: privileged
 ```
-ユーザーが複数のSCCにアクセスできる場合、システムはセキュリティコンテキスト値に一致するものを利用します。そうでない場合、禁止エラーが発生します。
+ユーザーが複数のSCCにアクセスできる場合、システムはセキュリティコンテキストの値に一致するものを利用します。そうでない場合、禁止エラーが発生します。
 ```bash
 $ oc apply -f evilpod.yaml #Deploy a privileged pod
 Error from server (Forbidden): error when creating "evilpod.yaml": pods "evilpod" is forbidden: unable to validate against any security context constrain