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

NSX Cloudとは

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

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の管理に関してはこちらを参照してください。

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つのサブネットに接続されます。

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スクリプトを利用した方法が掲載されています。

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を登録します。
   

2. CSMにAzureのアカウント情報を登録
   Azure Active Directoryに構成した情報(Webアプリ/APIのアプリケーションID、キー)、Subscription ID、Tenant IDを使ってCloud Accountを登録します。
   

Public Cloud Gatewayのデプロイ

1. CSMに対してAzureアカウントを設定すると、Azure内のVNetや仮想マシンの情報がCSM上に表示されます。
   

2. NSX Cloudの管理対象とするVNetのActionsからDeploy NSX Cloud Gatewayを選択して、PCGのデプロイを開始します。
   

3. 管理アクセスに利用するSSH用の公開鍵を指定し、PCGを作成するクラウドアカウントを選択します。デプロイ後のPCGにはnsxadminユーザーでログイン可能です。(セキュリティグループでSSHの通信を許可する必要があります)
   

4. PCGを接続する3つのサブネットを指定します。Management IPにはパブリックIPを割り当てます。(以下の例ではHAを無効化してSingle構成のPCGをデプロイしています)
   

5. しばらくすると、VNetにPCGが仮想マシンとしてデプロイされ、CSM上でGatewayがUp状態になります。
   

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

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

仮想マシンの作成

NSX Cloudが対応している仮想マシンはマニュアルに記載があります。対応する仮想マシンイメージを利用して仮想マシンを作成します。仮想マシンは_Downlinkサブネット_に接続し、ネットワークセキュリティグループはSSHやRDP等必要な通信を許可します。

NSX Agentのインストール

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

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による管理が可能になります。
マイクロセグメンテーションモードで利用する場合は、nsx.network=defaultをタグとして追加します。

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

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

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

NSGroupの作成

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

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

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

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

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へは対応できているので、今後のリリースでAWS/Azure/OnPremiseのワークロードのセキュリティポリシーをNSX-Tから統合管理することが可能になります。