Cisco Nexus Dashboard InsightのCompliance機能を使って、設計ルールから逸脱した場合にBotに怒られる実装をしてみる

この記事はシスコの有志による Cisco Systems Japan Advent Calendar 2022 (2枚目) の 18日目として投稿しています。
2022年版(1,2枚目): https://qiita.com/advent-calendar/2022/cisco

# 0.はじめに :christmas_tree:
　ネットワークを運用する場合に、設計ルールとしていかに素晴らしい取り決めをしてもそれが守られなく、形骸化してしまったという経験はないでしょうか？

　例えば、ネーミングルールを設定しているのに、担当者が後から適当に名前を付けてしまって、この定義って何だっけ？となったり、機密情報を保持したサーバーを配置するネットワークセグメントなので、外部と通信一切させないポリシーだったはずなのに、気付いたら外部と通信できるようになっていた、といったようなことは実際に起こりうるのではと思います。

　本稿では、このような問題を解決するためにCisco Nexus Dashboard InsightsとCisco ACIを連携させ、仮に設計ルールからの逸脱があった場合はWebex Botにタイムリーに怒られるという実装の仕方をご紹介したいと思います。

# 1.Nexus Dashboard Insightsとは

　Cisco Nexus Dashboard Insights（以後NDI）は、Ciscoのデータセンターソリューションで活用できる、次世代Day2 Operationプラットフォームのことです。
NDIの様々な機能を利用して、運用を高度化できます。

　Nexus Dashboard Insightsの機能は続々と追加されていますが、現時点での主な機能をまとめてみました。
![Slide1.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/ba0ab86f-a297-737d-77c1-c9f77f33f25a.jpeg)
　今回は、この中のCompliance機能を取り上げます。
NDIやNexus Dashboardに関する様々な情報は[こちら](https://community.cisco.com/t5/-/-/ta-p/4449779)にもありますので、是非参考にしてください

## 1.1.Compliance機能について
Compliance機能とは、事前に設定したルールを逸脱した場合に、Anomaly（NDIにおけるFaultのこと）を発生する機能になります。これにより、定期的に棚卸やレビューをしなくても、自動的にルールの逸脱を発見することができます。



## 1.2.Complianceで設定可能なルール
Compliance機能は、大きく2つの機能に分かれます。
Configuration(設定)のコンプライアンスと、Communication(通信)のコンプライアンスです。

先ほどの例で上げた、ネーミングルールは、Configのコンプライアンスに分類され、通信の禁止ルールは、Communicationのコンプライアンスに分類されます。


# 2.Webex botについて
NDIではルールの逸脱をAnomalyとして検知した場合に外部のソースに転送することができます。
外部ソースとしてEmail、SyslogやKalkaなどを選択できますが、それらの受信先からAPIを実行することで、もっとユーザーフレンドリーで、様々な面白いことができるWebex Botに違反を通知してもらうことにします。）

Webex botの設定はhiroさんの[記事](https://qiita.com/hiroactivity/items/2ff9ef7fbd8e6de19f06)を参考にしてください

# 3.実装例
登場人物：
- Kiteretsu ・・・ ネットワーク管理者
- Korosuke　・・・ Webex Bot

本稿における構成概要は以下のようになっています。
ACIはVersion4.2を利用し、NDIはVesion6.1を使用しています。
Syslog Server、スクリプト実行サーバーとしてZABBIXを利用しています。
![Slide2.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/3446b1ba-1b1e-dbe5-1797-46e033dacc5c.jpeg)
①KiteretsuがACIにおいてルールを逸脱をする
②APICと連携しているNDIがAnomaryを検知する
③NDIがAnomaly情報をSyslog(Zabbix)に転送する
④Syslog(Zabbix)サーバーにおいてAnomalyのキーワードに応じてActionとしてWebex APIを実行する
⑤これを受けたKorosuke（Bot）がKiteretsuに怒る

という仕組みです。

## 3.1. NDI事前設定

まずNDI側の設定です。
今回以下の２つのルールを設定したいと思います。

|設定ルール|カテゴリ|内容|
|:---|:---|:--|
|BDに対するネーミングルール|Configuration|BDの名前はBD_で始めなければならない|
|EPG:Daihyakkaの通信ルール|Communication|EPG:Daihyakkaは外部に通信してはいけない|

①Configurationルールは、ネーミングルールのほかに、パラメータの設値なども設定が可能です。
今回は、添付画像のようにBD_で始めることをルールとして設定しました。
![Slide3.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/464215ab-e50b-79a4-8167-8aedc78ace4f.jpeg)
②Communicationルールは、Must Talk to（SLAルール）、Must Not Talk to（禁止ルール）、May Talk to(制限ルール)の３つの方法が可能です。今回は、Daihyakkaは非常に気密性が高いため、外部と通信させないという禁止ルールを設定しました。
![Slide4.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/423de20d-b41e-728c-cc7f-33c760d62f66.jpeg)

該当Complianceルールを逸脱した際に、Anomalyの情報を外部サーバーに転送することができます。今回はFalicity local5で、Syslogサーバーに対して転送を行うこととしました。
![Slide5.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/746e27e6-2f58-a320-9de2-3d737d46e5b2.jpeg)

事前の状態では、Complianceの順守状況は、100％となっています。![Normal.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/df3d8da1-bb0e-9a27-aa2f-27fa4341a897.jpeg)


## 3.2. Syslog Server設定
Syslogサーバー、Webex APIの実行を行うサーバーとして、今回Zabbixを使用しました。
Anomalyのキーワードを元に、対応する処理を規定しています。

|内容　　　　　　　　　　|キーワード|アクション|
|:---|:---|:--|
|BDのネーミングルール逸脱を検知|CONFIGURATION_COMPLIANCE_VIOLATED<br>(復旧ルールとして、CONFIGURATION_COMPLIANCE_SATISFIED)|webex_anomaly_compliance1.pyを実行<br>RoomにConfigurationルール逸脱が発生したことを通知|
|通信ポリシー逸脱を検知|TRAFFIC_RESTRICTION_COMPLIANCE_VIOLATED<BR>(復旧ルールとして、TRAFFIC_RESTRICTION_COMPLIANCE_SATISFIED）|webex_anomaly_compliance2.pyを実行|

Zabbixの設定として、以下を実施しています。
なお、こちらの設定は、Configルールのみを記載しておりますが、Communicationルールも同様の設定を行っています。
① Syslogの指定
　・NDIから送信されたFacilityに従いSyslogを受信する設定
```php:rsyslog.conf
# Save NDI messages to nw.log
local5.*                                                /var/log/ndi.log
```
② トリガーの指定
　・Zabbixに送付されたSyslogからキーワードを指定して、トリガーを指定
![Slide6.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/36730a08-2acb-bd81-32a3-accfb816d660.jpeg)
③　アクションの指定
　・該当のトリガーが発生した際に、アクションとしてリモートコマンドを実施。
　今回は、Zabbix上にPythonファイルを配置し、Webex APIを発行するスクリプトを実行するように設定しました。
![Slide7.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/e90cf83a-4d4a-d74d-de02-80337273577d.jpeg)

## 3.3. Webex API設定
Webex APIを実行する際は、
・Room IDの指定
・User IDの指定
・Markdownの指定
が必要になります。
さらに今回の環境は、Proxy経由でしか外部にアクセスできないため、Proxyの設定も併せて実施しました。
これらをPythonのrequestsモジュールを使用して、以下のように実装しています。
```php:webex_anomaly_compliance1.py
#!/usr/bin/env python3

import requests
import json

proxies = {
    'http' : 'http://proxy.xxxx.com:80', # HTTP用Proxy
    'https' : 'http://proxy.xxxx.com:80',　# HTTPS用Proxy
}

def main():
    url="https://webexapis.com/v1/messages"
    headers={"Authorization": "Bearer xxxxxxxxxxxxx", # BOTのBearerを記載
             "Content-Type": "application/json"}
    markdown = "Kiteretsu、設定ミスしてるなりー"　# BOTにしゃべらせる文字を指定
    payload={"roomId": "xxxxxxxxxxxx", # Room IDを記載
            "markdown": markdown}
    requests.post(url, headers=headers, data=json.dumps(payload),proxies=proxies)

if __name__=="__main__":
    main()
```
## 3.4. ACIにルール逸脱設定をしてみる1（BDの名前をButa_Golliraにする）
では、早速BDを作成してみましょう。
①本来「BD_」で開始すべきBDの名前を「Buta_Gollira」として作ってみます
![Slide8.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/39fc3b7d-4050-a6f9-5a88-55bfad941a3f.jpeg)
②数分～十数分後にNDI側でComplianceのAnomalyが発生し、Korosukeが以下のメッセージを出して怒ってくれました。
![Slide9.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/14115a49-0a51-d2ee-c442-9ea166bdec7d.jpeg)
③NDIにログインすると、BD_RuleがVIOLATEDとなっていることが分かります。
![Slide10.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/a9c21f9c-a93e-376e-f8dd-e9870826d32a.jpeg)
更に、NDIでは、該当の詳細の理由や対応アクションを表示することも可能です。
![Slide11.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/d7df5f25-fea2-0d3f-d1cd-be6c4af118cc.jpeg)


## 3.5. ACIにルール逸脱設定をしてみる2（Daihyakkaを外部に公開する）
次に、Daihyakkaが外部からアクセスできる状態にしてみましょう。
①EPG DaihyakkaをL3OutのExternal EPGと通信できるようにContractを設定してみます
事前のACI設定は、こちらですが、
![Slide12.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/8736c776-63b7-914d-d7e4-82ed8c57f5e5.jpeg)
設定変更してDayhyakkaが外からアクセスできる状態になりました。
![Slide13.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/a682ced6-8a4c-c63a-0f30-868aa1c4dc3d.jpeg)

②数分～十数分後にNDI側でComplianceのAnomalyが発生し、Korosukeが以下のメッセージを出して怒ってくれました。
![Slide14.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/8f8bdb0f-4d28-e51a-76de-ad86b7ee9a92.jpeg)
③NDIにログインすると、Security_RuleがVIOLATEDとなっていることが分かります。
![Slide15.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/417a1ac6-1efc-3f77-dcfa-35b3e8cfa8df.jpeg)
先ほど同様NDIで、該当の詳細の理由や対応アクションを表示することが可能です。
![Slide15.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2960592/057fea57-0792-35de-c048-98904582a397.jpeg)


# 4. まとめ
　このようにNDIを使うと運用の高度化を簡単に実現します。
　一つだけ注意点は、Compliance機能は、デフォルトで15分間隔でSnapshotを取得し、Anomalyの発生有無を確認しているため、短い間隔での検知が必要な場合は、手動でSnapshotを取得するなどを検討頂く必要があります。
　今回はComplianceの機能を使って、BotOpsを実装する例を紹介しましたが、今後様々な活用用法をCisco Communityなどで紹介していきたいと思います。
　また、ACIやNDIの情報は、ACI How to、Nexus How toにまとめてありますので、是非活用してみてください。

それでは、皆様、良い年末をお過ごしください:bamboo:

# 最後に
Advent Calender気軽に挙手してみたんですけど、結構大変だとわかりましたー。
来年は一年かけてネタを仕込んでみたいと思います:santa:
本稿の投稿にあたって、様々な知見をアドバイス頂いた@hiroactivityさんに感謝いたします。