hacktricks-cloud/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md

Ansible Tower / AWX / Automation controller Security

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

基本情報

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

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

違い

こちらによると、Ansible TowerとAWXの主な違いは受けるサポートであり、Ansible Towerにはロールベースのアクセス制御、カスタムAPIのサポート、ユーザー定義のワークフローなどの追加機能があります。

テクノロジースタック

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

論理コンポーネント

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

ジョブ実行フロー

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

AWXラボの作成とテスト

ドキュメントに従って、docker-composeを使用してAWXを実行することが可能です:

git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version

cd awx

# Build
make docker-compose-build

# Run
make docker-compose

# Or to create a more complex env
MAIN_NODE_TYPE=control EXECUTION_NODE_COUNT=2 COMPOSE_TAG=devel make docker-compose

# Clean and build the UI
docker exec tools_awx_1 make clean-ui ui-devel

# Once migrations are completed and the UI is built, you can begin using AWX. The UI can be reached in your browser at https://localhost:8043/#/home, and the API can be found at https://localhost:8043/api/v2.

# Create an admin user
docker exec -ti tools_awx_1 awx-manage createsuperuser

# Load demo data
docker exec tools_awx_1 awx-manage create_preload_data

RBAC

サポートされている役割

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

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

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

1. システム管理者:

• これは、システム内の任意のリソースにアクセスし、変更する権限を持つスーパーユーザー役割です。
• すべての組織、チーム、プロジェクト、インベントリ、ジョブテンプレートなどを管理できます。

2. システム監査者:

• この役割を持つユーザーは、すべてのシステムデータを表示できますが、変更はできません。
• この役割は、コンプライアンスと監視のために設計されています。

3. 組織の役割:

• 管理者: 組織のリソースに対する完全な制御。
• 監査者: 組織のリソースへの表示専用アクセス。
• メンバー: 特定の権限なしでの組織の基本メンバーシップ。
• 実行: 組織内でジョブテンプレートを実行できます。
• 読み取り: 組織のリソースを表示できます。

4. プロジェクトの役割:

• 管理者: プロジェクトを管理および変更できます。
• 使用: ジョブテンプレートでプロジェクトを使用できます。
• 更新: SCM（ソース管理）を使用してプロジェクトを更新できます。

5. インベントリの役割:

• 管理者: インベントリを管理および変更できます。
• アドホック: インベントリ上でアドホックコマンドを実行できます。
• 更新: インベントリソースを更新できます。
• 使用: ジョブテンプレートでインベントリを使用できます。
• 読み取り: 表示専用アクセス。

6. ジョブテンプレートの役割:

• 管理者: ジョブテンプレートを管理および変更できます。
• 実行: ジョブを実行できます。
• 読み取り: 表示専用アクセス。

7. 資格情報の役割:

• 管理者: 資格情報を管理および変更できます。
• 使用: ジョブテンプレートやその他の関連リソースで資格情報を使用できます。
• 読み取り: 表示専用アクセス。

8. チームの役割:

• メンバー: チームの一部ですが、特定の権限はありません。
• 管理者: チームのメンバーと関連リソースを管理できます。

9. ワークフローの役割:

• 管理者: ワークフローを管理および変更できます。
• 実行: ワークフローを実行できます。
• 読み取り: 表示専用アクセス。

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（または事前ビルドされたバイナリを使用）。

ビルドと実行

# 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に直接インポートできます：

neo4j stop   # if BloodHound CE is running locally
bloodhound-import ansiblehound-output.json

オプションで、カスタムアイコンをアップロードして、新しいノードタイプを視覚的に区別することができます:

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
• BloodHound OSS

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