はじめに

前回の記事（以下、EDAありの記事）で、EDA Controller を使い、Palo Alto ファイアウォールの設定変更したらコンフィグを git にバックアップする仕組みを作ってみました。

作っている途中、EDA Controller を経由しなくても同等のことが実現できるのではないかと思いました。違いを体感するため、EDA Controller なしのパターンでも作ってみます。

環境
- paloaltonetworks.panos コレクション 2.17.3
- Automation Controller 4.4 (AAP 2.4)

はじめに
作るもの
■ Palo Alto 側の設定
- HTTP サーバープロファイルの作成
- ログ設定
■ Automation Controller 側の設定
- Playbook の作成
- Automation Controller 側の設定
■ 動作確認
EDA Controller 有無の比較
おわりに
- 参考

作るもの

Palo Alto 側で設定変更してコミットすると、Automation Controller のジョブテンプレートを実行され、Palo Alto のコンフィグを取得して git push するものです。

EDAありの記事と大きく異なるのは、EDA Controller を経由しないことです。Palo Alto から HTTP のログを飛ばす際に、 Automation Controller の REST API の形式に合わせてあげるのもポイントです。

■ Palo Alto 側の設定

まず、ログの発生源である Palo Alto 側の設定をします。EDAありの記事と同じの部分も多いです。

HTTP サーバープロファイルの作成

Palo Alto から HTTP でログを出力させるために、まず HTTP サーバープロファイルを設定します。

画面上部の DEVICE タブをクリックし、左メニューの サーバープロファイル 配下の HTTP をクリックします。HTTP サーバープロファイル一覧画面で (+) 追加 ボタンをクリックします。

HTTP サーバープロファイル作成画面が開きます。

HTTP サーバープロファイルの名前は ac-profile とします。

サーバー タブで、今回は以下の内容で追加します。

項目	今回の値	補足
名前	`ac-server`
アドレス	(Automation Controllerのアドレス)
プロトコル	`HTTPS`
ポート	`443`
TLS バージョン	`1.2`
証明書プロファイル	`None`
HTTP 方式	`POST`
ユーザー名	(未指定)
パスワード	`abc`	実際には不要だが必須のため適当な値

ユーザー名とパスワードの入力は、対象サーバーに対しての Basic 認証か何かに利用されるのかと予想しましたが、試した限りそうではありませんでした。そのため、Automation Controller への認証情報は、後述の Authorization ヘッダーで別途指定します。

続いて、ペイロードの形式 タブをクリックします。今回は、コンフィグのコミット完了のログを取れるログタイプ システム をクリックします。ペイロードの設定画面が表示されます。

今回は、以下のように設定します。

項目	今回の値	補足
名前	`ac-system-payload`
URI の形式	`/api/v2/job_templates/11/launch/`	`11` は今回実行したいジョブテンプレートのID、実際はジョブテンプレート作成してからこの設定をする
HTTP ヘッダー	ヘッダー: `Content-Type`、値: `application/json`	指定しないと `415 Unsupported Media Type` になる
	ヘッダー: `Authorization`、値: `Bearer トークン`	トークンは予め取得した OAuth 2 のトークンを利用する
ペイロード	*1

*1 ペイロード:

{
  "extra_vars": {
    "device_name": "$device_name",
    "receive_time": "$receive_time",
    "opaque": "$opaque"
  }
}

このペイロードには、ジョブテンプレートで必要な値を中心に詰め込みます。EDAありの記事と異なるのは、各変数を extra_vars 配下にした点です。

全体的に REST API リファレンスの

POST /api/v2/job_templates/{id}/launch/ Launch a Job Template

の方式に合わせています。

ログ設定

先ほどはプロファイルを作成しただけなので、今度はそれをどう割り当てるかという設定です。

左メニューから ログ設定 をクリックします。設定 セクションの (+) 追加 ボタンをクリックします。

ログ設定画面が開きます。

今回は、以下のように設定します。

項目	今回の値	補足
名前	`ac-log-system`
フィルタ	`(description contains 'Commit job succeeded')`	コミットしたときのログのみにフィルターする
HTTP	`ac-profile`	`(+) 追加` で先ほど作成した HTTP サーバープロファイルを選択

ここまでで Palo Alto 側の設定ができました。コミットを忘れずにしておきます。

■ Automation Controller 側の設定

Playbook の作成

ジョブテンプレートで実行する Playbook は以下のとおりです。

---
- name: Config Backup
  hosts: pan
  gather_facts: false

  tasks:
    # コンフィグバックアップリポジトリの clone
    - name: Execute git clone
      ansible.builtin.git:
        repo: git@example.com/pan-config-backup.git
        dest: pan-config-backup

    # Palo Alto から コンフィグエクスポート
    - name: Export a configuration
      paloaltonetworks.panos.panos_export:
        provider: "{{ provider }}"
        category: configuration
        filename: pan-config-backup/export.xml  # ほぼ改行無し
    
    # XML のフォーマット（改行）
    - name: Pretty prrint XML
      ansible.builtin.xml:
        xmlstring: "{{ lookup('file', 'pan-config-backup/export.xml') }}"
        pretty_print: true
      register: res_xml

    # フォーマット済み XML の書き出し
    - name: Write a pretty XML 
      ansible.builtin.copy:
        content: "{{ res_xml.xmlstring }}"
        dest: pan-config-backup/export.xml

    # git commit
    - name: Execute git commit
      ansible.builtin.command:
        cmd: "{{ item }}"
        chdir: pan-config-backup
      loop:
        - git add .
        - git commit -m "{{ opaque }}"    # EDA Controller ありと異なる点
        - git push

EDAありの記事と異なるのは、git commit する際のメッセージの変数名の指定のみです。EDA Controller を経由した場合は、ansible_eda 配下にさまざまな値が入りますが、今回はフラットな extra vars として渡ってきます。そのため単に opaque という変数の指定にしています。これは Palo Alto 側のでペイロードをそのように指定したためです。

Automation Controller 側の設定

先ほど作成した Playbook の実行するジョブテンプレートの名前を paloalto_config_backup_ac とします。

ジョブテンプレートでAPI 経由で追加変数を受け付けるように、追加変数の「起動プロンプト」を有効にしておきます。

ほか、インベントリや認証情報の設定も Automation Controller 上で設定しておきます。

■ 動作確認

準備ができたので、一連の流れを試します。流れは以下の通りです。

（人の操作） Palo Alto 側で設定変更（今回はオブジェクト追加）してコミット
Palo Alto から Automation Controller へ HTTPS （REST API 形式）でログが飛び、ジョブテンプレートを実行
Automation Controller からPalo Alto のコンフィグを取得して git push

設定変更して

コミットすると

ジョブが動いて

git push される

コミット時のみログが飛ぶようにフィルターを設定してあるので、ほかのログの時には特に何も起こりません。

EDA Controller 有無の比較

同じような仕組みを、EDA Controller ありなしのパターンの両方で試せたので、主観ですが感じた特徴をまとめます。あくまで私がブログに書いた処理内容での範囲です。

	EDA Controller あり	EDA Controller なし
ログのフィルター・ルールの柔軟性	○: Rulebook 側でもルールを指定可	△: Palo Alto 側でフィルターする必要がある
アクションの柔軟性	○: 1ログにつき複数のアクション（リクエストなど）	△: 1ログにつき1リクエスト
ジョブテンプレートの実行	○: Rulebook 内で名前で指定して実行	△: エンドポイント内でID で指定して実行
ワークフロージョブテンプレートの実行	✗: 不可（ansible-rulebook 1.0.0 時点）	△: エンドポイント内でID で指定して実行

もちろん、不要なのであれば無い方がメンテナンス対象が少ないことからくる運用上のメリットはあると思います。

おわりに

Palo Alto の設定変更をすると EDA 経由で、コンフィグを git push する仕組みを EDA Controller なしで試してみました。

Palo Alto 側の HTTP サーバープロファイルの設定の柔軟性のおかげで、EDA Controller なしでもできないこともないな、という感想です。作っている最中はジョブテンプレートを名前ではなく ID で指定する必要がある点が、ややむずむずしました。もっと複雑な処理を作ろうとすると、EDA Controller ありなしの差分が他にも色々出てきそうな気もします。

参考

EDA Controller ありの記事
- [Ansible/EDA] Palo Alto ファイアウォールの設定変更したらコンフィグを git にバックアップする仕組みを作ってみた - てくなべ (tekunabe)

てくなべ (tekunabe)

ansible / network automation / 学習メモ

[Ansible] Palo Alto ファイアウォールから Automation Controller のジョブテンプレートを実行する（EDA Controller なし）