VMware Carbon Black Cloud はじめの手引き

本記事はvExperts Advent Calender 2020の15日目です。

 

はじめに

EDRを触ったこともない仮想化エンジニアが、VMware Carbon Black Cloud(以下CBC)を触る機会に恵まれたので、学んだことを順次共有していければと考えています。今回は、はじめの手引きということでCBCの構築についてお伝えします。CBCクラウド製品のため、他のVMware製品に比べて触れる機会が少ないのが現状かと思います。VMware Handson Labにもカタログは存在しますがシミュレーターのようでしたので、可能な限り実機のスクショを交えてお伝えしていければと思います。

なお、私は仕事でVMware製品を拡販していますが、本ブログは所属会社に一切関係ありませんのでご了承ください。

Carbon Black Cloudへのログイン

はじめに、CBCは管理コンソールへログインしないと何も始まりません。CBCを購入するとVMwareから以下のようなメールが届くので、オレンジ色のConfirm my AccountをクリックしてCBCのリンクへ飛びます。

f:id:kncyd13:20201215220637p:plain

初回はアカウントのパスワード設定がありますが、設定が終わると以下のログイン画面へ遷移し、ログインできます。

f:id:kncyd13:20201215220825p:plain

新しいユーザーを追加する場合は、メールアドレスの入力とロールの選択が必須です。管理コンソールでユーザーを作成すると指定されたメールアドレスへアクティベートメールが送信されるので、先ほどと同じようにパスワード設定することでログインできます。

設定>ユーザー>ユーザーを追加

f:id:kncyd13:20201215220946p:plain

CBCのログインURLとユーザーアカウントについて補足します。たまたま複数のCBC環境を見る機会があったのですが、以下のような関係が見られました。

f:id:kncyd13:20201215221057p:plain

この図は、管理者が3つの異なるCBC環境(図中ではテナントとしています)へログインしていることを表現しています。まず、URLの数に注目してください。テナントは3つにもかかわらず、URLは2つです。この事実から、CBCは単一のURLで提供されているサービスではないことがわかります。テナントAとBは同一のURLなので、購入時点で複数のURLから1つ割り当てられるものと思われます。次に、ユーザーアカウントに注目してください。テナントAへはユーザーAでログインし、テナントBへはユーザーBでログインしています。テナントAとBはURLが同一であるため、ユーザーを分けることでログイン先のテナントを指定しているわけです。この状態で、テナントBへユーザーAを登録すると、テナントBへログインしたくてもテナントAへログインしてしまいます。基本的に複数のCBC環境を購入することは考えられませんが、PoCと本番とで異なる環境を使用する場合などにURLが同じだとユーザーの重複が問題となる可能性があります。なお、Gmailなどのエイリアス機能を使用すればログインユーザー名が変わることとなるため、この問題は回避できます。

Carbon Black Sensorのインストール

CBCでは管理対象にCarbon Black Sensor(以下CB Sensor)をインストールする必要があります。インストーラーは管理コンソール上で入手可能です。

インベントリ>エンドポイント>センサーオプション>センサーキットをダウンロード

f:id:kncyd13:20201215221312p:plain

サポートされているインストール対象OSのリストについては以下のURLを参照ください。Carbon Black Communityのアカウント作成が必要となります。

https://community.carbonblack.com/t5/Documentation-Downloads/Carbon-Black-Cloud-sensor-support/ta-p/66274

VMware HorizonのVDI環境にインストールする場合は、以下の互換性情報にご注意ください。マスターイメージへのCB Sensorインストール方法も書いてあります。

https://kb.vmware.com/s/article/79180

CB Sensorのインストール方法は2つあります。Attended Install(GUI)とUnattended Install(CLI)です。Attended Installは招待メールによるインストール方法で、正直、あまり使われないと思います。Unattended Installは配布ツールなどを用いたインストール方法で、コマンドによるオプションをつけることができます。以下はUnattended Installでインストールした様子です。

f:id:kncyd13:20201215222157p:plain

  • コマンドプロンプトは管理者として実行
  • [sc query cbdefense] でCB Sensorの状態を確認、STATEがRUNNINGであればインストール完了
  • [msiexec]で始まっている部分がインストールコマンド
  • 今回実行したオプションの意味
    [/q] サイレントインストール
    [/i] インストールファイルのディレクトリ指定、ダウンロードしたセンサーキットのパスが続きます
    [/L] 詳細インストールログの出力指定
    [COMPANY_CODE] 登録先CBC環境(テナント)の指定
    [GROUP_NAME] インストール時のポリシーの指定
    [CLI_USERS] 管理用コマンドの有効化
    [CURL_CRL_CHECK] CRLチェック、0で無効化

以上でCB Sensorのインストールは完了です。これでデバイスはCarbon Blackによって保護されている状態となりました。

f:id:kncyd13:20201215230139p:plain

CB Sensorをインストールする端末には必ずポリシーを適用する必要があります。今回は事前に「test-policy」というポリシーを作成した上で、[GROUP_NAME]オプションで指定していますが、何も指定しない場合には、予め用意されている「Standard」が適用されます。

f:id:kncyd13:20201215231100p:plain

さいごに

今回はCBCへのログインとCB Sensorのインストールについてお伝えしました。CBCは他のVMware製品に比べて、非常に少ないステップで構築できることが分かります。今回は説明できていませんが、CBCにおいてポリシーは非常に重要な要素です。防御ルール、ローカルスキャンの有効化、シグネチャの更新、他のAV製品のバイパスなど様々な設定をポリシーで行うこととなるため、次回はポリシーについて深掘りしていこうと思います。

NSX-T Edge のポイント

2020年に入り、VMware NSX-Tがこれまで以上に注目されています。また、それには様々な理由があると感じています。主だった要因としては、VMC on AWSに代表されるVMware Cloudに採用されていること、VCFに含まれていること、vSphere 7 with Kubernetesに必須のインフラであること、更改時期を迎えているVDI環境のインターネット分離に必要なこと、などが挙げられるのではないでしょうか。

そして、注目度が高まるにつれ、NSX-Tのキャッチアップを始める方が増えていると感じます。NSX-TはNSX-vを知っていたとしても難しく感じます。なので、少しでも理解が深まるようなポイントを取り上げて解説していきます。今回はNSX-T Edgeです。

私は仕事でVMware製品を拡販していますが、本ブログは所属会社に一切関係ありませんのでご了承ください。ただのエンジニアとして情報をアウトプットし、その結果、誰かの助けになれば嬉しいなというモチベーションで書いてます。

また、本ブログはNSX-T 3.0時点の情報で書かれています。アーキテクチャコンポーネント、単語などの解説は含まれていないため、VMware Docs等で補完していただければと思います。

VMware NSX-T Data Center のドキュメント

 Edge はあくまでリソース

Edgeは仮想マシンとしてvSphere環境にデプロイするか、物理サーバにインストールします。今回は、仮想マシンを想定します。Edgeは関連するサービスを提供するためにCPU、メモリ、ストレージといったリソースが必要なため、仮想ハードウェアでこれらを提供します。あくまでリソースなので、環境の規模や使用するサービスに応じてサイジングが必要となります。

EdgeサイズはSmall、Medium、Large、Extra Largeから選択します。サイジングの目安としては以下のイメージです。

  • Small:ラボやPoc
  • Medium:ハイパーバイザー64台以下の本番環境
  • Large:ハイパーバイザー64台以上の本番環境、または、ロードバランサを使用する場合
  • Extra Large:ロードバランサの負荷が高くリソースがLargeで足りない場合、または、URLフィルタリングやL7ファイアウォールといったアドバンスサービスを使用する場合

リソース要件やサイジングの公式ドキュメントは以下リンク先を参照してご確認ください。

NSX Edge 仮想マシンのシステム要件

実際にTier-0ゲートウェイなどをEdgeにホストする場合、Edgeではなく、Edge Clusterを選択します。Edge Clusterは複数台のEdgeを束ねたオブジェクトです。仮に、Edgeが1台だけであったとしても、Edge Clusterには追加する必要があります。

f:id:kncyd13:20200830221311p:plain

Edgeは物理ネットワークとの接続点

例えば、NSX-Tで自由にオーバーレイネットワークを構築しても、物理ネットワークとの接続点がなければインターネットを含む物理環境とアクセスできません。EdgeはvNICを仮想スイッチに接続することでオーバーレイネットワークと物理ネットワークを繋げます。Edgeには計4つのvNICがあり、それぞれEdge内部のインターフェイスとリンクしています。

詳細については以下リンク先を参照ください。

NSX Edge のネットワーク設定

eth0は管理ネットワークで固定ですが、あとはEdgeが属するトランスポートゾーンで変わります。仮に、Edgeがオーバーレイトランスポートゾーンに属する場合、fp-eth0はOverlay N-VDSにリンクされます。EdgeがVLANトランスポートゾーンに属する場合、fp-eth1はVLAN N-VDSのアップリンクセグメントにリンクされます。そして、冗長構成を目的に、Edgeが物理ネットワークと2つの接続点を持つ場合、fp-eth2もVLAN N-VDSのアップリンクセグメントにリンクされます。冗長化が目的のため、fp-eth1とfp-eth2は異なるVLANに設定します。

f:id:kncyd13:20200830233537p:plain

続いて、2台のEdgeが追加されたEdge Clusterに、Tier-0ゲートウェイをホストした構成のアップリンク接続について考えてみます。Tier-0ゲートウェイの作成では対象となるEdge ClusterとHAモードを選択します。HAモードはActive-Standby、または、Active-Activeを選択でき、それぞれ使用できる機能が異なります。例えば、Active-StandbyならゲートウェイファイアウォールやNATのようなステートフルサービスが使用できる、といった具合です。Active-Standbyで設定した場合、Tier-0ゲートウェイはEdge01とEdge02にそれぞれホストされ、障害発生時にはフェイルオーバーします。

f:id:kncyd13:20200830233600p:plain

Edge TEPの注意点

NSX-Tでオーバーレイネットワークを使用する場合、仮想マシンやコンテナが実行されているホストトランスポートノード(ESXiやKVM)と同じオーバーレイトランスポートゾーンにEdgeを追加する必要があります。これは、物理ネットワークへの接続点を持つEdgeへ、ホストトランスポートノードから通信が到達するために、Geneveカプセル化プロトコルのトンネルエンドポイント(以下TEP)をEdgeに作成する必要があるためです。しかし、Edge TEPのIPアドレスを設定する際には、Edgeのデプロイ場所に依存する問題に注意が必要です。

NSX-Tでは3つのクラスタデザインが紹介されています。検証や学習目的でNSX-T環境を構築する際には、多くの場合、小規模DCデザインのシングルクラスタ構成が採用されるかと思います。

f:id:kncyd13:20200830235815p:plain

シングルクラスタの場合、ホストの台数は少なく、高確率でホストトランスポートノード上にEdgeトランスポートノードをデプロイする構成となります。また、IPアドレスプールもホストトランスポートノードとEdgeトランスポートノードでわざわざ分けるようなことはせず、TEP用と一括りにするかと思います。このような構成で、EdgeのTEPとリンクされているvNICをNSX-Tが管理するVDS 7.0やN-VDSに接続すると、Edge TEPが他のTEPとトンネルを張れない問題が発生します。

f:id:kncyd13:20200831011713p:plain

この問題には3つの回避策があります。1つ目は、中規模DCデザインのようにコンピュートクラスタとEdgeクラスタを分け、ホストトランスポートノード上にEdgeトランスポートノードをデプロイする構成を避けること。2つ目は、ホストTEPとEdge TEPで使用するIPアドレスプールを分け、ホストTEPとEdge TEPを別VLANにすること。3つ目は、Edge TEPがリンクされているfp-eth0を、NSX-Tで管理していない仮想スイッチに接続することです。

偶然にもこの問題は、検証や学習環境の構築時に条件を満たしやすいです。ホスト間はトンネルが張れているにもかかわらず、Edgeとはトンネルが張れない場合、この問題を疑うのが、解決への近道となるかもしれません。

また、この構成に関連するKBも出ています。

VMware Knowledge Base (70745)

KBはEdge TEPがリンクされたvNICを、トランクのポートグループや論理スイッチに接続しないでくださいという内容です。

今回取り上げた問題は設定次第で解決できるものでしたが、このようなトラブルを未然に回避するためにも、コンピュートクラスタとEdgeクラスタは分けた方が良さそうです。

 さいごに

今回はNSX-T Edgeについて、ドキュメントだけではイメージしづらい内容や、私が検証環境を構築した際に直面した問題を取り上げてみました。正直、Edge上でホストするサービスの方がより抽象的で理解するのが難しいと思うので、今後の投稿でゆっくりと紐解いていこうと思います。