VMware NSX CloudによるAzureのセキュリティ管理


# NSX Cloudとは

NSX Cloudはパブリッククラウドに対して、ネットワークとセキュリティ機能を提供するサービスです。これまではSaaSとして提供されていましたが、オンプレミス向けに提供されているNSX-Tでもバージョン2.2から利用が可能になりました。(※2018年7月現在SaaS版のNSX Cloudは[Cloud Serviceのカタログ](https://cloud.vmware.com/service-catalog)から削除されています。)

SaaS版のNSX CloudとNSX-Tで利用できるNSX Cloudには以下の差があります。

- SaaS版 NSX Cloud : AWSに対応。インスタンスのセキュリティポリシーの管理とVPC内でのオーバーレイネットワークの利用が可能。
- NSX-T版 NSX Cloud : Microsoft Azureに対応。インスタンスのセキュリティポリシーの管理が可能。オンプレミス環境の仮想ネットワークも同じインターフェースから統合管理が可能。

今回は、NSX-Tから利用できるNSX CloudのAzure向け機能の設定方法と利用方法を説明します。[SaaS版 NSX CloudによるAWS VPCの管理に関してはこちらを参照](https://qiita.com/masanara/items/fb7ddd3b3245416295ff)してください。

# NSX Cloudのコンポーネント

NSX Cloudは以下のコンポーネントによって構成されます。

- NSX Manager : 論理スイッチやNSX Edge Services Gateway、ファイアウォールなどのNSX-Tコンポーネントの作成、設定、監視を行うためのGUIとREST APIを提供する仮想アプライアンスです。
- NSX Cloud Service Manager (CSM) : オンプレミスで起動する仮想マシン。AzureのAPIを登録しAzure上のオブジェクトの収集と、APIによるAzureの操作を行います。
- Public Cloud Gateway (PCG) : AzureのVNet内で起動する仮想マシンです。オンプレミスのNSX Managerと連携して、Azure VNet内でNSXのLocal Control Planeとして機能します。
- NSX Agent : VNet内でNSX管理下とする仮想マシン上で起動するエージェントです。Open vSwitchを利用して、仮想マシン内のネットワークを制御します。


# Azureの準備

## VNetの作成

VNetを新たに作成し、VNet内に3つのサブネット(management/downlink/uplink)を作成します。VNet内に作成されるPCGは3つのサブネットに接続されます。

![Kobito.QKREOP.png](https://qiita-image-store.s3.amazonaws.com/0/27668/f40a3692-60ce-16cc-2da1-b86596857bd1.png "Kobito.QKREOP.png")


## VNetとオンプレミスの接続

Public Cloud Gatewayをデプロイするためには、デプロイするPublic Cluoud GatewayとオンプレミスのNSX Manager間での通信が必要になります。(通信不可能な状態でPCGをデプロイすると、仮想マシンの作成は開始されますが、仮想マシンの構成に失敗し自動的に削除されます。)今回は、Azureの仮想ネットワークゲートウェイを利用してオンプレミスのルーターとIPSec VPNで接続しています。

## Azure VNetとオンプレミスNSX環境の通信要件
VPNもしくはExpress RouteでVNnetとオンプレミス環境を接続し、オンプレスのNSXコンポーネントと、クラウド上のコンポーネントの通信を可能にする必要があります。通信要件を満たしていない場合、PCGのデプロイに失敗します。

| 送信元 | 送信先 | Protocol/Port | 説明 |
|:-----------|:------------|:-----------------:|:--------|
| PCG        | NSX Manager | TCP/5671          | パブリッククラウドからオンプレミスのNSXに対する管理通信 |
| PCG        | NSX Manager | TCP/8080          | パブリッククラウドからオンプレミスのNSXに対するあアップグレード通信 |
| PCG        | NSX Manager | TCP/1234,TCP/1235 | パブリッククラウドからオンプレミスのNSXに対する制御通信 |
| PCG        | DNS         | UDP/53            | パブリッククラウドからオンプレミスのDNSに対する通信 |
| CSM        | PCG         | TCP/7422          | CSM Config Push |
| Any        | NSX Manager | TCP/443           | NSX Manaager UI |
| Any        | CSM         | TCP/443           | CSM UI |


## Azure Active Directoryの設定

NSX CSMが必要とするアクセス権を付与するための新しいサービスプリンシパルをAzure Active Directoryに作成します。私は以下の方法で手動でID及びキーを生成しましたが、[マニュアルにはPowerShellスクリプトを利用した方法](https://docs.vmware.com/jp/VMware-NSX-T/2.2/com.vmware.nsxt.admin.doc/GUID-276902EA-FFA5-4483-8124-D6ECA4F5069B.html)が掲載されています。

1. Azure Active DitectoryにWebアプリ/APIを追加します。追加したアプリの「アプリケーションID」をメモします。登録したアプリにはIAMから共同作成者の役割を割り当てます。
2. APIアクセスに対するキーをパスワードとして追加します。登録後に表示されるキーの値をKeyをメモします。

## Subscription ID/Tenant IDの確認

CSMに対するAzureの登録時に以下の2つのIDが必要とるので、確認してメモします。

- Subscription ID : ホーム → サブスクリプション - サブスクリプションID
- Tenant ID : ホーム → AAD(規定のディレクトリ) → プロパティ - ディレクトリID

上記の3つのIDとキーを使ってCSMにAzureのアカウントを登録します。

# NSX-Tのセットアップ

NSX Cloudを利用するためにオンプレミス環境にNSX-Tの環境が必要となります。NSX-Tを利用することでvSphereやコンテナ環境のネットワークやセキュリティを管理することが可能になりますが、ここではNSX Cloudで必要となるコンポーネントに関してだけ簡単に説明します。

1. NSX Maanagerをオンプレミスにデプロイ
NSX Manager仮想アプライアンスをオンプレミス環境にデプロイします。仮想アプライアンス(nsx-unified-appliance-2.2.0.0.0.xxxxxxx.ova)は統合イメージとして提供されているため、デプロイ時に「nsx-manager」を選択します。

2. NSX Controllerをオンプレミスにデプロイ
3台のNSX Controller VMをオンプレミス環境にデプロイします。以前のバージョンではControllerをそれぞれOVAから作成する必要がありましたが、NSX-T 2.2以降でNSX Manager上からNSX Controllerをデプロイすることが可能になりました。

3. Cloud Service Managerをオンプレミスにデプロイ
Azureとのインテグレーションを実現する、Cloud Service Manager(CSM)をオンプレミス環境にデプロイします。NSX Managerと同じOVAイメージを利用し、デプロイ時に「nsx-cloud-service-manager」を選択します。

# CSMの設定

CSMが起動したら、WebブラウザでCSMにアクセスし、ログインするとCSMのセットアップウィザードが起動します。
 
1. CSMにNSX Managerを登録
NSX ManagerのIPアドレスとクレデンシャルを指定して、NSX Managerを登録します。
![Kobito.TybNce.png](https://qiita-image-store.s3.amazonaws.com/0/27668/0be9b7fe-29a2-3dfc-fdb9-16323b0a919e.png "Kobito.TybNce.png")

2. CSMにAzureのアカウント情報を登録
Azure Active Directoryに構成した情報(Webアプリ/APIのアプリケーションID、キー)、Subscription ID、Tenant IDを使ってCloud Accountを登録します。
![Kobito.Ro9UlP.png](https://qiita-image-store.s3.amazonaws.com/0/27668/919546cd-c4df-2305-8fa8-7015568942eb.png "Kobito.Ro9UlP.png")


# Public Cloud Gatewayのデプロイ

1. CSMに対してAzureアカウントを設定すると、Azure内のVNetや仮想マシンの情報がCSM上に表示されます。
![Kobito.3mpxsB.png](https://qiita-image-store.s3.amazonaws.com/0/27668/90bb47cd-7609-e78a-9655-3be77604001a.png "Kobito.3mpxsB.png")



2. NSX Cloudの管理対象とするVNetのActionsからDeploy NSX Cloud Gatewayを選択して、PCGのデプロイを開始します。
![Kobito.GvR5m1.png](https://qiita-image-store.s3.amazonaws.com/0/27668/e5ec99bc-aac9-999f-7b46-602cff402b77.png "Kobito.GvR5m1.png")

3. 管理アクセスに利用するSSH用の公開鍵を指定し、PCGを作成するクラウドアカウントを選択します。デプロイ後のPCGにはnsxadminユーザーでログイン可能です。(セキュリティグループでSSHの通信を許可する必要があります)
![Kobito.2MC8sD.png](https://qiita-image-store.s3.amazonaws.com/0/27668/f7ef3fc7-5af9-c11d-de5b-d6586e45d222.png "Kobito.2MC8sD.png")

4. PCGを接続する3つのサブネットを指定します。Management IPにはパブリックIPを割り当てます。(以下の例ではHAを無効化してSingle構成のPCGをデプロイしています)
![Kobito.eqHCDe.png](https://qiita-image-store.s3.amazonaws.com/0/27668/13079f84-b280-094a-505b-95162769d87a.png "Kobito.eqHCDe.png")
  
5. しばらくすると、VNetにPCGが仮想マシンとしてデプロイされ、CSM上でGatewayがUp状態になります。
![Kobito.Cv4tWT.png](https://qiita-image-store.s3.amazonaws.com/0/27668/b6f3f414-f4d7-c42b-bfc1-755324db6300.png "Kobito.Cv4tWT.png")


PCGのデプロイによりAzure上にPCGに関連するリソースグループが作成され、仮想マシンやインターフェース、セキュリティグループ等が登録されていることを確認できます。

![Kobito.EsiU9d.png](https://qiita-image-store.s3.amazonaws.com/0/27668/8729c61b-25fc-8687-b3a3-880f68a17882.png "Kobito.EsiU9d.png")


# ワークロード仮想マシンの準備

## 仮想マシンの作成

NSX Cloudが対応している仮想マシンは[マニュアルに記載があります](https://docs.vmware.com/en/VMware-NSX-T/2.2/com.vmware.nsxt.admin.doc/GUID-F8455FDE-D29E-49AE-BBA2-4B5EC69ED4EC.html)。対応する仮想マシンイメージを利用して仮想マシンを作成します。仮想マシンは_Downlinkサブネット_に接続し、ネットワークセキュリティグループはSSHやRDP等必要な通信を許可します。

## NSX Agentのインストール

NSX Cloudで管理されるワークロード仮想マシンにはNSX Agentをインストールする必要があります。作成した仮想マシンにログインし、同一VNetのPCGからNSX Agentをダウンロードしてインストールすることが可能です。ダウンロード先とインストール方法は、CSMのCloud -> VNets -> 対象のVNetを選択すると「Agent Download & Installation」として表示されています。

![Kobito.xnkiy6.png](https://qiita-image-store.s3.amazonaws.com/0/27668/1dad8f04-8519-424f-a5d9-d8ce2a21aec7.png "Kobito.xnkiy6.png")


Linuxの場合は以下のようなコマンドでインストール可能です。

```
wget http://[PCGのManagementインターフェースIP]:8080/factory_default/linux/install_nsx_vm_agent.sh
sudo bash install_nsx_vm_agent.sh --dns-suffix [VNetの内部向けDNSサフィックス]
```

NSX Agentのインストールに成功すると、以下のメッセージが表示されパブリックIPアドレスに対するSSH接続がタイムアウトします。

```
------------------------------
Wed Jul 17 12:43:25 UTC 2018: Installation completed!!!

------------------------------
Starting NSX Agent service. SSH connection will now be lost.
```

## ワークロード仮想マシンに対するNSX用タグの付与

ワークロード仮想マシンにタグ(nsx.network)をつけることにより、NSX Cloudによる管理が可能になります。
[マイクロセグメンテーションモード](https://qiita.com/masanara/items/fb7ddd3b3245416295ff#%E5%88%A9%E7%94%A8%E5%BD%A2%E6%85%8B)で利用する場合は、nsx.network=defaultをタグとして追加します。

![Kobito.JYv1z5.png](https://qiita-image-store.s3.amazonaws.com/0/27668/32ec5a51-5576-90ea-e193-c6185657d0a9.png "Kobito.JYv1z5.png")

上記設定により、Azure上の仮想マシンはNSX Cloudの管理対象となり、CSMで以下のようにManagedと表示されます。

![Kobito.L7L5jd.png](https://qiita-image-store.s3.amazonaws.com/0/27668/5fe14f00-f5dd-bbdf-db09-71f63b77e178.png "Kobito.L7L5jd.png")

NSX管理下となったことで、NSX Managerから仮想マシンに対してファイアウォールルールを適用することが可能になります。

# NSXのファイアウォールによる管理

## NSGroupの作成

NSXでは管理対象のワークロードをNSGroupというオブジェクトで管理することが可能です。NSX ManagerはAzure上の仮想マシンもインベントリ上で認識しているため、以下のようなNSGroupを作成し、Azure上の仮想マシンを登録します。

![Kobito.7bUZ2X.png](https://qiita-image-store.s3.amazonaws.com/0/27668/79b01a6f-ce41-3602-2c17-669b30eed303.png "Kobito.7bUZ2X.png")


## ファイアウォールルールの作成

作成したNSX Groupを送信先として、以下のようなルールを追加することで、Azure上の仮想マシンに対して、パブリックIPアドレスを使ってSSHが可能になります。

![Kobito.V6P66p.png](https://qiita-image-store.s3.amazonaws.com/0/27668/33c28f10-d47b-1bd0-d5fd-fe8d60846be1.png "Kobito.V6P66p.png")


同一サブネット内の仮想マシン同士の通信を制御したり、インターネットから仮想マシンに対する通信を制御することも可能です。以下の例では、Azure VM NSGroup内のICMP通信と、外部からAzure VM NSGroupに対するのHTTP/HTTPS通信をRejectしています。

![Kobito.5aDTQj.png](https://qiita-image-store.s3.amazonaws.com/0/27668/3ff5eb49-7f87-2b82-c6f8-fdb0c18c3965.png "Kobito.5aDTQj.png")


# NSX Agentのインストールによる仮想マシンのネットワークの影響

仮想マシン内にはNSX AgentとしてOpen vSwitchがインストールされ、OVSスイッチとネットワークネームスペースが以下のように構成されます。

## OVSスイッチの状態

```
masanara@ubuntu-nsxcloud-01:~$ sudo ovs-vsctl show
fa9c0622-c9f8-4438-b5fc-cc6253e22c28
    Manager "unix:/var/run/vmware/nsx-agent/nsxagent_ovsdb.sock"
        is_connected: true
    Bridge nsx-switch
        Controller "unix:/var/run/vmware/nsx-agent/nsxagent_vswitchd.sock"
            is_connected: true
        fail_mode: secure
        Port nsx-switch
            Interface nsx-switch
                type: internal
        Port nsx-switch-
            Interface nsx-switch-
                type: patch
                options: {peer="nsx-switch+"}
        Port "eth0"
            Interface "eth0"
    Bridge nsx-managed
        Controller "unix:/var/run/vmware/nsx-agent/nsxagent_vswitchd.sock"
            is_connected: true
        fail_mode: secure
        Port nsx-managed
            Interface nsx-managed
                type: internal
        Port "nsx-switch+"
            Interface "nsx-switch+"
                type: patch
                options: {peer=nsx-switch-}
        Port "nsx-eth0-peer"
            Interface "nsx-eth0-peer"
    ovs_version: "2.9.1.8614397"
```

## ネットワークネームスペースの状態

```
masanara@ubuntu-nsxcloud-01:~$ ip netns
nsx (id: 0)
nsx-root

masanara@ubuntu-nsxcloud-01:~$ sudo ip netns exec nsx ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000
    link/ether 00:0d:3a:51:ea:d8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::20d:3aff:fe51:ead8/64 scope link
       valid_lft forever preferred_lft forever
3: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 36:30:db:7c:09:20 brd ff:ff:ff:ff:ff:ff
4: nsx-managed: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:0d:3a:51:ea:d8 brd ff:ff:ff:ff:ff:ff
5: nsx-switch: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 00:0d:3a:51:ea:d8 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.8/24 brd 10.1.1.255 scope global nsx-switch
       valid_lft forever preferred_lft forever
    inet6 fe80::20d:3aff:fe51:ead8/64 scope link
       valid_lft forever preferred_lft forever
6: nsx-eth0-peer@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP group default qlen 1000
    link/ether 00:0d:3a:51:ea:d8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::20d:3aff:fe51:ead8/64 scope link
       valid_lft forever preferred_lft forever

masanara@ubuntu-nsxcloud-01:~$ sudo ip netns exec nsx-root ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
7: nsx-eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:0d:3a:51:ea:d8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.1.1.8/24 brd 10.1.1.255 scope global nsx-eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20d:3aff:fe51:ead8/64 scope link
       valid_lft forever preferred_lft forever
```

# まとめ

オンプレミスのNSX-Tを利用してAzure上の仮想マシンのセキュリティポリシーを制御することができました。[SaaS版ですでにAWSへは対応できている](https://qiita.com/masanara/items/fb7ddd3b3245416295ff)ので、今後のリリースでAWS/Azure/OnPremiseのワークロードのセキュリティポリシーをNSX-Tから統合管理することが可能になります。