2016年10月16日日曜日

NSXコンポーネントの起動とシャットダウン手順

NSX for vSphere(NSX-v)は、NSX ControllerやNSX Manager、Edge Service Gatewayなどかなりのアプライアンスが展開されます。

例えば電源設備のメンテナンスなどでESXiホストの電源などを落とす際にどの順序で落とすのが正なのかというのが、わからないというケースに出会うこともあるかと思いますので、今回は、シャットダウン及び、起動の手順をお伝えします。


<シャットダウン順序>
  1. セカンダリNSXマネージャーのシャットダウン(マルチvCenterの場合のみ)
  2. プライマリNSXマネージャーのシャットダウン
  3. プライマリサイトNSX コントローラーのシャットダウン
  4. 分散論理ルーター(DLR )制御VMのシャットダウン
  5. 一般仮想マシン及びGuest Introspection、NSX Edge等のNSX関連仮想マシンのシャットダウン
    (シャットダウンの順序は任意)
  6. ESXiホストのシャットダウン


<起動順序>
  1. ESXiホストのパワーオン
  2. vCenter Serverのパワーオン
  3. NSX Managerをパワーオンし、「NSX Management Service」が起動していることを確認
    (マルチvCenter構成の場合は、はじめにプライマリNSX Managerを、次にセカンダリNSX Managerを起動します)
  4.  Guest Introspection及びNSX関連のサードパーティーVM(たとえば、Deep Security Manager等)を起動します。
  5. NSXコントローラーをパワーオン
  6. vSphere Web Clientから「Network and Security」の「インストール手順」項の「管理」タブの「NSX コントローラーノード」を確認し、NSXコントローラーが正しく起動及びNSX Managerによって認識されていることを確認します。※
  7. NSX Edge及び分散論理ルーター(DLR )制御VMのパワーオン
  8. 一般仮想マシンのパワーオン

※NSXコントローラーの確認場所



シャットダウン手順に比べ、起動手順は少々順序が厳しいので注意が必要です。
UPS連携は、スクリプトでの対応が必要になるかと思います。

より詳細な手順は以下のKBを参考にしてください。

Shutdown/Startup order of the NSX for vSphere 6.x environment after a maintenance window or a power outage (2139067)








2016年10月10日月曜日

NSX for vSphereのSSLVPNを使ってみよう(その1)

NSX for vSphereで提供される、Edge Service Gatewayには、「SSL VPN Plus」と言われる、端末VPNの機能が提供されています。
これ、あまり知られていないケースが多いのですが、いわゆる端末にインストールしてSSLでVPNトンネルを張ることができる製品です。

このSSL VPN Plusですが、元々は、NeoAccel社のSSL VPN Plusをカスタマイズしたものになっています。そもそもNeoAccel社をVMwareが買収したことで、Edge Service Gatewayに実装されているようです。
このNeoAccel社のSSL VPN Plusですが、あまり見覚えはないかもしれませんが、6年ぐらい前にアライドテレシスがSSL VPN Plusという形で、独自アプライアンスにSSL VPN Plusを導入したアプライアンスを販売していました。


[アライドテレシスのホームページより]

(参考)https://www.allied-telesis.co.jp/products/list/others/sslvpn/sslvpnplus/catalog.html

このページを見てもらえればわかりますが、ユーザーサイドの画面は今でもほとんど変わっていません...。


NSX SSL VPN Plusで提供されるWindowsクライアントの画面



ちなみに、対応クライアントはNSX-v 6.2.4の場合以下となります。

OS対応バージョン
WindowsXP以降~Windows 8
Linuxユーザー インターフェイスを機能させるには TCL-TK が必要です。
TCL-TK がない場合は、CLI を使用します。
MacTiger、Leopard、Snow Leopard、Lion、Mountain Lion、Maverick、Yosemite、ElCapitan


NSX-vでSSL-VPNを利用すると、CPUライセンスでNSXを購入した場合、そのESXiホストにEdge Service Gatewayを大量に展開すれば、大量のユーザーに対して安価にSSL-VPNを提供することも可能です。

尚、1つのESGで接続できる最大ユーザーは以下が最大値となっているようです。

ESGのサイズ最大接続数
compact50
large100
quad-large100
x-large1,000

(参考)https://d-fens.ch/2015/02/16/nsx-v-6-1-configuration-maximums/

次回から、SSLVPNの利用するまでの設定方法とAD連携などをご紹介したいと思います。









2016年9月30日金曜日

VMware Software Managerの紹介

MyVMwareサイトには、自分がライセンスを保有するVMware製品の一覧が表示され、必要に応じて製品のダウンロードが可能です。
一般的に稼働しているシステムに対して頻繁にバイナリをダウンロードすることはないかと思いますが、検証する場合には、様々な製品を組み合わせてダウンロードする必要があり、いちいちブラウザーからダウンロードするには少々面倒なケースがあります。

そういった際に利用すると少し便利になるのが、「VMware Software Manager」です。
こちらは、既存製品のバージョンアップ等を管理するUpdate Managerのようなインテリな伊勢品ではなく、単純に、VMware製品をダウンロードを手助けしてくれる製品です。

この製品はMyVMwareアカウントがあれば誰でもダウンロード可能なようです。
(ただ、製品をダウンロードするためにはライセンスガ紐付いたMyVMwareアカウントが必要です)

バイナリはMSIファイルで提供されており、WindowsOSにインストールして利用します。

あとは、ブラウザーで「localhost:8000」で、接続します。

最初にMyVMwareアカウントの紐付けを行いますと、以下のような製品一覧が表示されます。



この製品カテゴリからドリルダウンして、必要なバイナリを選択します。

製品に必要なファイルは、まとめて一括でダウンロードされますので、ブラウザーで一つでダウンロードするよりも大変楽です。(ダウンロードされるファイルの一覧も表示されます)




ただ製品カテゴリーがSDDCまわりに限られているようで、Horizonまわりの製品は一覧に上がってきませんので、注意が必要です。

検証環境などで素早くバイナリが必要なときなどに是非活用されるのは如何でしょうか?









2016年8月27日土曜日

NSX for vShield Endpointの各社サポート状況がKBに掲載されています

NSX for vSphere 6.2.4により、NSX for vShield Endpointなるライセンスが発表されたことを記載しました。
この新しい形のエージェントレスのウイルス対策には、当然ながらアンチウイルスソフトベンダーの協力なしに、なし得ない機能でもあります。

さて、ではアンチウイルスベンダーの対応状況はというと、KB2110078で公開されています。

ここには、実に興味深い内容が掲載されています。


NSX 6.2.4 vShield Endpoint Certification Planner
PARTNERPRODUCTNSX 6.2.4 CERTIFICATION TARGET
BitDefenderGravityZone SVE version 6.1September, 2016
Trend MicroDeep Security 9.6 (Version 7314 or higher)September, 2016
Intel Security (McAfee)MOVE 4.0October, 2016
ESETESET Virtualization Security for VMware NSX v1.5November, 2016
KasperskyKaspersky Security for Virtualization 4.0Q4 - 2016
SymantecDCS 6.7Q1 - 2017
SophosSophos Anti-Virus for VMware vShieldContact Vendor

(参考)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2110078

これを見ると、DeepSecurity9.6も、今すぐにはNSX for vShield Endpointには対応していないようですね。
興味深いのは、ESETの掲載があることです。ESETもついにエージェントレス版を提供するようですね...。






NSX for vSphere 6.2.4の登場とfor vShield Endpointエディションが無償で登場

NSX6.2.3がリリースされましたが、一部不具合があり、一度撤回されましたが、昨日ついに、NSX for vSphere(NSX-v) 6.2.4がリリースされました。
これは、NSX-v 6.2.3の改修版となり機能としては、6.2.4と変わりがありません。

しかし、6.2.3のリリースノートには、かなり大きな変更がたくさん加わっています。

その1つは、「VXLAN」の通信ポートです。
NSX-vは、VXLANのRFCに正式に認定される前に利用してた8472/UDPを利用していましたが、NSX-v 6.2.4から、4712/UDPに変更となります。
これは、大変大きな変更です。これには、Hardware VTEPが正式にサポートされることによる仕様に変更だと思われます。

さらに驚くべきことは、「vShield Endpoint」のサポート終了とNSX for vShield Endpointのリリースです。

vShield Endpointは、vCloud Network and Security(vCSN)の1機能として提供され、ESXi上にいる仮想マシンに対して、エージェントレスなウイルス対策機能を提供する製品でした。

vSphere5.1のリリースとともに、vShield Endpointに関しては、vSphereの1機能として提供されるようになり、vSphere Essentiauls Plus以上を保有していれば、無償で利用できるライセンスとなりました。

ここrで、vShield Endpointは、vCNSファミリーではなく、vSphereファミリーとなったのですが、vShield Endpointを利用するためには、vShield Managerが必要であることから、vShieldのファミリーであると認識をされていました。
ただ、vCNSが、2016年9月でサポートが終了されることから、vShield Endpointはどうなるのかという話が出ており、VMwareは、KB2128156で、
「VMware vShield Endpoint as part of vSphere 6.0 will follow its lifecycle with current end of general support occurring on March 12, 2020. For more information, see the VMware Lifecycle Product Matrix.」と記載しており、vShield Endpointは、vSphere6のサポート期限に紐づくものであると記載をしていました。(このKBはすでに削除されています)

当時のKB


(参考)VMware vCloud Networking and Security Manager support of vShield Endpoint (2128156)
http://web.archive.org/web/20150909045150/http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2128156 

しかし、最近出たKBを見ると状況が変わっており、vShield Endpointは、vShieldファミリーと同じく、2016年9月にサポートを終了すると発表がなされております。

(参考)Implementation of VMware vShield Endpoint beyond vCloud Networking and Security End of Availability (EOA) (2110078)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2110078

これにより、新しく登場したのが、「NSX for vShield Endpoint」になります。
vSphere Essentials Plus以上のライセンスを保有しているユーザーは、みなNSX Managerをダウンロードする権利を有し、「NSX-v for vShield Endpoint」ライセンスが自動的に付与されることとなります。

(参考)vSphere Essentiauls Plusライセンス保有ユーザーでもMyVMwareからNSX関連のバイナリがダウンロード可能


このNSX for vShield Endpoint ライセンスでは、カーネルモジュールで動作するVXLANや分散ファイアーウォール機能などは利用できず(モジュールインストールをしようとするおとライセンスが不足している旨のメッセージが表示される)、Guest Introspectionが展開できるだけという機能制限がかかっています。(もちろん、NSX for Standard以上のライセンスを適用すればそのロックは解除されます)

今まで、vShield Endpointを利用していたユーザーさんは、2016/9/19までに、NSX for vShield Endpointに乗り換える必要があります。

NSX Managerは、メモリーが16GB必要であることも注意点ですので、既存のvShield Endpointユーザーさんは、リソースの空き具合を含めて今一度確認をして以降に備えましょう。(といっても時間があまりありませんが)







2016年8月21日日曜日

vSphere6から誕生したPSCとSSOについておさらい

vSphere6が出て1年半が経とうとしています。
もう、この時期から新規構築でvSphere5.xを選択するケースは少なくなってきたかと思います。


vSphere6では、様々なところでアーキテクチャーの変更が加えられておりますが、構築の時点で一番に気が付くのは、vCenter Server Applianceのデプロイ方法だと思います。
昔は、OVFをぽいっとするだけで終わっていたのですが、今では少々面倒はWebのウィザードを経由してデプロイをする必要があります。

一方で、Windows版のvCenter Serverは、Embeded DBのアーキテクチャーが、PostgreSQLに変わったぐらいで、あまり変化がないように思いますが、プラットフォームに関係なく大きくアーキテクチャーが変わっているところがあります。

それが、「PSC」の存在です。
PSCは、Platform Service Controllerという名前で、vSphere5.5まであった、SSOの後継となります。

その昔、vSphere5.0までは、ADが必須という条件がありましたが、vSphere側にSSO機能を持つことで、AD必須という条件が取れたことは、非常に大きなアップデートだっだように思います。
(もともとV4.xやV5.0のvCenter Serverでも非サポートながら、Workgroupでのイストールで動作していた実績がありますが)

PSCは、従来のSSOと違い、
  • Single Sign-On (SSO)
  • ライセンス
  • 認証局
  • 証明書ストア
  • サービス(製品)登録
の機能を保有しています。

さらに、このPSCと今までのvCenter Serverは、独立した仮想アプライアンス(仮想マシン)として展開することも可能です。

ここで重要になるのは、vCenter ServerとPSCは、サーバーをまたいで通信をする構成になっているということです。
ということは、PSCとvCenter Serverで、きちんと名前引きができるDNSを構築しておかなければならないという事情があります。

PSCとvCenter Serverを同一の構成で作成すれば、同じホスト名だから問題ないよねと思うケースもあるかもしれませんが、NSX ManagerやvShield Managerなど、PSCを経由して、vCenter Serverと接続する連携製品は、それら連携製品がPSCとvCenter Serverの両方のホスト名を名前引きできないと、ただしく接続できません。

ここで、ポイントです。
vCenter Serverをインストールする際に、PSCを共にインストールをしますが、PSCをインストールする際に定義されたホスト名が、そのままPSCで構築されるSSOのURLの一部として利用されます。

Windows Serverにインストールする際、あらかじめホスト名にドメインサフィックスを入れてないと、そのホスト名だけがSSOのURLとして利用されるため、NSX ManagerのようなほかのアプライアンスからSSOにアクセスする際、FQDNになっていないため、SSOサーバーにたどり着けず、認証に失敗するケースがあります。(検索ドメインを定義おり、DNS名で名前引きができれば通信は可能です)


上記から、vSphere Web Clientにアクセスするとまず、PSCにSAML認証されていることがわかります。

vCenter Serverをインストールする際は、
  • DNSサーバーを構築し、vCenter Server、PSC(別立てする時)の正引き、逆引きをかならず設定する
  • Windows版の場合、vCenter Serverのインストール前に、DNSドメインサフィックスを設定し、ホスト名をFQDNの形式で設定をする
の2つを忘れないことが、とりあえずvCenter Server入ったけど、外部製品との連携ができないとか、vSphere Web Clientが正しく開けないといったトラブルを防ぐことができます。



2016年8月12日金曜日

NSX fro vSphere 6.2.3のリリース中止

NSX for vSphere 6.2.3(NSX-v)がリリースされましたが、現在、バイナリのダウンロードは中止されています。

NSX-v 6.2.3では、VXLANのポート番号がRFCに準じた「4789/UDP」(以前まではドラフト時代の8472/UDPで動作)に変更になるなど、マイナーバージョンアップのバージョンナンバーですが、かなり大きな変更が入っていました。(これはHW-VTEPの絡みでしょうね)

さて、このNSX-v 6.2.3ですが、上記のとおり現在はバイナリがダウンロードできません。その理由は、リリースノートにも記載されていますが「KB:2146227」が要因のようです。

要は、分散ファイアーウォールでSecurity Groupで定義した仮想マシンが分散ファイアーウォール処理されたときに、その仮想マシンがvMotionしてしまうと、通信が一切できなくなるという問題です。

分散ファイアーウォールとvMotionとは、NSXとvSphereのそれぞれのいいところを使うと発生する問題であり、実業務に影響が出る問題と思われます。
そのため、この問題が解決するまで6.2.3のバイナリは提供中止になったようです。

NSX-v 6.2.2は提供されていますので、現況では6.2.2を利用するしかなさそうですね。

KBは、日本語版も新たにリリースされましたので併せて紹介しておきます。

(参考)
NSX 6.2.3 をインストールまたはこれにアップグレードした後に SG を使用する DFW ルールが仮想マシンに正しく適用されない (KB:2146401)
http://kb.vmware.com/kb/2146401





ゼロクライアントからHorizon Viewに接続できなくなった

Horizon View 6.2.2から採用された「TLS1.0」のデフォルト無効化。
これが、Tera1チップを搭載したゼロクライアントでは、どうやら問題になるようで、私の利用する環境では、以下のような画面が出てゼロクライアントからVDIの環境にログインできなくなりました。

「セッションネゴシエーションに失敗しました。ゼロクライアントはホストのセッションネゴシエーションの暗号設定と互換性がない可能性があります。」とのこと。

TLS1.2等で接続をしてくれればよいのですが、どうやらTLS1.0で接続をしているようでそれが仇になっているようです。

さて、この場合の対策ですが、Connection Serverにレジストリで「TLS1.0」を許可することで対応可能です。(TLS1.0を許可することが事態はセキュリティを低くすることになるので、お勧めではありません)LANなど閉じられた環境下で引き続きTera1のゼロクラを利用したい場合はこの手法を使うことで回避できます。

キーの場所:HKLM\Software\Teradici\SecurityGateway
キー名称: SSLProtocol
型: REG_SZ
値: tls1.2:tls1.1:tls1.0

値に、「tls1.0」が入っているのがポイントです。

これで、tera1チップを積んだゼロクライアントでも、接続可能になります。

(参考)Configuring security protocols on components to connect the View Client with desktops (2130798)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2130798





2016年7月10日日曜日

Horizon Viewで、AD証明書認証局から証明書をもらう方法

最近、インターネットの無害化などで、Horizon Viewを検討されるユーザーさんが増えているようです。Horizon Viewを利用すれば、VDIももちろんですが、RDSHを利用した低コストなインターネットブラウザーの配布も可能になります。もちろん、管理も楽になり、セキュリティリスクもHorizon Viewを導入することで大幅に低減します。

さて、Viewを利用するためにまず1番最初に必要なのは「Connection Server」ですね。別名Manager Serverなどとも呼ばれることがあります。
(Connection Serverの前にADやvSphere基盤は必要ですが・・・)

View Administeratorにログインすると、各サーバーのステータスが表示されますが、デフォルトですと接続サーバー(Connection Serverのことですね)が赤くなっており、証明書が公的機関のものではないと怒られています。


 
大規模やお堅い企業でセキュリティを意識される場合は、公的機関から証明書を取得して入れるのがベストであると思いますが、小規模な環境等では自社の証明局を利用するか、そのままオレオレ証明書のまま突っ走るかという話になるかと思います。

ただ、最近のHoriozon Clientでは、デフォルトですと公的機関証明書(認証局情報を持っていないいわゆるオレオレ証明書)での接続を行うと、「証明機関が無効または不正です。」と、なんとも冷たいエラーメッセージが出てしまいます。



この場合、Horizon Clientのオプションを変更することで、接続可能になります。
右上のメニューから「SSLを構成」を選択します。


ここで、「サーバーID証明書を検証しない」を選択し、OKをクリックします。


これで、解決はできますが、まあ、公的証明機関とは言わずとも、自社の認証局からの証明書でも入れて解決する方が、このオプションをユーザーごとに都度入れるよりもかっこよいですし、手間も省けますね。

View Connection Serverに、証明書を組み入れるのは少々手間がかかりますので、今回はAD上にWindowsの証明書サーバーがある前提で、楽に証明書の入れ込みを行う方法をお伝えしたいと思います。


まずは、あらかじめActiveDirectory内に証明書サーバーを構築しておいてください。


まずは、View Connection Serverがインストールされたサーバーにログインし、「ファイル名を指定して実行」をクリックします。
実行プログラムで「mmc.exe」を入力し、Enterキーを押します。


MMCコンソールを開いたら「ファイル」→「スナップインの追加と削除」をクリックします。


利用できるスナップインの項目を一番下までスクロールし「証明書」を選択し「追加」をクリックします。


スナップインで管理する証明書:で、「コンピューターアカウント」を選択します。


現在View Connection Serverで操作をしていますので、コンピューターの選択は、「炉k-刈るコンピューター」を選択し、完了をクリックします。


これで、スナップインの登録が完了しました。「完了」をクリックします。


コンソールルートの証明書から「個人」→「証明書」を選択し、現在View Connection Serverで利用されている証明書が存在していることを確認します。

Viewで利用されているかどうかを確認するためには、確認したい証明書を右クリックし「プロパティ」を開き、「フレンドリー名」が「vdm」が記載されているものになります。
※証明書をダブルクリックしても、プロパティは開きません。必ず右クリックからプロパティを引きましょう。


証明書のフォルダを右クリックし「すべてのタスク」→「新しい証明書の要求」をクリックします。


 開始する前のウィザードが表示されますので「次へ」をクリックします。


今回は既存のADに存在する証明書サーバーを利用しますので、そのまま「次へ」をクリックします。


WebサーバーというポリシーはWindowsデフォルトで存在するテンプレートになりますのでこちらを選択し、「この証明書を登録するには情報が不足しています。設定を構成するには、ここをクリックしてください」という文字をクリックします。


いろいろな項目がありますが、無理にすべての情報を入れる必要はありません。
最低限、「共通名」(Common Name)の記述が必要です。
例えば、ユーザーから「viewcon.labo.local」というドメイン名でView Connection Serverにアクセスされる場合は、そのまま「viewcon.labo.local」と入力します。
共通名には、外部からアクセスされるFQDNを記入します。
共通名を入れるだけでも証明書としては一応発行可能ですが、必要に応じて、国や地域名、組織名などは入れておいた方がよいかと思います。




次に、「拡張機能」タブを選択します。
選択後、「キー使用法」を選択し、「CRL証明、データの暗号化、暗号解読のみ、暗号化のみ、キーの承諾、キー証明書の署名」を選択し、「追加>」をクリックします。

さらに、下にスクロールし「基本制限」の項から「この拡張機能を有効にする」、「重要な機能制限拡張機能として登録する」、対象アルゴリズムの項から「この拡張機能を有効にする」にチェックを入れます。


次に「秘密キー」タブをクリックし、「秘密キーをエクスポート可能にする」、「秘密キーのアーカイブを許可する」をチェックを入れ、最後にOKをクリックします。



正常に値が反映される黄色の!で、表示されていた「この証明書を登録するには情報が不足しています。設定を構成するには、ここをクリックしてください」というメッセージが消えていることを確認します。


これで、発行は完了です。「完了」をクリックします。


さて、これで新しい証明書が発行されましたが、これをViewで利用できるようにします。
まずView Connection Serverインストール時に自動的に発行された、デフォルトの証明書のフレンドリー名を変更します。
尚、インストール時に発行された証明書は、発行者がコンピューター名のFQDNと同じになっていますので、それで判断が可能です。


フレンドリー名がvdmになっているので、これを違う名前に変えて「OK」をクリックします。


次に、先ほど発行した証明書を同じように右クリックし「プロパティ」を開きます。


こちらのフレンドリー名を「vdm」にし、OKをクリックします。


これで、作業は完了です。MMCコンソールを閉じて、Viewのサービスを再起動します。

サービス再起動後、View Administratorの画面にログインし、アイコンが緑になっていれば証明書の問題はクリアーになります。


VMwareからは、コマンドラインで証明書を要求する方法がKBとして出ていますが、この方法であれば、マウス操作だけで簡単に証明書を組み込むことができます。

検証環境であってもオールグリーンがお好きな方は、是非やってみてください。



2016年6月5日日曜日

NSXのセキュリティタグをAPIで活用してみよう(その3)

実際に、セキュリティタグを仮想マシンに付与するためには、セキュリティタグIDと仮想マシンIDが必要になります。

今回は、「ANTI_VIRUS.VirusFound.threat=low」のタグを仮想マシンに付与したいと思います。
先ほど、Postmanで取得したXMLをみて、<objectId>の部分を確認し、事前に控えておきましょう。
タグの名称は<name> で確認できます。


今回の場合は、「securitytag-2」が、「ANTI_VIRUS.VirusFound.threat=low」のIDとなります。

続いて仮想マシンのIDですが、こちらはNSXのAPIから取得することはできません。

こちらは、PowerCLIで取得します。
今回は、「CL-WIN81-2」という仮想マシンにタグをつけたいと思います。

PowerCLIのインストールは、 こちらに簡単ですが紹介しております
(参考)
http://infratraining.blogspot.jp/2015/06/blog-post.html

PowertCLIをインストールし、起動後、まずはvCenterにまずは、接続します。
Connect-VIServer -Server 「vCSのIP」 -User 「vCSのアカウント」 -Password vCSのパスワード

次に、仮想マシンの情報を取得します。
get-vmguest 仮想マシン名(今回はCL-WIN81-2) | select *


出てきた仮想マシンの詳細情報で「VmId」という項目があります。
ここの「VirtualMachine-vm-61」の「vm-61」がIDとなりますのでこれを控えておきます。

これで準備はできました。

まずは、控えた情報を整理しておきましょう。


付与するセキュリティタグ名称ANTI_VIRUS.VirusFound.threat=low
付与するセキュリティタグIDsecuritytag-2
付与される仮想マシン名CL-WIN81-1
付与される仮想マシンIDvm-61

NSX APIガイドの112ページを確認してみましょう。


「Apply Tag to Virtual Machine」の項が、仮想マシンにセキュリティタグを付与する為のAPIコール用のURLが記載されています。


APIは、
https://NSXManagerのIP/api/2.0/services/securitytags/tag/TagのID/vm/VMのID
のURLでコールします。

今回は上記で控えた情報を元に
https://NSXManagerのIP/api/2.0/services/securitytags/tag/securitytag-2/vm/vm-61
というURLが、APIをコールするためのURLになります。

では、早速Postmanに入れてみましょう。

メソッドが前回は「GET」でしたが、タグを付与する場合は「PUT」になりますので、注意してください。
必要なパラメーターを入力後、Sendをクリックしてみましょう。


今度は、セキュリティグ情報を取得したときのようにXMLの情報は帰ってきませんが、STATUSが200になっていれば、メソッドは成功しています。
XMLのデーターが出てきている場合は、ステータスコードが200以外で何らかのエラー内容がXMLで出力されていると思います。

では、これでvSphere Web Clientの画面から、仮想マシンにタグが付与されたかを見てみたいと思います。

きちんと、「ANTI_VIRUS.VirusFound.threat=low」のところに、仮想マシンが「1」と表示されています。

仮想マシン数の「1」 をクリックすると今回、タグを付与した「CL-WIN81-1」が存在していることが確認できます。



わずかこれだけで、仮想マシンのセキュリティタグ付与ができました。

今回は、Chromeのアプリケーションを利用しましたが、REST APIは、URLベースで簡単にやり取りをすることができるため非常に簡単です。
既存の資産管理アプリケーションやウイルス対策ソフトウェアと連携することで、簡単に既存のソフトウェアがNSXのセキュリティタグ連携ができるようになるのは、大変魅力的だと思います。

NSXのセキュリティは、高価なソリューションとの連携も魅力的ですが、お手製ツールでも簡単に高度なセキュリティを得ることができます。




NSXのセキュリティタグをAPIで活用してみよう(その2)

前回は、PostmanのRESTアプリをインストールしました。
実際に、REST APIをコールするためには、まずAPIのドキュメントが必要です。

NSXのドキュメントページ(https://www.vmware.com/support/pubs/nsx_pubs.html)から、APIガイドをあらかじめダウンロードしておきましょう。

参考(APIガイド)
http://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_api.pdf


では、基本設定を行い、まずはNSXのセキュリティタグ一覧を取得してみましょう。

重要な基本設定は、NSX Managerに認証情報を渡すことです。
(でないと、だれでもAPIをコールされると困るので)

NSX RestAPIは、Basic認証でユーザー認証を行います。
まず、Postmanの画面で「Basic Auth」のタブをクリックし、UserNameとPasswordを入力し、「Refresh headers」をクリックします。


その後、Normalタブを選択し、URLに、
「https://"NSX-Manager-IP-Address"/api/2.0/services/securitytags/tag」
を入力します。
NSX-Manager-IP-Addressは、NSX ManagerのIPアドレスを入力します。

このURLは、先ほどダウンロードしたAPIガイドの112ページに掲載されています。

あとは、メソッドを「GET」にして、「SEND」をクリックします。


うまくいくと、ステータス200で、XMLの結果が帰ってきます。

この場合ですと、「VULNERABILITY_MGMT.VulnerabilityFound.threat=high」と「ANTI_VIRUS.VirusFound.threat=low」が見えていますが、実際にvSphere Web ClientからNSXのタグ一覧を見てみましょう。


XMLを読んでいただくとわかりますが、NSX Managerで保有しているすべてのセキュリティタグ情報が出力されているのがわかります。

では、実際にセキュリティタグを付与するアクションを次回に紹介したいと思います。