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

2026-01-12 13:05:19 -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-ci-cd/ansible-tower-awx-automation-controller-security.md
+++ b/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md
@@ -4,19 +4,19 @@

 ## 基本情報

-**Ansible Tower** またはそのオープンソース版 [**AWX**](https://github.com/ansible/awx) は、**Ansibleのユーザーインターフェース、ダッシュボード、REST API** としても知られています。**ロールベースのアクセス制御**、ジョブスケジューリング、グラフィカルなインベントリ管理を使用して、最新のUIからAnsibleインフラストラクチャを管理できます。TowerのREST APIとコマンドラインインターフェースにより、現在のツールやワークフローに簡単に統合できます。
+**Ansible Tower** またはそのオープンソース版 [**AWX**](https://github.com/ansible/awx) は、**Ansibleのユーザーインターフェース、ダッシュボード、およびREST API**として知られています。**ロールベースのアクセス制御**、ジョブスケジューリング、グラフィカルなインベントリ管理を使用して、最新のUIからAnsibleインフラストラクチャを管理できます。TowerのREST APIとコマンドラインインターフェースにより、現在のツールやワークフローに簡単に統合できます。

-**Automation Controllerは新しい** バージョンのAnsible Towerで、より多くの機能を備えています。
+**Automation Controllerは新しい**バージョンのAnsible Towerで、より多くの機能を備えています。

 ### 違い

-[**こちら**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00)によると、Ansible TowerとAWXの主な違いは受けたサポートであり、Ansible Towerにはロールベースのアクセス制御、カスタムAPIのサポート、ユーザー定義のワークフローなどの追加機能があります。
+[**こちら**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00)によると、Ansible TowerとAWXの主な違いは受けるサポートであり、Ansible Towerにはロールベースのアクセス制御、カスタムAPIのサポート、ユーザー定義のワークフローなどの追加機能があります。

 ### テクノロジースタック

- **Webインターフェース**: これは、ユーザーがインベントリ、資格情報、テンプレート、ジョブを管理できるグラフィカルインターフェースです。直感的に設計されており、オートメーションジョブの状態や結果を理解するのに役立つ視覚化を提供します。
+- **Webインターフェース**: これは、ユーザーがインベントリ、資格情報、テンプレート、およびジョブを管理できるグラフィカルインターフェースです。直感的に設計されており、オートメーションジョブの状態と結果を理解するのに役立つ視覚化を提供します。
 - **REST API**: Webインターフェースでできるすべてのことは、REST APIを介しても行えます。これにより、AWX/Towerを他のシステムと統合したり、インターフェースで通常実行するアクションをスクリプト化したりできます。
- **データベース**: AWX/Towerは、設定、ジョブ結果、その他の必要な運用データを保存するためにデータベース（通常はPostgreSQL）を使用します。
+- **データベース**: AWX/Towerは、構成、ジョブ結果、およびその他の必要な運用データを保存するためにデータベース（通常はPostgreSQL）を使用します。
 - **RabbitMQ**: これは、AWX/Towerが異なるコンポーネント間、特にWebサービスとタスクランナー間で通信するために使用するメッセージングシステムです。
 - **Redis**: Redisは、キャッシュおよびタスクキューのバックエンドとして機能します。

@@ -25,34 +25,34 @@
 - **インベントリ**: インベントリは、**ジョブ**（Ansibleプレイブック）を**実行**できる**ホスト（またはノード）のコレクション**です。AWX/Towerでは、インベントリを定義してグループ化でき、AWS、Azureなどの他のシステムから**ホストリストを取得する**動的インベントリもサポートしています。
 - **プロジェクト**: プロジェクトは、**バージョン管理システム**（Gitなど）から取得した**Ansibleプレイブックのコレクション**です。必要に応じて最新のプレイブックを取得します。
 - **テンプレート**: ジョブテンプレートは、**特定のプレイブックがどのように実行されるか**を定義し、ジョブのための**インベントリ**、**資格情報**、およびその他の**パラメータ**を指定します。
- **資格情報**: AWX/Towerは、SSHキー、パスワード、APIトークンなどの秘密を**管理および保存する**安全な方法を提供します。これらの資格情報は、プレイブックが実行されるときに必要なアクセスを持つように、ジョブテンプレートに関連付けることができます。
- **タスクエンジン**: ここで魔法が起こります。タスクエンジンはAnsibleに基づいて構築されており、**プレイブックを実行する**責任があります。ジョブはタスクエンジンに送信され、指定されたインベントリに対して指定された資格情報を使用してAnsibleプレイブックを実行します。
- **スケジューラーとコールバック**: これらは、特定の時間にジョブを**スケジュール**したり、外部イベントによってトリガーしたりすることを可能にするAWX/Towerの高度な機能です。
+- **資格情報**: AWX/Towerは、SSHキー、パスワード、APIトークンなどの秘密を**管理および保存する**安全な方法を提供します。これらの資格情報は、プレイブックが実行されるときに必要なアクセスを持つようにジョブテンプレートに関連付けることができます。
+- **タスクエンジン**: ここで魔法が起こります。タスクエンジンはAnsibleに基づいて構築されており、**プレイブックを実行する**責任があります。ジョブはタスクエンジンに送信され、指定されたインベントリに対して指定された資格情報を使用してAnsibleプレイブックが実行されます。
+- **スケジューラとコールバック**: これらはAWX/Towerの高度な機能で、**ジョブを特定の時間にスケジュール**したり、外部イベントによってトリガーしたりできます。
 - **通知**: AWX/Towerは、ジョブの成功または失敗に基づいて通知を送信できます。メール、Slackメッセージ、Webhookなど、さまざまな通知手段をサポートしています。
- **Ansibleプレイブック**: Ansibleプレイブックは、構成、デプロイメント、およびオーケストレーションツールです。自動化された再現可能な方法でシステムの望ましい状態を記述します。YAMLで記述され、プレイブックはAnsibleの宣言型自動化言語を使用して、実行する必要がある構成、タスク、およびステップを記述します。
+- **Ansibleプレイブック**: Ansibleプレイブックは、構成、デプロイメント、およびオーケストレーションツールです。自動化された再現可能な方法でシステムの望ましい状態を記述します。YAMLで記述され、プレイブックはAnsibleの宣言的自動化言語を使用して、実行する必要がある構成、タスク、およびステップを記述します。

 ### ジョブ実行フロー

 1. **ユーザーインタラクション**: ユーザーは、**Webインターフェース**または**REST API**を介してAWX/Towerと対話できます。これにより、AWX/Towerが提供するすべての機能にフロントエンドアクセスが提供されます。
 2. **ジョブの開始**:
- ユーザーは、WebインターフェースまたはAPIを介して、**ジョブテンプレート**に基づいてジョブを開始します。
- ジョブテンプレートには、**インベントリ**、**プロジェクト**（プレイブックを含む）、および**資格情報**への参照が含まれています。
- ジョブの開始時に、実行のためにジョブをキューに入れるリクエストがAWX/Towerのバックエンドに送信されます。
+   - ユーザーは、WebインターフェースまたはAPIを介して**ジョブテンプレート**に基づいてジョブを開始します。
+   - ジョブテンプレートには、**インベントリ**、**プロジェクト**（プレイブックを含む）、および**資格情報**への参照が含まれています。
+   - ジョブの開始時に、実行のためにジョブをキューに入れるリクエストがAWX/Towerのバックエンドに送信されます。
 3. **ジョブのキューイング**:
- **RabbitMQ**は、Webコンポーネントとタスクランナー間のメッセージングを処理します。ジョブが開始されると、RabbitMQを使用してタスクエンジンにメッセージが送信されます。
- **Redis**は、実行待ちのキューに入れられたジョブを管理するタスクキューのバックエンドとして機能します。
+   - **RabbitMQ**は、Webコンポーネントとタスクランナー間のメッセージングを処理します。ジョブが開始されると、RabbitMQを使用してタスクエンジンにメッセージが送信されます。
+   - **Redis**は、実行待ちのキューに入れられたジョブを管理するタスクキューのバックエンドとして機能します。
 4. **ジョブの実行**:
- **タスクエンジン**がキューに入れられたジョブを取得します。タスクエンジンは、ジョブに関連付けられたプレイブック、インベントリ、および資格情報に関する必要な情報を**データベース**から取得します。
- 関連する**プロジェクト**から取得したAnsibleプレイブックを使用して、タスクエンジンは指定された**インベントリ**ノードに対して提供された**資格情報**を使用してプレイブックを実行します。
- プレイブックが実行されると、その実行出力（ログ、ファクトなど）がキャプチャされ、**データベース**に保存されます。
+   - **タスクエンジン**は、キューに入れられたジョブを取得します。ジョブに関連付けられたプレイブック、インベントリ、および資格情報に関する必要な情報を**データベース**から取得します。
+   - 関連する**プロジェクト**から取得したAnsibleプレイブックを使用して、タスクエンジンは指定された**インベントリ**ノードに対して提供された**資格情報**を使用してプレイブックを実行します。
+   - プレイブックが実行されると、その実行出力（ログ、ファクトなど）がキャプチャされ、**データベース**に保存されます。
 5. **ジョブ結果**:
- プレイブックの実行が終了すると、結果（成功、失敗、ログ）が**データベース**に保存されます。
- ユーザーは、Webインターフェースを介して結果を表示したり、REST APIを介してクエリを実行したりできます。
- ジョブの結果に基づいて、**通知**が送信され、ユーザーや外部システムにジョブの状態を通知できます。通知は、メール、Slackメッセージ、Webhookなどです。
+   - プレイブックの実行が終了すると、結果（成功、失敗、ログ）が**データベース**に保存されます。
+   - ユーザーは、Webインターフェースを介して結果を表示したり、REST APIを介してクエリを実行したりできます。
+   - ジョブの結果に基づいて、**通知**が送信され、ユーザーや外部システムにジョブの状態を通知できます。通知はメール、Slackメッセージ、Webhookなどです。
 6. **外部システムとの統合**:
- **インベントリ**は外部システムから動的に取得でき、AWX/TowerはAWS、Azure、VMwareなどのソースからホストを取得できます。
- **プロジェクト**（プレイブック）はバージョン管理システムから取得でき、ジョブ実行中に最新のプレイブックを使用することが保証されます。
- **スケジューラーとコールバック**は、他のシステムやツールと統合するために使用でき、AWX/Towerが外部トリガーに反応したり、事前に決められた時間にジョブを実行したりすることができます。
+   - **インベントリ**は外部システムから動的に取得でき、AWX/TowerはAWS、Azure、VMwareなどのソースからホストを取得できます。
+   - **プロジェクト**（プレイブック）はバージョン管理システムから取得でき、ジョブ実行中に最新のプレイブックを使用することが保証されます。
+   - **スケジューラとコールバック**は、他のシステムやツールと統合するために使用でき、AWX/Towerが外部トリガーに反応したり、事前に決められた時間にジョブを実行したりします。

 ### AWXラボの作成とテスト

@@ -86,24 +86,24 @@ docker exec tools_awx_1 awx-manage create_preload_data

 ### サポートされている役割

-最も特権のある役割は**システム管理者**と呼ばれます。この役割を持つ者は**何でも変更することができます**。
+最も特権のある役割は**システム管理者**と呼ばれます。この役割を持つ者は**何でも変更**できます。

-**ホワイトボックスセキュリティ**レビューでは、**システム監査役**が必要で、これにより**すべてのシステムデータを表示**できますが、変更はできません。もう一つの選択肢は**組織監査役**を取得することですが、前者を取得する方が良いでしょう。
+**ホワイトボックスセキュリティ**レビューでは、**システム監査者役割**が必要で、これにより**すべてのシステムデータを表示**できますが、変更はできません。別の選択肢として**組織監査者役割**を取得することもできますが、前者を取得する方が良いでしょう。

 <details>

 <summary>利用可能な役割の詳細な説明を表示するにはここを展開してください</summary>

 1. **システム管理者**:
- これは、システム内の任意のリソースにアクセスし、変更する権限を持つスーパーユーザーの役割です。
- 彼らはすべての組織、チーム、プロジェクト、インベントリ、ジョブテンプレートなどを管理できます。
-2. **システム監査役**:
- この役割を持つユーザーはすべてのシステムデータを表示できますが、変更はできません。
- この役割はコンプライアンスと監視のために設計されています。
+- これは、システム内の任意のリソースにアクセスし、変更する権限を持つスーパーユーザー役割です。
+- すべての組織、チーム、プロジェクト、インベントリ、ジョブテンプレートなどを管理できます。
+2. **システム監査者**:
+- この役割を持つユーザーは、すべてのシステムデータを表示できますが、変更はできません。
+- この役割は、コンプライアンスと監視のために設計されています。
 3. **組織の役割**:
 - **管理者**: 組織のリソースに対する完全な制御。
- **監査役**: 組織のリソースへの表示専用アクセス。
- **メンバー**: 特定の権限なしで組織の基本メンバーシップ。
+- **監査者**: 組織のリソースへの表示専用アクセス。
+- **メンバー**: 特定の権限なしでの組織の基本メンバーシップ。
 - **実行**: 組織内でジョブテンプレートを実行できます。
 - **読み取り**: 組織のリソースを表示できます。
 4. **プロジェクトの役割**:
@@ -112,7 +112,7 @@ docker exec tools_awx_1 awx-manage create_preload_data
 - **更新**: SCM（ソース管理）を使用してプロジェクトを更新できます。
 5. **インベントリの役割**:
 - **管理者**: インベントリを管理および変更できます。
- **アドホック**: インベントリに対してアドホックコマンドを実行できます。
+- **アドホック**: インベントリ上でアドホックコマンドを実行できます。
 - **更新**: インベントリソースを更新できます。
 - **使用**: ジョブテンプレートでインベントリを使用できます。
 - **読み取り**: 表示専用アクセス。
@@ -134,4 +134,71 @@ docker exec tools_awx_1 awx-manage create_preload_data

 </details>

+## AnsibleHoundによる列挙と攻撃経路マッピング
+
+`AnsibleHound`は、Goで書かれたオープンソースのBloodHound *OpenGraph*コレクターで、**読み取り専用**のAnsible Tower/AWX/Automation Controller APIトークンを完全な権限グラフに変換し、BloodHound（またはBloodHound Enterprise）内で分析できるようにします。
+
+### これはなぜ便利ですか？
+1. Tower/AWX REST APIは非常に豊富で、インスタンスが知っている**すべてのオブジェクトとRBAC関係**を公開しています。
+2. 最も低い権限（**読み取り**）のトークンでも、すべてのアクセス可能なリソース（組織、インベントリ、ホスト、資格情報、プロジェクト、ジョブテンプレート、ユーザー、チーム…）を再帰的に列挙することが可能です。
+3. 生データがBloodHoundスキーマに変換されると、Active Directory評価で非常に人気のある*攻撃経路*の視覚化機能を得ることができますが、今度はあなたのCI/CD環境に向けられています。
+
+したがって、セキュリティチーム（および攻撃者！）は：
+* **誰が何の管理者になれるか**を迅速に理解できます。
+* **特権のないアカウントから到達可能な資格情報やホスト**を特定できます。
+* 複数の「読み取り ➜ 使用 ➜ 実行 ➜ 管理者」エッジを連鎖させて、Towerインスタンスまたは基盤となるインフラストラクチャを完全に制御できます。
+
+### 前提条件
+* HTTPS経由でアクセス可能なAnsible Tower / AWX / Automation Controller。
+* **読み取り**のみにスコープを持つユーザーAPIトークン（*ユーザー詳細 → トークン → トークンを作成 → スコープ = 読み取り*から作成）。
+* コレクターをコンパイルするためのGo ≥ 1.20（または事前ビルドされたバイナリを使用）。 
+
+### ビルドと実行
+```bash
+# Compile the collector
+cd collector
+go build . -o build/ansiblehound
+
+# Execute against the target instance
+./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN"
+```
+内部的にAnsibleHoundは、少なくとも以下のエンドポイントに対して*ページネーション*された`GET`リクエストを実行し、すべてのJSONオブジェクトで返される`related`リンクを自動的に追跡します:
+```
+/api/v2/organizations/
+/api/v2/inventories/
+/api/v2/hosts/
+/api/v2/job_templates/
+/api/v2/projects/
+/api/v2/credentials/
+/api/v2/users/
+/api/v2/teams/
+```
+すべての収集されたページは、ディスク上の単一のJSONファイルにマージされます（デフォルト: `ansiblehound-output.json`）。
+
+### BloodHound 変換
+生のTowerデータは、`AT`（Ansible Tower）でプレフィックスされたカスタムノードを使用して**BloodHound OpenGraph**に**変換**されます：
+* `ATOrganization`, `ATInventory`, `ATHost`, `ATJobTemplate`, `ATProject`, `ATCredential`, `ATUser`, `ATTeam`
+
+および関係/特権をモデル化するエッジ：
+* `ATContains`, `ATUses`, `ATExecute`, `ATRead`, `ATAdmin`
+
+結果はBloodHoundに直接インポートできます：
+```bash
+neo4j stop   # if BloodHound CE is running locally
+bloodhound-import ansiblehound-output.json
+```
+オプションで、**カスタムアイコン**をアップロードして、新しいノードタイプを視覚的に区別することができます:
+```bash
+python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"
+```
+### Defensive & Offensive Considerations
+* *Read* トークンは通常無害と見なされますが、**完全なトポロジーとすべての認証情報メタデータ**を漏洩します。機密情報として扱ってください！
+* **最小特権**を強制し、未使用のトークンを回転/取り消ししてください。
+* APIの過剰な列挙（複数の連続した `GET` リクエスト、高いページネーション活動）を監視してください。
+* 攻撃者の視点から見ると、これはCI/CDパイプライン内での完璧な*初期の足場 → 特権昇格*手法です。
+
+## References
+* [AnsibleHound – BloodHound Collector for Ansible Tower/AWX](https://github.com/TheSleekBoyCompany/AnsibleHound)
+* [BloodHound OSS](https://github.com/BloodHoundAD/BloodHound)
+
 {{#include ../banners/hacktricks-training.md}}
--- a/src/pentesting-ci-cd/concourse-security/concourse-architecture.md
+++ b/src/pentesting-ci-cd/concourse-security/concourse-architecture.md
@@ -1,26 +1,26 @@
 # Concourse Architecture

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

+## Concourse Architecture
+
 [**Concourse ドキュメントからの関連データ:**](https://concourse-ci.org/internals.html)

 ### Architecture

 ![](<../../images/image (187).png>)

-#### ATC: ウェブ UI & ビルドスケジューラ
+#### ATC: web UI & build scheduler

-ATCはConcourseの中心です。**ウェブ UI と API**を実行し、すべてのパイプラインの**スケジューリング**を担当します。**PostgreSQL**に接続し、パイプラインデータ（ビルドログを含む）を保存します。
+ATCはConcourseの中心です。**web UIとAPI**を実行し、すべてのパイプラインの**スケジューリング**を担当します。**PostgreSQL**に接続し、パイプラインデータ（ビルドログを含む）を保存します。

-[checker](https://concourse-ci.org/checker.html)の責任は、リソースの新しいバージョンを継続的にチェックすることです。[scheduler](https://concourse-ci.org/scheduler.html)はジョブのビルドをスケジュールする責任があり、[build tracker](https://concourse-ci.org/build-tracker.html)はスケジュールされたビルドを実行する責任があります。[garbage collector](https://concourse-ci.org/garbage-collector.html)は、未使用または古くなったオブジェクト（コンテナやボリュームなど）を削除するためのクリーンアップメカニズムです。
+[checker](https://concourse-ci.org/checker.html)の責任は、新しいリソースのバージョンを継続的にチェックすることです。[scheduler](https://concourse-ci.org/scheduler.html)はジョブのビルドをスケジュールする責任があり、[build tracker](https://concourse-ci.org/build-tracker.html)はスケジュールされたビルドを実行する責任があります。[garbage collector](https://concourse-ci.org/garbage-collector.html)は、未使用または古くなったオブジェクト（コンテナやボリュームなど）を削除するためのクリーンアップメカニズムです。

-#### TSA: ワーカーの登録 & 転送
+#### TSA: worker registration & forwarding

-TSAは**カスタムビルドのSSHサーバー**であり、[**ワーカー**](https://concourse-ci.org/internals.html#architecture-worker)を[ATC](https://concourse-ci.org/internals.html#component-atc)に安全に**登録**するためだけに使用されます。
+TSAは**カスタムビルドのSSHサーバー**であり、[**workers**](https://concourse-ci.org/internals.html#architecture-worker)を[ATC](https://concourse-ci.org/internals.html#component-atc)に安全に**登録**するためだけに使用されます。

-TSAは**デフォルトでポート `2222`**でリッスンし、通常は[ATC](https://concourse-ci.org/internals.html#component-atc)と同じ場所に配置され、ロードバランサーの背後にあります。
+TSAは**デフォルトでポート`2222`**でリッスンし、通常は[ATC](https://concourse-ci.org/internals.html#component-atc)と同じ場所に配置され、ロードバランサーの背後にあります。

 **TSAはSSH接続を介してCLIを実装し、**[**これらのコマンド**](https://concourse-ci.org/internals.html#component-tsa)をサポートします。

@@ -28,8 +28,8 @@ TSAは**デフォルトでポート `2222`**でリッスンし、通常は[ATC](

 タスクを実行するために、Concourseはワーカーを持つ必要があります。これらのワーカーは[TSA](https://concourse-ci.org/internals.html#component-tsa)を介して**自分自身を登録**し、[**Garden**](https://github.com/cloudfoundry-incubator/garden)と[**Baggageclaim**](https://github.com/concourse/baggageclaim)のサービスを実行します。

- **Garden**: これは**コンテナ管理API**で、通常は**ポート 7777**で**HTTP**を介して実行されます。
- **Baggageclaim**: これは**ボリューム管理API**で、通常は**ポート 7788**で**HTTP**を介して実行されます。
+- **Garden**: これは**Container Manage API**で、通常は**ポート7777**で**HTTP**を介して実行されます。
+- **Baggageclaim**: これは**Volume Management API**で、通常は**ポート7788**で**HTTP**を介して実行されます。

 ## References

--- a/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md
+++ b/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md
@@ -1,50 +1,52 @@
 # Concourse Enumeration & Attacks

-## Concourse Enumeration & Attacks
-
 {{#include ../../banners/hacktricks-training.md}}

-### ユーザーロールと権限
+## Concourse Enumeration & Attacks

-Concourse には5つのロールがあります：

- _Concourse_ **Admin**: このロールは **メインチーム**（デフォルトの初期 concourse チーム）の所有者にのみ与えられます。管理者は **他のチームを構成**できます（例：`fly set-team`、`fly destroy-team`...）。このロールの権限は RBAC によって影響を受けません。
- **owner**: チームの所有者は **チーム内のすべてを変更**できます。
- **member**: チームメンバーは **チームの資産内で読み書き**できますが、チーム設定を変更することはできません。
- **pipeline-operator**: パイプラインオペレーターはビルドのトリガーやリソースのピン留めなどの **パイプライン操作**を実行できますが、パイプライン設定を更新することはできません。
- **viewer**: チームのビューワーはチームとそのパイプラインに対して **「読み取り専用」アクセス**を持っています。
+
+### User Roles & Permissions
+
+Concourseには5つの役割があります：
+
+- _Concourse_ **Admin**: この役割は**メインチーム**（デフォルトの初期concourseチーム）の所有者にのみ与えられます。管理者は**他のチームを構成**できます（例：`fly set-team`、`fly destroy-team`...）。この役割の権限はRBACによって影響を受けません。
+- **owner**: チームの所有者は**チーム内のすべてを変更**できます。
+- **member**: チームメンバーは**チームの資産内で読み書き**できますが、チーム設定を変更することはできません。
+- **pipeline-operator**: パイプラインオペレーターはビルドのトリガーやリソースのピン留めなどの**パイプライン操作**を実行できますが、パイプライン設定を更新することはできません。
+- **viewer**: チームのビューワーはチームとそのパイプラインに**「読み取り専用」アクセス**を持っています。

 > [!NOTE]
-> さらに、**owner、member、pipeline-operator、viewer のロールの権限は** RBAC を構成することで **変更可能です**（具体的にはそのアクションを構成します）。詳細については、[https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)を参照してください。
+> さらに、**owner、member、pipeline-operator、viewerの役割の権限はRBACを構成することで変更**できます（具体的にはそのアクションを構成します）。詳細については、[https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)を参照してください。

-Concourse は **チーム内にパイプラインをグループ化**します。したがって、チームに属するユーザーはそれらのパイプラインを管理でき、**複数のチーム**が存在する可能性があります。ユーザーは複数のチームに属し、それぞれのチーム内で異なる権限を持つことができます。
+Concourseは**チーム内にパイプラインをグループ化**します。したがって、チームに属するユーザーはそれらのパイプラインを管理でき、**複数のチーム**が存在する可能性があります。ユーザーは複数のチームに属し、それぞれのチーム内で異なる権限を持つことができます。

 ### Vars & Credential Manager

-YAML 設定では、`((_source-name_:_secret-path_._secret-field_))` の構文を使用して値を構成できます。\
-[ドキュメントから：](https://concourse-ci.org/vars.html#var-syntax) **source-name はオプション**であり、省略した場合は [クラスター全体の資格情報マネージャー](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) が使用されるか、値が [静的に提供される](https://concourse-ci.org/vars.html#static-vars)場合があります。\
-**オプションの \_secret-field**\_ は取得した秘密のフィールドを読み取るために指定します。省略した場合、資格情報マネージャーはフィールドが存在する場合、取得した資格情報から「デフォルトフィールド」を読み取ることを選択することがあります。\
-さらに、_**secret-path**_ と _**secret-field**_ は、`。` や `:` のような **特殊文字**を含む場合、二重引用符 `"..."` で囲むことができます。たとえば、`((source:"my.secret"."field:1"))` は _secret-path_ を `my.secret` に、_secret-field_ を `field:1` に設定します。
+YAML構成では、`((_source-name_:_secret-path_._secret-field_))`という構文を使用して値を構成できます。\
+[ドキュメントから：](https://concourse-ci.org/vars.html#var-syntax) **source-nameはオプション**であり、省略した場合は[クラスター全体の資格情報マネージャー](https://concourse-ci.org/vars.html#cluster-wide-credential-manager)が使用されるか、値が[静的に](https://concourse-ci.org/vars.html#static-vars)提供される場合があります。\
+**オプションの\_secret-field**は、取得した秘密から読み取るフィールドを指定します。省略した場合、資格情報マネージャーはフィールドが存在する場合、取得した資格情報から「デフォルトフィールド」を読み取ることを選択する場合があります。\
+さらに、_**secret-path**_と_**secret-field**_は、`。`や`:`のような**特殊文字**を含む場合、二重引用符`"..."`で囲むことができます。たとえば、`((source:"my.secret"."field:1"))`は、_secret-path_を`my.secret`に、_secret-field_を`field:1`に設定します。

-#### 静的変数
+#### Static Vars

-静的変数は **タスクステップ**で指定できます：
+静的変数は**タスクステップ**で指定できます：
 ```yaml
 - task: unit-1.13
 file: booklit/ci/unit.yml
 vars: { tag: 1.13 }
 ```
-以下の `fly` **引数**を使用します：
+Or using the following `fly` **arguments**:

 - `-v` または `--var` `NAME=VALUE` は、文字列 `VALUE` を変数 `NAME` の値として設定します。
 - `-y` または `--yaml-var` `NAME=VALUE` は、`VALUE` を YAML として解析し、変数 `NAME` の値として設定します。
 - `-i` または `--instance-var` `NAME=VALUE` は、`VALUE` を YAML として解析し、インスタンス変数 `NAME` の値として設定します。インスタンス変数について詳しくは [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) を参照してください。
 - `-l` または `--load-vars-from` `FILE` は、変数名と値のマッピングを含む YAML ドキュメント `FILE` を読み込み、すべてを設定します。

-#### 認証情報管理
+#### Credential Management

 パイプラインで **Credential Manager を指定する方法** はいくつかあります。詳細は [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html) をお読みください。\
-さらに、Concourse は異なる認証情報マネージャーをサポートしています：
+さらに、Concourse はさまざまな資格情報マネージャーをサポートしています：

 - [The Vault credential manager](https://concourse-ci.org/vault-credential-manager.html)
 - [The CredHub credential manager](https://concourse-ci.org/credhub-credential-manager.html)
@@ -57,13 +59,13 @@ vars: { tag: 1.13 }
 - [Retrying failed fetches](https://concourse-ci.org/creds-retry-logic.html)

 > [!CAUTION]
-> **Concourse** に対して何らかの **書き込みアクセス** がある場合、ジョブを作成して **それらの秘密を流出させる** ことができることに注意してください。
+> Concourse に対して **書き込みアクセス** がある場合、**それらの秘密を外部に持ち出す** ジョブを作成できることに注意してください。Concourse はそれらにアクセスできる必要があります。

-### Concourse 列挙
+### Concourse Enumeration

-Concourse 環境を列挙するには、まず **有効な認証情報を収集する** か、`.flyrc` 設定ファイルにある **認証トークン** を見つける必要があります。
+Concourse 環境を列挙するには、まず **有効な資格情報を収集する** か、`.flyrc` 設定ファイルにある **認証トークンを見つける** 必要があります。

-#### ログインと現在のユーザー列挙
+#### Login and Current User enum

 - ログインするには、**エンドポイント**、**チーム名**（デフォルトは `main`）、および **ユーザーが所属するチーム** を知っている必要があります：
 - `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]`
@@ -75,9 +77,9 @@ Concourse 環境を列挙するには、まず **有効な認証情報を収集
 - `fly -t <target> userinfo`

 > [!NOTE]
-> **API トークン** はデフォルトで `$HOME/.flyrc` に **保存** されるため、マシンを略奪する際にそこに認証情報が見つかる可能性があります。
+> **API トークン** はデフォルトで `$HOME/.flyrc` に **保存** されます。マシンを略奪する際に、そこに資格情報が見つかる可能性があります。

-#### チームとユーザー
+#### Teams & Users

 - チームのリストを取得：
 - `fly -t <target> teams`
@@ -86,15 +88,15 @@ Concourse 環境を列挙するには、まず **有効な認証情報を収集
 - ユーザーのリストを取得：
 - `fly -t <target> active-users`

-#### パイプライン
+#### Pipelines

 - **パイプラインのリスト**：
 - `fly -t <target> pipelines -a`
- パイプラインの YAML を **取得**（**機密情報**が定義に含まれている可能性があります）：
+- パイプラインの YAML を **取得**（定義に **機密情報** が含まれている可能性があります）：
 - `fly -t <target> get-pipeline -p <pipeline-name>`
- すべてのパイプライン **設定された変数** を取得：
+- すべてのパイプラインの **設定された変数** を取得：
 - `for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done`
- 使用されているすべての **パイプラインの秘密の名前** を取得（ジョブを作成/変更したり、コンテナをハイジャックしたりできる場合、流出させることができます）：
+- 使用されているすべての **パイプラインの秘密の名前** を取得（ジョブを作成/変更したり、コンテナをハイジャックしたりできる場合、それらを外部に持ち出すことができます）：
 ```bash
 rm /tmp/secrets.txt;
 for pipename in $(fly -t onelogin pipelines | grep -Ev "^id" | awk '{print $2}'); do
@@ -125,7 +127,7 @@ rm /tmp/secrets.txt

 #### シークレットとパラメータの列挙

-前のセクションでは、パイプラインで使用される**すべてのシークレット名と変数**を**取得する方法**を見ました。**変数には機密情報が含まれている可能性があり**、**シークレットの名前は後でそれらを盗むために役立ちます**。
+前のセクションでは、パイプラインで使用される**すべてのシークレット名と変数**を**取得する**方法を見ました。**変数には機密情報が含まれている可能性があり**、**シークレットの名前は後でそれらを盗むために役立ちます**。

 #### 実行中または最近実行されたコンテナ内のセッション

@@ -136,8 +138,8 @@ fly -t tutorial intercept # To be presented a prompt with all the options
 ```
 これらの権限があれば、次のことができるかもしれません：

- **コンテナ**内の**秘密**を**盗む**
- **ノード**に**エスケープ**しようとする
+- **コンテナ**内の**秘密**を盗む
+- ノードに**エスケープ**しようとする
 - **クラウドメタデータ**エンドポイントを列挙/悪用する（ポッドおよびノードから、可能であれば）

 #### パイプラインの作成/変更
@@ -199,9 +201,9 @@ fly -t tutorial execute --privileged --config task_config.yml
 ```
 #### 特権タスクからノードへのエスケープ

-前のセクションでは、**concourseで特権タスクを実行する方法**を見ました。これは、dockerコンテナの特権フラグと同じアクセスをコンテナに与えるわけではありません。例えば、/devにノードのファイルシステムデバイスは表示されないため、エスケープはより「複雑」になる可能性があります。
+前のセクションでは、**concourseで特権タスクを実行する方法**を見ました。これは、dockerコンテナの特権フラグと同じアクセスをコンテナに与えるわけではありません。例えば、/devにノードのファイルシステムデバイスは表示されないため、エスケープは「複雑」になる可能性があります。

-次のPoCでは、いくつかの小さな修正を加えてrelease_agentを使用してエスケープします：
+次のPoCでは、いくつかの小さな変更を加えてrelease_agentを使用してエスケープします：
 ```bash
 # Mounts the RDMA cgroup controller and create a child cgroup
 # If you're following along and get "mount: /tmp/cgrp: special device cgroup does not exist"
@@ -306,7 +308,7 @@ CONCOURSE_ADD_LOCAL_USER=test:test
 ```
 その資格情報を使用して**ウェブサーバーにログイン**し、**特権コンテナを作成してノードにエスケープ**することができます。

-環境内では、concourseが使用する**postgresql**インスタンスにアクセスするための情報（アドレス、**ユーザー名**、**パスワード**、およびデータベースなどの情報）も見つけることができます。
+環境内では、concourseが使用する**postgresql**インスタンスにアクセスするための情報（アドレス、**ユーザー名**、**パスワード**、およびデータベースなどの情報）も見つけることができます：
 ```bash
 env | grep -i postg
 CONCOURSE_RELEASE_POSTGRESQL_PORT_5432_TCP_ADDR=10.107.191.238
@@ -332,10 +334,10 @@ select * from users;
 > [!WARNING]
 > これはサービスに関するいくつかの興味深いメモですが、ローカルホストでのみリッスンしているため、これらのメモは私たちがすでに利用したことのない影響をもたらすことはありません。

-デフォルトでは、各concourseワーカーはポート7777で[**Garden**](https://github.com/cloudfoundry/garden)サービスを実行します。このサービスは、Webマスターがワーカーに**実行する必要があること**（イメージをダウンロードし、各タスクを実行する）を示すために使用されます。これは攻撃者にとってはかなり良いように思えますが、いくつかの優れた保護があります：
+デフォルトでは、各concourseワーカーはポート7777で[**Garden**](https://github.com/cloudfoundry/garden)サービスを実行します。このサービスは、ウェブマスターがワーカーに**実行する必要があること**（イメージをダウンロードし、各タスクを実行する）を示すために使用されます。これは攻撃者にとってはかなり良いように思えますが、いくつかの優れた保護があります：

- それは**ローカルにのみ公開されています**（127..0.0.1）し、ワーカーが特別なSSHサービスでWebに対して認証するときに、各ワーカー内の各Gardenサービスと**通信するためのトンネル**が作成されると思います。
- Webサーバーは**数秒ごとに実行中のコンテナを監視しており**、**予期しない**コンテナは**削除されます**。したがって、**カスタムコンテナを実行したい**場合は、Webサーバーとガーデンサービス間の**通信**を**改ざん**する必要があります。
+- それは**ローカルにのみ公開されています**（127.0.0.1）し、ワーカーが特別なSSHサービスでウェブに対して認証するときに、ウェブサーバーが**各ワーカー内の各Gardenサービスと話すためのトンネルが作成される**と思います。
+- ウェブサーバーは**数秒ごとに実行中のコンテナを監視しており**、**予期しない**コンテナは**削除されます**。したがって、**カスタムコンテナを実行したい場合**は、ウェブサーバーとガーデンサービス間の**通信を改ざんする**必要があります。

 Concourseワーカーは高いコンテナ特権で実行されます：
 ```
@@ -348,7 +350,7 @@ Capabilities:
 BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
 Seccomp: disabled
 ```
-しかし、ノードの/devデバイスやrelease_agentを**マウント**するような技術は**機能しません**（ノードのファイルシステムを持つ実際のデバイスにはアクセスできず、仮想デバイスのみです）。ノードのプロセスにアクセスできないため、カーネルエクスプロイトなしでノードから脱出することは複雑になります。
+しかし、ノードの/devデバイスやrelease_agentを**マウント**するような技術は**機能しません**（ノードのファイルシステムを持つ実際のデバイスにはアクセスできず、仮想デバイスのみが存在します）。ノードのプロセスにアクセスできないため、カーネルエクスプロイトなしでノードから脱出するのは複雑になります。

 > [!NOTE]
 > 前のセクションでは特権コンテナから脱出する方法を見ましたので、**現在の** **ワーカー**によって作成された**特権コンテナ**でコマンドを**実行**できる場合、**ノードに脱出**できる可能性があります。
@@ -376,7 +378,7 @@ nsenter --target 76011 --mount --uts --ipc --net --pid -- sh
 ```
 **新しい特権コンテナの作成**

-ランダムなUIDを実行するだけで、新しいコンテナを非常に簡単に作成し、その上で何かを実行できます：
+ランダムなUIDを実行するだけで、新しいコンテナを非常に簡単に作成し、その上で何かを実行できます:
 ```bash
 curl -X POST http://127.0.0.1:7777/containers \
 -H 'Content-Type: application/json' \
@@ -411,6 +413,6 @@ Accept-Encoding: gzip.
 ```
 ## 参考文献

- https://concourse-ci.org/vars.html
+- [https://concourse-ci.org/vars.html](https://concourse-ci.org/vars.html)

 {{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md
@@ -1 +1,3 @@
-# Gh Actions - アーティファクトポイズニング
+# Gh Actions - Artifact Poisoning
+
+{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md
@@ -1 +1,3 @@
-# GH Actions - キャッシュポイズニング
+# GH Actions - Cache Poisoning
+
+{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
@@ -1 +1,3 @@
-# Gh Actions - コンテキストスクリプトインジェクション
+# Gh Actions - Context Script Injections
+
+{{#include ../../../banners/hacktricks-training.md}}