Keystone 認証

NSX Advanced Load Balancer は、コントローラへのユーザー認証に OpenStack の Keystone サービスを使用できます。NSX Advanced Load Balancer は Keystone v3 をサポートします。

Keystone を使用して、NSX Advanced Load Balancer にログインするユーザーを認証することは、構成可能なオプションです。これは、NSX Advanced Load Balancer で OpenStack クラウドを構成するときに、use_keystone_auth フラグによって制御されます。このフラグを無効にして、OpenStack クラウドを構成できます。このような場合は、NSX Advanced Load Balancer で構成されたユーザーのみがログインできます。また、ユーザーのテナントとロールは Keystone からインポートできないため、NSX Advanced Load Balancer 管理者がローカルに作成する必要があります。

Keystone を認証に使用する場合、NSX Advanced Load Balancer は Keystone の 1 つのインスタンスでのみ使用できます。その他のリモート認証メカニズムは使用できません。したがって、認証に Keystone を使用する場合は、単一の NSX Advanced Load Balancer システムに 1 つの OpenStack クラウドのみを構成できます。admin などの NSX Advanced Load Balancer 内部システムアカウントは、ローカルで認証されていることを示す内部ローカルフラグを維持します。

次のフローチャートに示すように、ユーザーがログインすると、NSX Advanced Load Balancer は最初に Keystone に対して認証され、Keystone 認証が失敗した場合にのみ、ローカルユーザーデータベースを確認します。新しいローカルユーザーは作成しないことをお勧めします。これらの名前は Keystone でも使用され、混乱を引き起こす可能性があるためです。

Keystone からのテナントとロールの情報は、ユーザーがログインしたときにのみインポートされます。そのため、ユーザーがログインすると、そのユーザーの Keystone に追加された新しいテナントと新しいロールは、NSX Advanced Load Balancer に即時には反映されません。ユーザーが次回コントローラにログインしたときにインポートされます。

Keystone からインポートされたテナントのリスト

NSX Advanced Load Balancer は、OpenStack クラウドで構成されたユーザーがアクセスできるテナントにのみ Keystone からインポートされます。ここでは、NSX Advanced Load Balancer OpenStack クラウドで構成されたユーザーが Keystone のテナント p1、p2、および p3 のみにアクセスできるとします。別のユーザーが NSX Advanced Load Balancer にログインし、テナント p1、p3、および p6 にアクセスできる場合、NSX Advanced Load Balancer は、これら 2 つのリストの交差にあるテナント（p1 と p3）に関する情報のみをインポートします。

NSX Advanced Load Balancer OpenStack クラウドで構成されたユーザーが Keystone に対する管理者権限を持っていても、NSX Advanced Load Balancer が Keystone の admin_url にアクセスできない場合は、構成されたユーザーが明示的なロールを持つ Keystone にのみテナントをインポートできます。この場合、OpenStack 管理者は、NSX Advanced Load Balancer が LBaaS サービスを提供する必要がある各テナントにおいて、構成されたユーザーが管理者ロールを持っていることを確認する必要があります。

Keystone v3.0 と複数のドメインが使用されている場合、NSX Advanced Load Balancer OpenStack クラウドで構成されたユーザーは、構成されたユーザーのドメイン以外のドメイン内のプロジェクトで LBaaS サービスを提供できるようにするために、これらのプロジェクトでロールを必要とします。

OpenStack ダッシュボード (Horizon) では、ドメイン間でのロールの割り当てをサポートしていません。これを実現するには、OpenStack CLI を使用することをお勧めします。

openstack role add --user <USERID> --project <PROJECTID> <ROLE-NAME>

Keystone V3 の使用中、openstack-cleanup API は、OpenStack からインポートされた古いユーザーとテナントを無条件でクリーンアップします。

NSX Advanced Load Balancer と Keystone との統合

認証のために、Keystone v2.0 には、users、projects（tenants とも呼ばれる）、および roles という概念があります。ユーザーは、1 つ以上のプロジェクトで 1 つ以上のロールを持つことができます。OpenStack の他のサービスには、各ロールの権限を定義するための独自のポリシーがあります。

Keystone v3.0 には、domains の追加の概念が導入されています。ドメインは、Keystone エンティティ（user および project）の管理のための境界を定義します。したがって、user または project は 1 つのドメインにのみ属します。各ドメインは一意の名前を持ちます。ただし、同じユーザー名（demo など）は複数のドメインに存在できます。Keystone v2.0 API と互換性を持つ v3.0 では、Default という名前のデフォルトドメインが作成されます。Keystone v2.0 API でアクセス可能なすべての users および projects はこのデフォルトドメインに配置されます。

Keystone には、groups の概念も導入されています。group は、単一の domain 内の users のコレクションで、domain によって所有されます。group は、プロジェクト内の role に割り当てられ、そうすることで、そのプロジェクト内のロールをそのグループの /all/ users に効果的に割り当てることができます。Keystone v2.0 パブリック API と Keystone v3.0 のエンドポイントの形式は、http://keystone:5000/v2.0 と http://keystone:5000/v3 です。

NSX Advanced Load Balancer での Keystone 認証

OpenStack 統合のクラウド構成には、auth_url フィールドが含まれています。Keystone ホストの名前または IP アドレスを指定するために以前のバージョンで使用されていたフィールド keystone_host は廃止されました。NSX Advanced Load Balancer は、auth_url フィールドを解析して、構成された Keystone サービスとの通信時に使用する API バージョンを決定します。サフィックスが「v3」で終わる場合は、v3.0 API が使用されます。それ以外の場合は、v2.0 API が使用されます。

現在、NSX Advanced Load Balancer 認証モデルには domain エンティティがありません。ただし、ドメイン testdomain の Keystone ユーザー test は、NSX Advanced Load Balancer の test@testdomain という名前のユーザーにマッピングされます。同様に、testdomain の Keystone プロジェクト testproject は、NSX Advanced Load Balancer に testproject@testdomain という名前を持つテナントとしてマッピングされます。唯一の例外は、Keystone 上の Default ドメインです。これは、特殊な UUID default: を持ちます。NSX Advanced Load Balancer は、そのドメインからの Keystone からインポートされたユーザーとテナントの @Default をドロップします。他のドメインのユーザーの場合、NSX Advanced Load Balancer にログインするとき、またはそのユーザーを使用して OpenStack クラウドを NSX Advanced Load Balancer で構成するときに、常に @domain サフィックスを明示的に使用します。

したがって、Keystone のドメイン testdomain のユーザー test は、次のようにコントローラにログインできます。

@domain が指定されていない場合、コントローラは、そのユーザーが構成された Keystone v3.0 サービスの Default ドメインに属していると見なします。

Keystone のドメイン testdomain のユーザー testdomain が、ドメイン Default およびドメイン testdomain の test プロジェクトの admin プロジェクトにアクセスできるとします。そのユーザーがコントローラにログインすると、次の 2 つの NSX Advanced Load Balancer テナントにアクセスできるようになります。

役割のインポート

NSX Advanced Load Balancer を使用すると、管理者はクラウドリソース API を介して明示的なマッピングを構成できます。openstack_configuration のパラメータ role_mapping は、OpenStack Keystone からのユーザーのロールを NSX Advanced Load Balancer Controller のロールにマッピングする方法を定義します。role_mapping パラメータの構成例を次に示します。

"openstack_configuration": {
   ....
   "role_mapping": [
      {"os_role": "admin", "avi_role": "Tenant-Admin"},
      {"os_role": "_member_", "avi_role": "Tenant-Admin"},
      {"os_role": "*", "avi_role": "Application-Operator"}
   ],
}

role_mapping パラメータは順序付きリストであり、このリスト内の各項目は、Keystone ロール (os_role) が NSX Advanced Load Balancer Controller 内のロール (avi_role) にマッピングする方法を指定します。os_role フィールドに「/」ワイルドカードを指定することにより、任意の Keystone ロールのデフォルトのマッピングを定義できます。上記の例では、Keystone からのロール admin と _member_ は、NSX Advanced Load Balancer Controller のロール *Tenant-Admin にマッピングされています。また、Keystone からのその他のロールは、NSX Advanced Load Balancer ロール Application-Operator にマッピングされています。

次の例では、ロール lbaas_project_admin を持つユーザーのみがコントローラにアクセスでき、そのロールを持たない Keystone ユーザーはログインを拒否されます。

"openstack_configuration": {
   ....
   "role_mapping": [
      {"os_role": "lbaas_project_admin", "avi_role": "Tenant-Admin"},
   ],
   ....
}

@avilocal ユーザーの Keystone 認証のスキップ

Keystone 認証が有効になると、デフォルトで、NSX Advanced Load Balancer にログインするすべてのユーザーが Keystone に対して最初に認証されます。これが失敗した場合、ユーザーはローカルに保存された認証情報に対して認証されます。これは、non-Keystone Avi-local ユーザーがログインするたびに、Keystone 認証の試行に失敗し、Keystone ログに監査メッセージが記録される可能性があることを意味します。

サフィックスとして @avilocal を持つユーザー名は、NSX Advanced Load Balancer のローカルに保存された認証情報に対してのみ認証されます。このようなユーザーは Keystone に対して認証されません。これにより、追加の Keystone 認証の試行が回避されるため、Keystone 監査メッセージはトリガされません。