はじめに
こんにちは、SREの井上です。
本記事は、Ansibleを使用してNW機器のNetwork Time Protocol（NTP）の設定を統一した事例紹介です。以前の記事の続きになっています。
NWコンフィグの設定状況
NWコンフィグの自動取得
Oisix ra daichi Inc.は、数百台のNW機器によって支えられており、NWチームによって管理されています。そのうち、約400台のNW機器コンフィグは、GitHubで管理しています。コンフィグファイルは拠点名/設置場所/ホスト名.txtの形式で管理され、必要に応じてすぐに設定内容を確認できるようになっています。この他にも、OSのバージョン情報やインターフェースの情報を管理しています。これらのコンフィグは、週に1度自動的にGitHubへバックアップをしています。
コンフィグ管理しているNW機器メーカの割合は、Cisco機器が5割、Aruba機器が4割、Fortinet機器が1割ほどです。Cisco機器が最も多く、コアルータやL2・L3スイッチなどが含まれます。社内通信を支えているCisco機器ですが、歴史ある弊社において導入時期やバージョンの違いによる設定差異がありました。
NTPの設定が機器ごとによって異なる
機器ごとに異なっていた点として、NTPの設定先がバラバラに設定されていました。NTPの設定先は、以下のような物がありました。
- 誰でも利用できるPublic NTPサーバ*1
- 社内で管理しているNTPサーバ
- 既に削除済みのサーバ
- 他のネットワーク機器
少なくとも時刻同期ができていれば良いですが、存在しないサーバへ時刻同期を試みるのは、セキュリティ上問題があります。 そもそも、NTPとは機器同士で時刻同期を行うためのプロトコルです。機器ごとに異なる設定がある場合、ログファイルのタイムスタンプの正確性が損なわれる可能性があります。
例えば、企業のシステムやアプリケーションが異なるサーバーで実行されながら、異なる時刻を持っているとします。この時に悪意のある攻撃が行われた場合は、攻撃の前後の正確なタイムスタンプが得られず、結果的に攻撃の追跡や解析が難しくなります。したがって、企業が運用するサーバーやNW機器のNTP設定は、セキュリティ上のリスクを最小限に抑えるために正確で統一された設定が必要です。
チーム内へNTPの設定条件について相談した結果、次のように変更することにしました。
- NTPの通信は、社内で完結させる（外部への接続はしない）
- 社内のサーバ1をプライマリ、サーバ2をセカンダリのNTPサーバとして設定とする
- 不必要なNTPの設定は削除する
これらの条件のもと数百台の機器に対してAnsibleでNTPの設定を統一しました。
NTPの設定の自動化
Ansibleを用いたNTPの設定
NW機器へのNTP設定は、Ansibleで実施しました。使用したモジュールは、cisco.ios.ios_ntp_global*2です。サンプルのPlaybookは、次のように記載します。cisco.ios.ios_ntp_globalモジュールの重要なオプションは、state: replacedです。この設定を追加すると、モジュールで定義したNTPサーバのみを設定し、不必要なNTPの設定は削除します。そのため、前節で定義した設定条件をこのPlaybookのみで実現できます。
--- - name: sample playbook hosts: all gather_facts: false tasks: - name: configure NTP (ios) connection: network_cli cisco.ios.ios_ntp_global: config: servers: - server: "192.0.2.1" prefer: "true" - server: "192.0.2.2" prefer: "false" state: replaced ignore_errors: true
Playbookの実行結果は、次の通りです。playbookの実行前と実行後の設定はbefore、afterから確認可能です。さらに、commandsには実行されるコマンドが記述されているためどのように設定変更されるかが分かるようになっています。
$ ansible-playbook -i inventory ntp.yml -vvv PLAYBOOK: ntp.yml **************************************************************************************************************** PLAY [sample playbook] *********************************************************************************************************** TASK [configure NTP (ios)] ******************************************************************************************************* changed: [198.51.100.1] => { "after": { "servers": [ { "prefer": true, "server": "192.0.2.1" }, { "server": "192.0.2.2" } ] }, "before": { "servers": [ { "prefer": true, "server": "198.51.100.100" }, { "server": "198.51.100.200" } ] }, "changed": true, "commands": [ "ntp server 192.0.2.1 prefer", "ntp server 192.0.2.2", "no ntp server 198.51.100.100 prefer", "no ntp server 198.51.100.200" ], ..<省略>.. } PLAY RECAP *********************************************************************************************************************** 198.51.100.1 : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
AWXを使用したワークフロー設定
Ansibleの実行には、AWX*3を使用しました。AWXとは、AnsibleをWebアプリケーションで管理してREST APIやタスクエンジンを提供しているオープンソースソフトウェアです。また、AWXは商用版のRed Hat Ansible Automation Platform（RHAAP）*4のアップストリームプロジェクトの1つです。AWXとRHAAPの違いは、サポートが受けられる点や安定性が異なります。弊社では、コスト面を考慮してAWXを利用しています。
AWXの実行は、NetBoxをダイナミックインベントリとして活用しました。前回Blog記事の成果から、NetBox上に登録されたデバイスに紐づくSiteを条件とし、対象拠点に所属するデバイスを抽出できる環境となっています。リスクの観点も踏まえて、NetBoxのSite毎に設定変更を行いました。システム構成図は、おおまかに次のように表せます。
NTPの設定後には、コンフィグを保存する必要があります。AWXは、このようなタスクをワークフローとして順番に実行させることが可能です。ワークフローは、常時実行、成功時、障害発生時に実行など制御可能です。例として、NTPの設定後にコンフィグ保存としてcopy running-config startup-configを実行するワークフローを次のように定義可能です。このように事前にワークフローを用意することで、手作業によるコンフィグ保存の忘れを防ぎました。
ワークフローを実行する際、段階的に機器の台数を増やして設定しましたが、いくつかの小さな問題が見られました。たとえば、NetBoxの登録情報の修正が必要だったり、AWXから機器へ接続するためにルートテーブルの見直しが必要でした。しかし、影響の少ない部分から始めて、最後にはNTP設定を統一することができました。
まとめ
Ansibleを使用してNW機器のNTP設定を統一しました。また、AWXを使用することで、NW機器の設定からコンフィグ保存までを自動化することができました。今後は、NTP以外のNW機器設定を検討してNetBoxとAWXの自動化を紹介することができればと思います。
*1:NICT、インターネットマルチフィード社やpool.ntp.orgなどのPublic NTPサーバを使用していました。
*2:cisco.ios.ios_ntp_global module – Resource module to configure NTP. — Ansible Documentation
*3:ansible/awx: AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform.
