【後編】Red Hat Ansible Automation Platform(AAP)×Open Policy Agent(OPA)の連携方法と実践

2026.03.10

ご挨拶

ビジネス開発本部に所属しております伊藤と申します。

前編に続き本記事は後編としまして、Ansible Automation Platform(以下、AAPと省略します)とOpen Policy Agent(以下、OPAと省略します)を組み合わせたポリシーチェックについて、サンプルを利用して実際の動作結果をご紹介いたします。

もしまだ前編をご覧になっていないようでしたら、ぜひとも前編からご覧頂ければ幸いです。

ライター：伊藤　明央: Red Hat社の自動化ツールであるAnsible、及びAnsible Automation Platformなど、インフラ自動化技術の主幹として活動しております。

AAP×OPAのおさらい

前編ではAAPがポリシーチェックの連携機能としてOPAをサポートした事と、動作概要や準備、設定方法などをご紹介いたしました。この後編では、実際にGitHubに公開されているサンプルスクリプトを用いて、動作の様子をご紹介いたします。

AAPに入力されるextra_varsのキーチェック

参考リンクにありますGitHubにて公開されているサンプルをベースに、スクリプトの内容を説明します。

1～3行目のpackageやimportはおまじないの行となりますが、このサンプルスクリプトは、『“allowed”というキーだけ』がextra_varsで渡されることを期待するregoスクリプトとなっております。
6行目の①で、ポリシーチェックするキー名(“allowed”)を設定し、9行目の②では“default extra_vars_allowlist"でデフォルトの返り値を設定します。このスクリプトでは、最終的な出力として“extra_vars_allowlist”がtrue時のみポリシーチェックが成功(=正常)となり、それ以外の値の場合は失敗となるので注意が必要です。
15行目の③から、ポリシーチェックのメインルーチン部分となります。“result if{ … }"という表記は他の言語ではあまり見かけないかと思われますが、ifブロック内の評価を行い、“result”値に値が存在する場合(このスクリプトの場合は24行目のブロック)は、“extra_vars_allowlist"にその値が返る評価となります。
23行目④にある“count()"の評価が真(“allowed”以外に入力されたキーが1つ以上存在)であれば、24行目のresultが評価された結果allowedは“false”となり、最終的に“extra_vars_allowlist"が“false”となります。
また、23行目④の結果が偽であれば、その時点でブロックの評価が終了するため、9行目②で与えたdefault値が“extra_vars_allowlist"に保持されるという仕組みになっています。

動作の確認と結果

上記のようにポリシーを『ジョブテンプレート』に適用すると、ジョブテンプレート起動時に評価されますので、以下の様な動作となります。

ジョブテンプレートに渡された”extra_vars”に“allowed”のみ存在
→　◯　ジョブテンプレートが正常動作
ジョブテンプレートに渡された”extra_vars”に“allowed”が存在しない
→　×　ジョブテンプレートが起動しない(エラー表示)
ジョブテンプレートに渡された”extra_vars”に“allowed”が存在しているが、他のキーもある
→　×　ジョブテンプレートが起動しない(エラー表示)

OPAサーバーの起動

AAPと連携するには、OPAをサーバーモードで起動し、APIで応答できるようにする必要があります。先述したサンプルregoスクリプトを読み込み、サーバーモードで起動するには以下のコマンドを実行します。

> opa run --server --addr <hostname>:<port> extra_vars_allowlist.rego

コマンドを実行すると、ターミナル上でサーバーが起動して入力を待ち受ける状態となります。AAPからポリシーチェックが行われると、画面上に動作ログが表示されるようになっています。OPAは通常ポート8181を使用して起動します。
アドレスやポートを変更する必要があればコマンドにて可能となっています。オプションで--log-levelを渡すと、更に詳細なログを出力することも可能です。

> opa run --server --addr <hostname>:<port> extra_vars_allowlist.rego

(起動時)
{"addrs":["<hostname>:<port>"],"diagnostic-addrs":[],"level":"info","msg":"Initializing server.","time":"2026-01-28T19:58:01+09:00"}

(データ受信→ポリシー評価結果)
{"client_addr":"<ip_addr>:<port>","level":"info","msg":"Received request.","req_id":1,"req_method":"POST","req_path":"/v1/data/aap_policy_examples/extra_vars_allowlist","time":"2026-01-28T19:58:05+09:00"}
{"client_addr":"<ip_addr>:<port>","level":"info","msg":"Sent response.","req_id":1,"req_method":"POST","req_path":"/v1/data/aap_policy_examples/extra_vars_allowlist","resp_bytes":134,"resp_duration":0.700528,"resp_status":200,"time":"2026-01-28T19:58:05+09:00"}

また、このスクリプトの指定では“*.rego"として複数のスクリプトを読み込ませる事も可能ですし、--bundleオプションを使用してregoスクリプトとdataファイルをtar.gz形式で読み込むことも可能となっております。

ポリシーチェックの違反例

AAPの設定とOPAが正常に動作している場合、ポリシーに違反するとAAPでは以下の様なメッセージが『ジョブ』に表示されます。
(この例では、“extra_vars"に“allowed"、“debug"、“env"を与えています)

図1. OPAポリシー違反

また、ポリシーチェックが正常に通過した場合は、以下の通り正常にPlaybookが実行されます。

図2. OPAポリシー正常

まとめ

AAPからOPAへ渡される値は仕様として公開されているため、必要なデータを取捨選択しポリシーチェックできます。
OPA側の実装は非常にシンプルで、入力されたデータをregoスクリプトで評価し、ポリシーに違反しているか否かを返すのみの機能を持っています。

また、Playbook内に記述されたタスクごとにポリシーチェックが可能であれば、より柔軟な活用が可能かと考えられますが、現時点の仕組みではAAPのジョブテンプレート実行直前にOPAと連携しポリシーチェックするという仕組みとなっております。

GitHubリポジトリに公開されているサンプルにもあるように、Playbookの実行開始時間の制限やファイル名のルール指定などがOPAのポリシーチェックを利用することで可能となり、前編のユースケースに挙げたとおり本来AAPの機能だけでは実現できない仕組みを、OPAを利用することで実現するという役割分担が可能となります。OPAを活用することにより、イベント駆動の自動化やAI連携した自動化の安全性を高めることも可能かと考えます。

ぜひOPAを活用して、より柔軟に、セキュアにAAPを運用してみてはいかがでしょうか。