NutanixのSSP（Self Service Portal）再入門（その1）

本記事は、Nutanix Advent Calendar 2018，2枚目の4日目、12月4日分としての投稿になります。
https://adventar.org/calendars/3174

本記事の内容は、この日付時点の情報（AOS 5.10/Prism Central 5.10）に基づいています。そのため，今後新しいバージョンが提供された場合に，当該記載と矛盾が生じる場合がありますのでご注意ください。

はじめに

この記事ではNutanixをシステム管理者以外のユーザーとして利用する際に利用可能なセルフサービスの機能であるSSPについて、改めて紹介します。
実は、本記事を投稿するにあたり、再入門と題したのには理由があります。それは、Nutanix Advent Calendar 2016、12月25日分の投稿として、ヤギの（中の？）人でお馴染みの @smzksts さんの投稿「CloudStackerから見た、NutanixのSelf-Service Portalについて」 でSSPの特徴やプライベートクラウド基盤ソフトウェアとの比較を行った点などについて既に解説されています。
この投稿から約2弱年が経過しようとしていることもあり、改めてSSPに入門しなおそうと言うことで、こちらの記事を投稿します。

SSPの概要

SSPはNutanixのSelf Service Portal機能の略称です。この機能はユーザーに対してVMの作成や削除、アプリケーションのデプロイや削除と言った権限の委譲を行うことで、システム管理者権限を用いずに、VMやアプリケーションのライフサイクル管理を行うことが可能な機能です。
堅苦しい言い方を避けてざっくりとした紹介をするのならば、ユーザー権限でVMの作成や利用、運用が可能なサービスです。

SSPの成り立ち

本来的にNutanixの管理コンソールであるPrismは、仮想化基盤を中心としたITインフラのシステム管理者のためのものです。そのためPrismでは、Nutanixを構成し、Nutanixによって構成される以下のような要素をすべてコントロール可能です。

・Nutanixを構成するハードウェア（Disk、ノード、IPMI）に対する操作
・Nutanixを構成するハイパーバイザーに対するあらゆる操作
・Nutanixを構成するAOS（CVM）に対するあらゆる操作
・Nutanixによって構成されるVMやアプリケーションに対するあらゆる操作
・Nutanixにおけるヘルス、パフォーマンス、アラート、イベントの管理
・などなど

仮に（贅沢にも！）1人でNutanixを利用する場合には、どんな操作を行ってたとしても自己責任で、おおよそ他の人に迷惑をかけることはありませんが、複数のユーザーやグループで共有して利用している場合、数百人、数千人が利用している環境であった場合には、このシステム管理者向けの管理コンソールにおける不用意な操作は、大きな問題を生じさせる恐れがあります。

しかし、多数のユーザーが共有して利用する仮想化基盤において、VMやアプリケーションの作成や削除が日常的に生じるようなユースケース、また仮想化基盤の管理者が常に配置できない場合などには、都度、VMやアプリケーションの作成や設定変更等の操作をシステム管理者に依頼して運用することは現実的ではないケースもあります。

そのため、仮想化基盤を使ってVMやアプリケーションを運用していく上で認証されたユーザーに対して認可された操作のみを許可した形のPrismを提供することで、ユーザーに対する利便性とITインフラの安定運用の両方を提供可能にするSSPが登場しました。

SSPの立ち位置

このような生い立ちを持つSSPは、パブリッククラウドサービスようなIaaSを模しつつ、主にオンプレミスを中心に利用するための機能を踏まえ、それらから、必要十分な機能のみに絞ったオンプレミス向けのIaaSを提供しています。

SSPは、主にオンプレミスで運用するNutanix上におけるユースケースを中心にしたIaaSを提供する利用形態を想定していることから、ユーザーに対する権限委譲対象の中心となるのはVMまたはVMとその上に展開するアプリケーションを中心としたものとなります。

SSPの概要のまとめ

• SSPはユーザーのための機能限定されたPrismを提供
• SSPはオンプレミスのNutanixにおけるIaaS
• SSPで操作可能な対象はVMとその上に展開するアプリケーション

SSPを使い始める

ここでSSPを利用する上で、把握しておくべき重要なポイントがあります。Prismをシステム管理者が主体となって運用する場合とセルフサービスでユーザーが主体となって利用する場合との、根本的な考え方の違いのポイントは、SSPはIaaS的なサービス提供形態をとっている点です。

SSPでユーザーがセルフサービス的に操作を行う対象は、これまで何度もキーワードとして登場している「VMとその上に展開するアプリケーション」であり、SSPでは、それをIaaS的に提供するものです。

そのため、SSPはVMの展開方法ひとつとっても根本的な考え方が異なることや、それに伴う通常の手順とは大きく異なるフローでVMやアプリケーションの展開が行われる形になります。

例えばパブリッククラウドにおいて「クラウドネイティブ」的な考え方に基づいてアプリケーションやサービス提供する場合、ISOをVMにマウントしてインストールしたり、同一のVMをずっと永続的に使い続けるような使い方をしません。スケールアウト・スケールインを繰り返すようなシステムではVMは使い捨てのリソースになります。

そのため、スケール対応し素早くVMをデプロイ可能なように、ディスクイメージやスナップショットイメージをベースとしたテンプレートやコレクションからVMを選択し利用する、又は既にアプリケーションのがインストール済みのVMをマーケットプレイスから選択して利用したりします。

一方で、オンプレミスの製品ではどちらかと言うとVMを永続的に利用する傾向があるため、NutanixのSSPでは少しオンプレミス寄りなインフラストラクチャ利用を想定した操作や運用を前提としています。

このようなバックグラウンドを理解することで、システム管理者が主体となって運用する場合との差異に戸惑うことなく、SSPの利用や運用にスムースに入っていけます。ここでは、そういった考慮点を踏まえSSPの利用を開始する上で把握しておくべきSSPの全体像やSSPを構成するコンポーネント、SSPを実際に利用する上で必要な設定等について見ていきます。

SSPの全体像

まず、SSPの全体像です。基本的にSSPはセルフサービスのIaaS的なサービスとなります。そのため、ユーザーが権限で可能なことはVMの作成、削除、更新、参照（利用）のみとなります。以下のように、Admin（システム管理者）は、Projectの作成、カタログの作成・準備、Projectごとのクォータの設定、クラスターの管理、ロールの設定、そしてVMの詳細な管理が可能です。一方で、SSPのユーザーはVMの管理のみが可能となっています。

システム管理者が可能なこと

• Projectの作成
• カタログの作成・準備
• Projectごとのクォータの設定
• クラスターの管理
• ロールの設定
• VMの詳細な管理

SSPユーザーが可能なこと

• SSPのユーザーのVMの管理

システム管理者とSSPユーザーのロール

おおまかな概要は上記のとおりですが、ロール別に見ていくと以下のような形なります。パブリッククラウドなどのIAMのRBACほど粒度は細かくありませんが、VMと言うリソースに対する操作に対する認可がロールごとに定められており、そのロールをSSPを利用するユーザーに割り当てることで、操作権限を制御しています。

主にオンプレミスでの利用を想定してIAMのような膨大な数のロールを設定せず、もう少し粒度の大きな単位での利用を可能とすることで、非常に簡単にセルフサービス用途の権限設定を可能とし、オンプレミスのプライベートクラウドのような基盤で利用しやすいようになっています。

SSPを構成するコンポーネント

前述のとおり、SSPがターゲットとするものは「VMとその上に展開するアプリケーション」です。そのためシステム管理者が主体となって運用する際に必要となる機能とSSPで利用する際に利用する機能には大きな差分が生じます。
ここでは、その差分を理解すべく、SSPが利用する主なコンポーネントや機能について紹介していきます。

SSPの基盤

SSPの基盤はAOS 5.5/Prism Central 5.5までCVMに内包されPrism Elementからの操作をベースとしていました。しかしAOS 5.5/Prism Central 5.5以降、Prism Centralの一機能として実装され、操作をPrism Centralから行うようになっています（あくまでコントロールプレーンがPrism Centralに実装されているのみで、データプレーンとしてVMのリソースはそのままNutanixの基盤上に展開されます）。

そのため現在のAOS 5.5/Prism Central 5.5以降、最新バージョンまでSSPを利用するためにはPrism Centralが必要となります。

認証制御コンポーネント

セルフサービスを提供するに当たっては、セルフサービスを利用するユーザーが、これらリソースにアクセスすることを許可された本人であるかを適切に判断する必要があります。そのためにActive DirectoryやOpenLDAPと言ったディレクトリサービスを通じて本人認証行うための仕組みが必要となります。

認可制御コンポーネント

セルフサービスを提供するに当たっては、セルフサービスを利用するユーザーごとに利用可能なリソースを定義する必要があり、パブリッククラウド等ではIAMなどのサービスでそれらを制御していますが、NutanixのSSPでは、それらIAMと比較すると、もう少し粒度の荒いRBACを利用して、これを定義します。

SSPユーザーが利用可能なオブジェクト

SSPが利用可能なオブジェクトは、SSPにログイン処理をするためのオブジェクトであるSSPのログイン画面、VMのCRUDのためのオブジェクトであるVMの操作画面とそれに付随する機能、アプリケーションを展開するためのオブジェクトであるCalmとそれに付随する機能です。
逆説的な言い方をするのであれば、上記に含まれないリソースやオブジェクトには一切アクセスできない形になっています。

事前準備

パブリッククラウドの事業者が、IaaSユーザーのために、データセンターを準備し、低レイヤーのハードウェア、スイッチ、ストレージ装置を接続、配置し、ソフトウェア的にそれらを動的に切り出し提供可能な状態を準備しているのと同様に、SSPは予めNutanixシステム管理者がセルフサービス的にNutanixの仮想化基盤を利用したいと考えているユーザーに対するインフラ面の環境を準備し提供する必要があります。
ここでは、SSPを利用するに当たって必要となる事前の準備・設定について見ていきます。

ディレクトリサービスの設定

前述のSSPを構成するコンポーネントでも紹介したとおり、SSPの認証制御をするためのディレクトリサービスを設定する必要があります。NutanixのSSPでは、ディレクトリサービスとしてActive Directory又はOpenLDAPの利用が可能です。

SSP管理者の設定

SSPの管理者をディレクトリサービスに登録されているユーザーまたはグループから選択又は追加し選択します。
SSP管理者は、SSPの利用に必要な準備を行うための権限のみを有しており、SSPユーザー以上、admin未満の権限を与えられています。SSP管理者（Prism表示上ではSSP Admin）は、クラスターやCVM、ハイパーバイザー等のリソースに対するアクセス権は持っていませんが、すべてのプロジェクトに対する操作権を有しています。

SSPユーザーの設定

SSP利用ユーザーをディレクトリサービスに追加し選択します。既にSSPで利用するユーザー又はグループがディレクトリサービスに存在する場合には不要です。

これらの作業の際に、1つ考慮すべき点として、NutanixのSSPに限らず、このようなセルフサービスを利用するに当たって、このディレクトリサービスへのユーザーの追加及びグルーピングは、SSPのリソース利用の単位であるプロジェクト（或いは簡易なテナント）を構成する上で重要な考慮ポイントとなります。

例えば、ディレクトリサービスを利用したアクセス制御等を行うに当たってよく利用されるファイルサーバーへのアクセス権設定を例にとってユーザーの追加及びグルーピングの方法論を考えてみます。ファイルサーバーリソースに対するアクセスを許可を設定する場合、一人一人のユーザーに対して個別に許可を設定していると大量ユーザーを制御するのにとてつもない時間を要します。

そのため一般的には一定の役割や所属する組織、部署ごとにグルーピングを行い、そのグループごとにファイルサーバーへのアクセス制御を行ったり、ユーザーに対する属性情報を付与し、属性情報ごとにファイルサーバーへのアクセス制御を行うケースが多いかと思われます。これらのアクセス制御には、それぞれの組織構造やファイルサーバーのディレクトリ構成ポリシーなどによって千差万別だと思われますが、SSPについても同様の考慮が必要となります。

どのような粒度でプロジェクトを管理したいか、どのようなユーザーやグループの単位でRBACを設定したいか、これはディレクトリサービスにおけるOUやGroup、Userを設定する際の考慮ポイントとなり、或いはその逆の判断基準として、既存のディレクトリサービスにおけるOUやGroup、Userの単位を見ながら、どのようにプロジェクトを構成するか、RBACを設定するかを検討するケースもあります。

そのため、場合によっては、SSPの利用に際して新たなOUやGroupを構成したりする必要も生じること留意する必要があります。

プロジェクトに所属するSSPユーザーのためRBACの確認又は設定

ユーザーごとにどのようなリソースにアクセス可能か、どのような操作が可能かを確認又は設定します。SSPには、ビルトインのロールが設定されており、SSPで利用可能なビルトインのロールはSSP全体の管理者であるSSP Adminのほか、SSPの一般ユーザーロールとして、Operator、Consumer、Developer、Project Adminが定義されています。

このビルトインのロールは、Operator、Consumer、Developer、Project Adminの順番で権限が強くなっています。また、ユーザー定義のロールを設定することが可能で、Operator以下の権限（例えばVMのコンソールのみアクセスが可能）やDeveloper以上の権限を設定したロールを定義しておき、それをプロジェクトに所属するユーザーに割り当てて利用することも可能です。

プロジェクトの作成とユーザーの設定及び利用可能なネットワークリソースの設定

プロジェクトの作成は、システム管理者又はSSP Adminが行います。これはプロジェクトという箱を用意し、そこに所属するユーザーを設定します
プロジェクトに所属するユーザーは、あらかじめシステム管理者やSSP Adminが追加・設定する方法や、作成したプロジェクトの管理者であるProject Adminだけを作成しておき、後からProject Adminが、プロジェクトの所属を必要とするユーザーを追加することも可能です。

また、ここで利用可能なネットワークリソースの設定も行いますが、この設定は、SSPがパブリッククラウドのIaaSと大きく異なる点の1つとして挙げられます。多くのパブリッククラウドのIaaSでは、動的に必要なネットワークリソースをオンデマンドで構成することが可能ですが、SSPでは、予めシステム管理者が定義したVLANの中から、作成したプロジェクトに対して利用可否の有無を設定する形となります。

これはNutanixのネットワークリソースの利用が、パブリッククラウドのIaaSと異なり外部のスイッチの設定に依存することに起因します。そのため、どちらかと言うと、このネットワークリソースの設定についてはベーシックなOpenStackを利用するケースに近しいと言えます。

プロジェクトのクォータの設定

SSPは、1つのNutanixクラスターのリソースを複数のプロジェクトやプロジェクトに一切所属しないVM等と共有することになります。そのため、必要に応じてプロジェクトごとに利用可能なCPU、メモリ、ストレージリソースに対するクォータを設定することが可能です。
なお、SSPにおけるリソースクォータはハードリミットで、設定されたクォータを越えることはできず、例えばVMの作成や起動時にクォータ越えると分かった時点で作成や起動が中止されます。

カタログの準備

システム管理者でログインしてVMを作成して利用する場合と異なり、SSPでは大前提としてディスクのイメージやVMのテンプレートのコレクションであるカタログを利用してのみSSPユーザーはVMの作成が可能です。カタログは、AWSで言うところのAMIに相当し、こちらに登録されたイメージを利用してVMをデプロイします。

カタログに登録可能なリソースは以下の3つの形態です。

• VMテンプレート
• ディスクイメージ
• ISOイメージ

ここでパブリッククラウド等と異なるSSPの特徴として挙げられるのは、カタログにディスクのイメージやVMのテンプレートだけではなくISOファイルを登録できることです。
前述のとおり、SSPはパブリッククラウドのIaaSの考え方をバックグラウンドに持っていますが、ベースはオンプレミス又はプライベートクラウドでのユースケースを主なユースケースとして想定しています。またパブリッククラウド等と異なり急激なスケールアウトやスケールインをしないVMも多数存在するケースやISOファイルなどを通じて、一からVMを構成して利用したいニーズもあります。
そのため「オンプレミスらしい」選択肢としてカタログにISOを登録可能とすることで、SSPユーザーはカタログからISOを選択することで、一からVMを自分好みに作成することも可能です。

SSPを使い始めるのまとめ

• SSPはVMを中心としたリソースをセルフサービスで利用するもの
• SSPのプロジェクトは簡易なテナントに相当
• SSPを利用するには予めシステム管理者かSSP管理者による設定が必要
• SSPユーザーがVMを作成するにはカタログを経由する必要がある

POST SCRIPT

NutanixのSSP（Self Service Portal）再入門（その1）、いかがでしたでしょうか、SSPは運用フェーズにおけるNutanixの利用形態の1つです。Nutanixを導入することで、従来のサーバー・ストレージエリアネットワーク・ストレージの管理というインフラレイヤー運用・管理の悩みから解放されたら、次はインフラの上で運用するVMの運用・管理の負担やコストの悩みをお持ちのようでしたら、それらを解決するためのネクストステップの選択肢の一つとしてSSPの利用を検討してみてはいかがでしょうか。
その2では、実際にSSPユーザーでログインした場合のPrismの見え方やVMの作成等のSSP利用フェーズやSSPではできないこと等について紹介したいと思います。

明日は、Yoshihito Kashimaさんです。