前回に引き続き、AnsibleによるFortigateのポリシー設定のお話です。
だんだん「普段だとエラーチェックで弾かれる設定をAPIで叩いたのち、再起動してどうなるかを試す」のが楽しくなってきています。
Ansible関連の実践記事一覧はこちら。
- 現在のポリシー設定情報の取得
- ポリシーの並び順
- ポリシーの順序の入れ替え
- ポリシー要素の複数オブジェクトの指定
- ポリシーのEnable/Disableの切り替え
- 初期定義以外のオブジェクトが使えるか
- 「名無しポリシー許可」無効状態での名前無しポリシーの設定
- 感想
現在のポリシー設定情報の取得
色々とポリシー系のモジュールを眺めてみましたが、基本的にfortios用の現在のモジュールには、「設定変更」用のモジュールしか存在せず、「設定取得」用のモジュールはなさそうです…
唯一の設定取得用のfortios_configモジュールはpyFGなので今のところ動かせてません…
FortigateのAPIそのものはGETメソッドには対応しており、例えばログインした状態で以下のようにURLにアクセスすることで、指定されたエンドポイントの情報をJSON形式で取得することが可能なようです。
■ポリシー全体の情報を取得 htttp[s]://<fortigate_ip_address>/api/v2/cmdb/firewall/policy ■単一のポリシー情報を取得 htttp[s]://<fortigate_ip_address>/api/v2/cmdb/firewall/policy/1
■出力例 { "http_method":"GET", "revision":"39.0.0.661485498.1572955273", "results":[ { "q_origin_key":1, "policyid":1, "name":"", "uuid":"ee645184-fec9-51e9-d467-0b6fb1a24d6d", "srcintf":[ { "q_origin_key":"internal", "name":"internal" } ], "dstintf":[ { "q_origin_key":"wan1", "name":"wan1" } ], "srcaddr":[ { "q_origin_key":"all", "name":"all" } ], "dstaddr":[ { "q_origin_key":"all", "name":"all" } ], (略) "action":"accept", "send-deny-packet":"disable", "firewall-session-dirty":"check-all", "status":"enable", "schedule":"always", "schedule-timeout":"disable", "service":[ { "q_origin_key":"HTTP", "name":"HTTP" }, { "q_origin_key":"HTTPS", "name":"HTTPS" }, { "q_origin_key":"DNS", "name":"DNS" } ], (略)
ポリシーの並び順
Policy IDには関係なく、上から順に登録されるようです。
ポリシーの順序の入れ替え
モジュールは見当たりませんでした。 CLIだとこれだけなんですけどね…
ポリシー要素の複数オブジェクトの指定
モジュールのリファレンスにも「list形式」とあったので、以下のように宣言したところ、問題なく複数サービス指定のポリシーになりました。(前回と共通する部分は省略)
service: - name: "HTTP" - name: "HTTPS" - name: "DNS"
ポリシーのEnable/Disableの切り替え
ポリシーの削除と同じように、指定したPolicy IDだけを宣言し、status: "disable"にすることで実施可能でした。
tasks: - name: Configure Firewall Policy (Disable) fortios_firewall_policy: host: "{{ host }}" username: "{{ username }}" password: "{{ password }}" vdom: "{{ vdom }}" ssl_verify: "{{ ssl_verify }}" state: "present" firewall_policy: policyid: "1" status: "disable" #有効化するときはstatus: "enable"
↓実行結果
初期定義以外のオブジェクトが使えるか
当たり前ですが、宣言されてさえいれば利用が可能でした。↑の画像の「HOGE_TCP999」はカスタムサービスオブジェクトです。
「名無しポリシー許可」無効状態での名前無しポリシーの設定
Fortigateのポリシーには、いつからか初期設定で名前の設定が必須になりました。これを無効化(=名無しポリシーを許可)できるスイッチが「Allow Unnamed Policies」の有効化です。
名無しポリシー禁止の状態で、Ansible のPlaybook(前回のものと同じ)を実行してみましたが、特にエラーもなく正常終了しました。
また、その状態で再起動も試してみましたが、特に設定が消えるようなことはありませんでした。
やはり、CLI/WebUIでエラーチェックがかかる設定も、REST APIだと設定可能なようです。要注意ですね…
感想
モジュールリストを眺めていて薄々感じてはいましたが、最初のほうにも書いたようにfortios用のモジュールは「設定変更」用のものしかなく、一部の例外(fortios_facts)を除いては「情報取得」用のものはなさそうです。
これまで、もくもく会で実施してきたコンテンツや環境は、どれだけ恵まれた状態だったのかを痛感しました…
また、一部分だけをSSH用のコマンドを実行する形でPlaybook化して実装する、などしたときにも、fortiosapiが利用するlocalコネクションプラグインではつらそうだなあと感じました。
いきなりモジュールを試すのもいいですが、地力をつけるためにも色々と基礎から勉強をせねばな、と改めて感じました。