こうした矛盾を感じているLinuxエンジニアは多い。Ansibleによる自動化が進むほど「誰でも実行できてしまうリスク」が顕在化する。開発チームには本番への直接実行を禁止したい。運用チームには特定のPlaybookだけ実行させたい。変更作業は必ずリードエンジニアの承認を経てから走らせたい——。
この記事では、Ansible Automation Controller（旧Ansible Tower）が持つ3つの仕組み——RBAC・承認フロー・監査ログ——を使って、ITチームの権限委譲を安全に設計する方法を解説する。Ansible Automation Platform 2.4 / RHEL 9.4環境で動作確認済みの内容だ。
この記事のポイント
・Ansible Automation Controllerは組織→チーム→ユーザーの3階層でRBACを管理する
・本番変更前に承認を必須化するには、ワークフローの「承認ノード」を使う
・Activity StreamがAPI操作を全件記録し、Splunk/ELKへの外部転送も設定できる
・AWXとの機能差はサポート・認定EE・RHSSO連携の有無のみ（RBAC設計は共通）
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Ansible Automation ControllerとAWXは何が違うか
Ansible Automation Controller（以下Controller）は、Red HatのAnsible Automation Platform（AAP）の中核コンポーネントだ。2021年にAnsible Tower 3.xから改名された。OSS版上流プロジェクトであるAWXをエンタープライズ向けに安定化・認定したもので、GUI・RBAC・承認フロー・Activity Streamといった主要機能はAWXと設計を共有している。両者の差を一覧にまとめる。
| 比較項目 | AWX（OSS） | Ansible Automation Controller（AAP） |
|---|---|---|
| ライセンス | 無料 | 有償（Red Hatサブスクリプション） |
| サポート | コミュニティのみ | Red Hat公式サポート |
| 認定EE | なし | Red Hat認定Execution Environment |
| SSO連携 | LDAP/SAML（手動設定） | RHSSO・Azure AD・Okta（GUIで設定） |
| RBAC機能 | AWX版（同等） | Controller版（同等） |
| 承認フロー | 同等 | 同等 |
| 監査ログ | Activity Stream（同等） | Activity Stream＋認定ログ転送 |
RBACで実現する権限委譲の設計
ControllerのRBACは「組織（Organization）→チーム（Team）→ユーザー（User）」の3階層で管理する。インベントリ・認証情報・プロジェクト・ジョブテンプレートはすべて特定の組織に属し、それぞれのリソースに対してロール（Role）を付与する仕組みだ。1. 組織・チーム・ユーザーの3階層設計
組織はControllerの最上位コンテナだ。複数事業部や複数クライアントを扱う場合は組織を分けてリソースを完全分離できる。同一ControllerサーバーでSaaSのマルチテナント的な運用も可能だ。典型的な設計例を示す。
・組織: production-infra——本番インフラ担当全体のコンテナ
・チーム: ops-team——本番Playbook実行権限を持つ運用メンバー
・チーム: dev-team——ステージング実行のみ許可する開発メンバー
・チーム: audit-team——実行権限なし・閲覧のみのAuditorメンバー
チームを使わず直接ユーザーへロールを付与することも可能だが、メンバーが増えた場合の管理コストが増大する。5人以上のチームではチームベースの付与を推奨する。
2. ロールの種類と付与方法
Controllerに事前定義されているロールを一覧にまとめる。| ロール名 | 主な権限 | 典型的な付与先 |
|---|---|---|
| Admin | 作成・編集・削除・実行すべて | 組織管理者 |
| Execute | ジョブテンプレートの実行のみ | 開発チーム・運用メンバー |
| Project Admin | プロジェクトの作成・同期・削除 | インフラエンジニア |
| Inventory Admin | インベントリの作成・編集・削除 | インフラエンジニア |
| Credential Admin | 認証情報の作成・編集（秘密鍵読み取り不可） | セキュリティ担当 |
| Auditor | 組織内の全オブジェクト閲覧のみ（実行不可） | 監査担当・CISO |
| Read | 特定オブジェクトの閲覧のみ | 関係者への限定共有 |
3. 最小権限設計の実践手順
開発チームに「ステージング用ジョブテンプレートだけ実行させる」設定を例に説明する。まずawx CLIでチームを作成する（事前に
awx loginでControllerに認証しておく）。# チームを作成する $ awx teams create --name "dev-team" --organization "production-infra" --description "開発チーム：ステージング実行のみ許可" id name organization ---- --------- ---------------- 12 dev-team production-infra
# ジョブテンプレートの一覧を確認する $ awx job_templates list --all -f human | grep staging 42 deploy-staging production-infra # ジョブテンプレートID=42 に dev-teamのExecuteロールを付与する $ awx role grant --type team --name "dev-team" --job_template 42 --role execute Role 'execute' granted to team 'dev-team' on job template 'deploy-staging'.
# ジョブテンプレートID=42 のアクセス権一覧を確認する $ awx job_templates access_list --id 42 -f json { "count": 3, "results": [ { "username": "admin", "role": {"name": "Admin"}, "type": "user" }, { "username": "dev-team", "role": {"name": "Execute"}, "type": "team" }, { "username": "audit-user", "role": {"name": "Read"}, "type": "user" } ] }
承認フローの実装
RBACで「誰が何を実行できるか」を制御したら、次は「実行前に承認を経る」仕組みを加える。Controllerではワークフロージョブテンプレートの「承認ノード（Approval Node）」でこれを実現する。通常のジョブテンプレートでは承認ノードを使えないため、本番変更作業はワークフロージョブテンプレートとして設計し直す必要がある。1. ワークフロージョブテンプレートに承認ノードを追加する
ControllerのGUIで次の手順を実行する。・「Templates」→「Add」→「Add workflow job template」→テンプレート名を入力→「Save」
・「Visualizer」タブを開く
・「Add step」でノードを追加→タイプ「Approval」を選択
・タイトルに「本番適用の承認（リードSRE確認）」を入力
・タイムアウトを「3600」秒（1時間）に設定→「Save」
・承認ノードの「On Success」から実際のジョブテンプレートノードを接続する
この構成により「承認ノードが通過しない限り、後続のジョブテンプレートが実行されない」フローが完成する。承認が却下されれば後続ノードには進まずワークフロー全体が「Denied」状態で終了する。
2. 承認者・タイムアウト・通知の設定
承認ノードに「Approve」ロールを持つユーザーだけが承認・却下を行える。承認者を追加するにはノードの「Access」タブから対象ユーザーまたはチームに「Approve」ロールを付与する。承認待ちになった際にSlackやメールで通知するには、Notificationを事前に設定したうえでワークフロージョブテンプレートの「Notifications」タブから「Awaiting approval」イベントに割り当てる。通知が届いた担当者はControllerの「Workflow Approvals」メニューから内容を確認し、GUIで「Approve」または「Deny」を押す。
承認待ちの一覧をAPIで取得する場合は次のコマンドを使う。
# 承認待ちジョブの一覧をAPIで確認する $ curl -sk -H "Authorization: Bearer ${CONTROLLER_TOKEN}" "https://controller.example.com/api/v2/workflow_approvals/?status=pending" | python3 -m json.tool | grep -E '"id"|"name"|"status"' "id": 301, "name": "本番適用の承認（リードSRE確認）", "status": "pending", "id": 302, "name": "本番適用の承認（リードSRE確認）", "status": "pending",
3. 承認の実行と記録
GUIから承認を行うとその操作はActivity Streamにも記録される。「誰が・いつ・どのワークフローを承認（または却下）したか」が後から追跡できる。APIで承認を行う場合は次のように実行する。# ワークフロー承認ID=301 を承認する（APIによる承認操作） $ curl -sk -X POST -H "Authorization: Bearer ${CONTROLLER_TOKEN}" -H "Content-Type: application/json" "https://controller.example.com/api/v2/workflow_approvals/301/approve/" | python3 -m json.tool { "detail": "The workflow approval request was successful." }
監査ログの設計と外部転送
承認フローは「事前制御」だが、監査ログは「事後追跡」を担う。ControllerのActivity Streamは、Controllerに対して行われた全API操作をレコードに残す仕組みだ。GUIでの操作もAPI経由で処理されるため、ほぼすべての変更が記録される。1. Activity Streamで操作ログを確認する
GUIでは右上のベルアイコンから全組織を横断した直近のActivity Streamを確認できる。特定組織・オブジェクト単位のフィルタリングはAPIが便利だ。# 直近10件の操作ログをAPIで取得する $ curl -sk -H "Authorization: Bearer ${CONTROLLER_TOKEN}" "https://controller.example.com/api/v2/activity_stream/?page_size=10&order_by=-timestamp" | python3 -m json.tool | grep -E '"actor"|"username"|"operation"|"object1"|"timestamp"' "actor": { "username": "deploy-user" }, "operation": "create", "object1": "job", "timestamp": "2026-09-28T03:14:22.341Z", "actor": { "username": "sre-lead" }, "operation": "update", "object1": "workflow_approval", "timestamp": "2026-09-28T03:18:57.112Z", "actor": { "username": "admin" }, "operation": "associate", "object1": "user", "timestamp": "2026-09-27T23:05:41.009Z",
2. 外部SIEMへのログ転送設定
Activity Streamのログを外部SIEMに転送するには「Settings」→「Logging」から設定する。対応している転送先と主な設定項目は以下だ。・Splunk HEC——ホスト・ポート・HECトークン・SourceTypeを指定する
・Elastic Stack（ELK）——LogstashのHTTP Inputエンドポイントを指定する
・Sumologic——Sumo Logic HTTP Source URLを指定する
・Loggly——Loggly AuthTokenを指定する
・Generic HTTP——任意のHTTPエンドポイントへJSON形式で転送する
設定後は「Test」ボタンを押してSIEMへのテスト送信が通ることを確認してから「Save」する。ログレベルはデフォルト「WARNING」では情報が少ないため、SIEMへの転送用途では「INFO」に変更することを推奨する。
SIEMへの転送が安定したら、Ansible構成管理をチームに定着させるトレーニングで運用設計の全体像を固めると、Controllerの導入効果がさらに高まる。
「Approve」ボタンが表示されない・ログが残らない場合のトラブルシュート
承認ノードで「Approve」ボタンが表示されない
原因: 承認ノードに対するAdminまたはApproveロールが付与されていない。対処: ControllerのGUIで該当ワークフロージョブテンプレートを開き「Access」タブから承認担当のユーザーまたはチームに「Approve」ロールを付与する。System Administratorロールを持つユーザーはすべての承認操作が可能だ。
Activity Streamに操作ログが残らない
原因: Controllerを経由せずSSHで直接ansible-playbookコマンドを実行した操作は、Activity Streamに記録されない。対処: 全Playbook実行をControllerのジョブテンプレート経由に統一する運用ルールを設ける。SSHによる直接実行を禁止するネットワークACLの適用も有効だ。コントロールノードから本番サーバーへのSSH接続をControllerサービスアカウントのみに限定するとさらに確実になる。
SIEMにControllerのログが届かない
原因1: ControllerサーバーからSIEMのTCPポートへのアウトバウンド通信がファイアウォールでブロックされている。対処1: Controllerサーバー上で疎通確認を行う。
# Splunk HECポートへの疎通確認（Splunkのデフォルトは8088番） $ nc -zv splunk.example.com 8088 Connection to splunk.example.com 8088 port [tcp/*] succeeded! # 疎通できない場合はiptablesのアウトバウンドルールを確認する $ sudo iptables -L OUTPUT -n | grep 8088
対処2: 「Settings」→「Logging」→「Log Level」を「INFO」に変更して「Save」する。
まとめ
Ansible Automation Controllerで権限委譲・承認フロー・監査ログを実装する際のポイントをまとめる。| 機能 | 主な設定箇所 | 解決する課題 |
|---|---|---|
| RBAC（権限委譲） | Organizations / Teams / Roles | チームごとに実行できるPlaybookを最小化する |
| 承認フロー | Workflow Job Template → Approval Node | 本番変更前にリードSREの確認を必須化する |
| 監査ログ（内部） | Activity Stream | 誰がいつ何を実行・変更・承認したか追跡する |
| 監査ログ（外部転送） | Settings → Logging | Splunk/ELKなど既存SIEMでController操作を集中管理する |
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：ansible roleとは｜チームで再利用できる自動化部品の境界を引く考え方
- この記事の属するカテゴリ：Ansibleへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます