NSX ではマルチテナント機能が搭載され、NSX VPC というマルチテナント機能の応用的な機能も追加されて、より柔軟でセルフサービスが可能なクラウドとして利用できるようになりました。また、この NSX マルチテナントや NSX VPC は、NSX Advanced Load Balancer ( NSX ALB )  とも連携ができるようになり、NSX のテナントネットワークと NSX ALB のテナント機能が連動するようになりました。

このように、テナントの仮想ネットワークと NSX ALB のロードバランサが連携できることで、テナント単位でネットワーク・セキュリティ・ロードバランサを独立して管理ができるようになっています。テナントのユーザは、クラウド基盤は他のテナントと共有しつつ、ネットワークやロードバランサは独立して管理ができるセルフサービスができるようになります。

NSX マルチテナント・NSX VPC は、NSX ALB とも連携ができることで、NSX テナントと同じテナント名が NSX ALB のテナントとして自動生成されます。（ 連携詳細はこちらのブログをご参照ください）
こうした連動やテナント管理をする上で、NSX テナントユーザと NSX ALB テナントアカウントを LDAP で一元管理ができると効率的です。

このブログでは、以下のイメージのような NSX マルチテナントと NSX ALB のマルチテナントの環境に対して、LDAP ユーザを使って同じアカウントで両方にログインできるテナントアカウントの動作確認を例にとり、動作を解説していきたいと思います。

LDAP による NSX ユーザ管理

まずは、NSX の LDAP 設定を行い、NSX UI に LDAP ユーザでログインできるようにします。今回は Microsoft Windows Server Active Directory を LDAP サーバとします。

以下のように、[システム] > [ユーザー管理] > [LDAP] に移動し、[ID ソースの追加] をクリックし、Active Directory を使用している場合は、[ドメイン名] を入力（Active Directory サーバのドメイン名）し、タイプとして、[LDAP 経由の Active Directory] を選択します。

Active Directory ドメインを追加するには、基本識別名（基本 DN )）が必要で、ドメイン名が corp.local の場合、Active Directory のベース DN の DN は DC=corp,DC=local とします。この設定により、NSX ユーザーは、[user_name@domain_name] のようにログイン名の後に @ および LDAP サーバのドメイン名を使用してログインできるようになります。

次に、NSX テナントに利用する LDAP ユーザを、テナントや VPC に登録していきます。以下のように、[プロジェクトの管理] に移動し、[プロジェクトを追加] をクリックし、プロジェクトの作成とユーザの追加を行います。[ユーザ]をクリックし、このテナントや VPC の管理者を割り当てるため、LDAP ユーザを登録していきます。

詳細手順は、こちらの管理ガイドをご参照ください。

以下のように、テナント管理者として「Project Admin」ロールを割り当てたり、VPC管理者として 「VPC Admin」ロールを割り当てることができます。

これで、テナントや VPC に向けた LDAP ユーザを作成することができました。Project Admin」、「VPC Admin」、それぞれのユーザで NSX にログインして、UI の表示内容の違いを見てみましょう。

上記動画のように、ロールに応じたUIの表示が切り替わっていることがわかります。

LDAP による NSX ALB ユーザ管理

では次に、NSX ALB に LDAP 設定を行い、NSX ALB UI に LDAP ユーザでログインできるようにします。[テンプレート] > [セキュリティ] > [認証プロファイル] に移動し、[作成] をクリックし、以下の各種設定項の入力を行います。以下はあくまで設定例になりますので、LDAP の構成に応じて設定内容を適切にご選択ください。

次に、LDAP ユーザ（ AD セキュリティグループ）とテナントのマッピングを行います。（例：Blue組織ユーザはBlueテナントの管理）

[テンプレート] > [セキュリティ] > [認証マッピングプロファイル] に移動し、[作成] をクリックし、以下の各種設定項の入力を行います。こちらも以下はあくまで設定例になりますので、LDAP の構成に応じて設定内容を適切にご選択ください。今のように、マッチ条件とアクションを設定します。

マッチ条件

以下の場合は、AD セキュリティグループ（project-blue）のマッチルールとなっており、[LDAPグループ一致] を任意とし、[属性名] には「memberOf」、 [属性値]には「CN=project-blue,CN=Users,DC=corp,DC=local」を用いて設定しています。または、LDAP サーバの構成によっては、マッチルールは [LDAPグループ一致] を「メンバー」とし、[グループ] に AD セキュリティグループ「project-blue」と入力し、[属性一致] は「任意」とする設定で構成することもあります。

アクション

上記のマッチ条件で指定したセキュリティグループに応じたテナントを指定と、ユーザロールを指定します。以下では、project-blue のテナントを指定し、Tenant-Admin の権限としています。

上記のルールを、テナント数だけルールで定義することで、Project-blue や Project-red と複数テナントのユーザ紐付けを行うことができます。

最後に、認証プロファイルとマッピング プロファイル を用いて、NSX ALB UI に LDAP ユーザでログインできるようにします。[管理] > [システム設定] > [編集] に移動し、以下のように[認証] を「リモート」とし、上記で作成した認証プロファイルとマッピング プロファイルをご選択ください。

これで、テナントに向けた LDAP ユーザを作成することができました。それぞれのテナント管理者のユーザ ID で NSX ALB にログインして、UI の表示内容の違いを見てみましょう。

上記動画のように、ロールに応じた UI の表示が切り替わっていることがわかります。特に、Project Red の LDAP ユーザがダイナミックに生成され、NSX ALB の管理 UI にLDAP ユーザが自動生成されているところも確認できます。このように、LDAP ユーザにユーザ管理を一元化させることができていることが確認できました。

まとめ

今回は、NSX マルチテナントや NSX VPC が NSX ALB とも連携ができ、管理者のセルフサービス化が非常に強化されたことをうけて、管理者の ID 管理に焦点を当てた Tips をご紹介しました。
管理者の ID 管理を一元することで、テナント管理者はクラウド基盤を他のテナントと共有しつつも、ネットワークやロードバランサは独立して管理ができるセルフサービスができるようになります。
管理者の ID 管理が別々となれば、いくらマルチテナントなUIや管理方法があったとしても、ネットワーク、セキュリティ、ロードバランサの一気通貫したシームレスなインフラ管理になるとは言えません。
こうした ID 管理を基準として、インフラのオブジェクトレベルまでテナント分離がなされ、安心してテナントのインフラ設定管理ができることは権限管理やプロジェクト管理にとって非常に重要な要素となります。
ぜひ、これからのマルチテナントなクラウドインフラを検討する際には、こうしたテナント単位の ID 管理の一元化も一つ考慮ポイントとしていただけたらと思います。
これからの皆様のプライベートクラウドのヒントになれば幸いです。