はじめに
以前の記事 で、Palo Alto ファイアウォールと EDA Controller、Automation Controller の連携を試しました。
記事の中でも触れていますが、EDA Controller が本当に必要かどうかは考えず、とりあえず手を動かしてみた趣旨でした。
連携を考えるうえで、EDA Controller の要不要にどんな観点があるかなと考えたことをまとめます。
- 前提環境
- AAP 2.4. (Automation Controller 4.4)
- ansible-rulebook 1.0.1
Webhook 以外の連携方法
Red Hat 社から EDA の話がでは出始めたのは 2022 年の AnsibleFest でした。まだ新しいということもあってか、サンプルコードのパターンも多くありません。
よく見かけるのは ansible.eda.webhook イベントソースプラグインを利用したものです。Webhook のように他システムからの push による Web をベースの連携というと、真っ先に思い浮かぶのは、Automation Controller が備える REST API です。だったら EDA Controller を介さずに済むのでは、とも頭をよぎります。
しかし、EDA の連携方法は Webhook だけではありません。ansible-rulebook 1.0.1 のタイミングで、イベントソースプラグインを以下の3つのパターンに分けて紹介する個所ができました。
- Event Bus Plugins
- Scraper Plugins
- Callback Plugins
このうち、ansible.eda.webhook イベントソースプラグインは「3. Callback Plugins」にあたります。ほかのパターンのような連携が必要な場合は、EDA Controller が活きてくるのではと思います。
ドキュメントには
It’s strongly recommended to adopt one of the first two patterns and only consider callback plugins in the absence of any other solution.
とあります。
完全に私見ですが、ansible.eda.webhook の例しか見てない場合だと、EDA Controller は不要という思いが強くなるのではないかと思います。
Webhook の場合はどうか
では、Webhook に限った話だとどうでしょうか。頭をよぎった「だったら EDA Controller を介さずに済むのでは」を少し掘り下げます。
技術的な可否
避けて通れないのは、各システムの技術的、仕様的な可否です。
まず整理したいのが、先ほどの「他システムからの push による Web をベースの連携」と表現したもの中身です。具体的には以下の2つの方式をまとめて表現しました。
- Automation Controller が持つ Webhook 受信機能
- Automation Controller が持つ REST API 機能
Automation Controller における、各方式の簡単な特徴は以下の通りです。
| 方式 | どこから? | 操作できるもの |
|---|---|---|
| Webhook | GitHub、 GitLab | ジョブテンプレート、ワークフロージョブテンプレートの起動 |
| REST API | どこでも | あらゆるリソース |
以下、それぞれ考えていきます。
Automation Controller が持つ Webhook 受信機能
Automation Controller 自身の機能として、Webhookを受けてジョブテンプレートやワークフロージョブテンプレート実行する機能があります。
現状、この機能は GitHub や GitLab から飛んでくる Webhook のための機能です。
そのため、他のシステムからの Webhook を経由してジョブテンプレートやワークフロージョブテンプレートを実行するには、EDA のような他の仕組みが必要になります。
なお、通知機能の一種の Webhook は、Automation Controller が発の機能なので、ここでは言及しません。
Automation Controller が持つ REST API 機能
Webhook より汎用的に利用できるのが、Automation Controller が持つ REST API です。ansible.controller コレクションなどでも、内部的にこの REST API を利用しています。
ジョブテンプレートやワークフロージョブテンプレートの起動だけでなく、各テンプレートの作成、プロジェクトの作成や、ユーザーやチームの作成などさまざまな操作ができます。
「REST API があるのだから、他システムから直接から叩こう」となった場合でも、技術的な制限が出てくる場合があります。例えば、REST API では、対象リソースや操作内容に応じてエンドポイントやペイロードを変える必要がありますが、他システム側でその変更ができないような場合です。認証情報は仕込めるか、などもポイントになってきます。
以前の記事 で取り上げた、Palo Alto ファイアウォールの HTTP サーバープロファイルでは、エンドポイントやヘッダー、ペイロードがかなり柔軟に設定できました。固定の文字列だけでなく $device-name のような変数も使えました。このケースでは、技術的には EDA を介さずに、Automation Controller の REST API 経由で連携ができます。（(ジョブテンプレート実行だけ試しました](https://tekunabe.hatenablog.jp/entry/2023/08/02/pan-config-backup)）
一方、仕様的に他システムから直接 Automation Controller の REST API を叩けない場合は、何かしら一工夫、ワンクッション必要になってきます。例えば、他システムからは POST しかできずエンドポイントも固定、ペイロードは変更できるという場合。この場合は、EDA Controller が一度 Webhook として受けて、ペイロードの中身に応じて、実行するジョブテンプレートを選んで実行するような仕組みが考えられます。まだ実際にこのケースに出くわして対処したわけではないので、想像を含みます。
EDA Controller / ansible-rulebook 側の現状の仕様制限
逆に EDA Controller を挟むとできないこともあります。
ansible-rulebook 1.0.1 現在、Rulebook の Automation Controller への action は、 ジョブテンプレートの実行（run_job_template）のみです（ただし、ワークフロージョブテンプレート実行 action の PR あり）。
そのため、ワークフロージョブテンプレートの実行や、他のリソースの操作（プロジェクト、インベントリなど）はできません。これらの操作がしたい場合は、ほかの何かしらの方法で Automation Controller の REST API を叩くことになります。
（外からは ジョブテンプレートの実行として受け取って、そのジョブテンプレートの Playbook の中で ansible.controller.project モジュールなどを利用して各種リソースの操作をしてもいいかもしれないです。未検証）
設計上の考慮点
技術的にできるからといって、必ず EDA Controller を導入すべきかというと、そうでもないですよね。既存システムの特性やセキュリティの考え方などによって変わってくると思います。
あまりバシッといえることはないのですが、以下のような観点があるかと思います。
- ログ類のフィルターをどこでかけるか
- ルールやロジックをどこに定義するか
- 認証情報をどこに持たせるか
おわりに
他システムと Automation Controller の連携を検討する際に、EDA Controller が必要かどうかを、どのような観点で検討すればよいか考えてみました。
それぞれのものに詳しくないと、なかなか解像度高く考えられないので、引き続きいろいろと調べていきたいと思います。
