ECE 2.3でロールベースのアクセス制御と外部認証の一般提供を開始

By
Rory Hunter

Elastic Cloud Enterprise（ECE）2.3のリリースに伴い、ロールベースのアクセス制御と外部ソースによる認証が一般利用できるようになりました。これらの機能により、ECEプラットフォームへのユーザーアクセスをロールによって制御できるようになります。ユーザーをECEにネイティブに追加できるようになるとともに、自社のディレクトリサーバーまたはアイデンティティプロバイダーに接続して、既存のユーザーにアクセス権を付与できます。

これらの機能のサポートはECE 2.2のベータ版で最初に追加されました。そして、2.3ではバグを解決するとともに、既存のLDAPおよびSAMLオプションに加えてActive Directoryのサポートが追加されています。

その仕組み

ECEにRBACを追加することでセキュリティデプロイメントが追加されます。これは、認証設定およびパーミッションのすべてを管理するシステムがデプロイされることを意味します。ユーザーがログインを試行すると、ECEはこのセキュリティデプロイメントを使用して認証を行い、必要な場合はシステムユーザーにフォールバックします。ユーザーが認証されると、ECEはそのユーザーに割り当てられるロールを適用します。そして、それらのロールはきめ細かなパーミッションに変換され、各ユーザーが表示可能なデータや実行可能なアクションが制御されます。

注意が必要なのは、ECEでのユーザーのロールは、ECEでホストされているデプロイメントに関してユーザーが保有している認証情報とは関係がないということです。つまり、ECEへのアクセス権がなくても、ホストされているデプロイメントには管理者アクセス権がある、またはその逆といったユーザーがいるということです。

利用可能なロール

ECEは、プラットフォームおよびデプロイメントレベルの両方でいろいろな操作を可能にします。ロールの定義と維持に関する管理者の作業を削減するために、ECEでは、ほとんどの一般的なユースケースを網羅する事前定義されたロールが提供されます。これらのロールは、今後提供される機能の増加に合わせて継続的に更新されるため、独自の定義を最新に保つことを心配する必要はありません。

下記に各ロールを説明します。ユーザーは2つ以上のロールを保持することができ、必要に応じてそれらを組み合わせることができます。たとえば、「プラットフォーム管理者（Platform admin）」は何でもできるため、他のロールを付与する必要はありません。ただし、「プラットフォーム閲覧者（Platform viewer）」は何でも閲覧することはできますが、何も変更することはできないため、「デプロイメント管理者（Deployment manager）」と組み合わせると有効な場合があります。

プラットフォーム管理者（Platform admin）

このロールのユーザーは、インストールプロセスで作成されたシステムレベルのadminユーザー（またはECE 1.xでのrootユーザー）と同様に、ECEですべてのデータを閲覧し、任意のオペレーションを実行できます。このロールは通常、ECEプラットフォーム全体の責任を担う管理者のみが保持します。UIの「Platform」セクションが良い例です。そこでは、アロケーターとデプロイメントなどの情報や、アロケーターを無効にする機能、メンテナンスモードにする機能などが提供されます。

プラットフォーム閲覧者（Platform viewer）

このロールでは、プラットフォーム全体およびホストされたデプロイメントに関して閲覧のみのパーミッションが提供されます。関連付けられているパーミッションは、readonlyのシステムレベルユーザーと同様です。これは自動化、たとえばECEのステータスの監視などに便利です。

デプロイメント管理者（Deployments manager）

このロールでは、プラットフォーム上でデプロイメントの作成および管理ができます。このロールを持つユーザーは、スケールアップ、スケールダウン、スナップショットの設定、ノードの再起動、パスワードのリセットなど、デプロイメント上ですべてのアクションを実行できます。プラットフォームレベルの操作や、デプロイメントテンプレート、インスタンス設定、アロケーターなどのリソースへのアクセス権はありません。

このロールは、プラットフォームレベルの情報（デプロイメントチームの責任者など）を見る必要がない、デプロイメント管理の責任者に最適なロールです。

デプロイメント閲覧者（Deployments viewer）

このロールを持つユーザーは、デプロイメントを閲覧することはできますが、変更することはできません。このロールは、サポートスタッフまたはデプロイメントチームのメンバーに最適です。

ネイティブユーザーの管理

ECEでRBACの使用を開始する最も簡単な方法は、ネイティブユーザーを作成することです。これらは、Elasticsearchのネイティブレルムのセキュリティデプロイメントに保持され、ユーザー名、フルネーム、メール、パスワード、ロール、現在有効化されているかどうかといった、限られた属性のみがサポートされます。

ナビゲーションメニューで［Users］をクリックすると、認証プロバイダー（Authentication providers）を見ることができます。［Users］の下にはネイティブユーザー（Native users）プロファイルもあり、そのプロファイルを開くと全ネイティブユーザーのリストが表示されます。そのリストには、ECEのインストーラーによって作成された2人のシステムユーザーが含まれています。これらのユーザーを編集および削除することはできず、ここでそれらのパスワードをリセットすることもできません。パスワードのリセット方法の詳細については、ドキュメントを参照してください。

ネイティブユーザー作成のデモ

［Native users］ページで、ネイティブユーザーを作成、編集、削除できます。これらのユーザーは、システムユーザーと同様にECEにログインでき、そのアクセスは各ユーザーに割り当てられたロールによって制御されます。

ユーザー設定ページ

ECE 2.3にはユーザー設定ページも追加されています。ページの右上隅にあるユーザーアイコンをクリックし、［Settings］をクリックします。ネイティブユーザーとしてログインしている場合は、名前とメールを編集でき、パスワードを変更できます。外部認証プロバイダーからログインしている場合は、名前、認証プロファイルのタイプ、自分のロールなど、基本的な情報を表示する読み取り専用ページを見ることができます。

ユーザー設定の編集のデモ

外部認証プロバイダー

LDAP、Active Directory、またはSAMLサーバーをすでにお持ちの場合、認証および許可にそれらを使用するようECEを設定できます。また、複数のサーバーを構成して、Elasticsearchの設定と同様の順番で認証を実行することも可能です。既存の認証ソースを使用する場合は、ユーザーを1つの場所で管理するだけになります。外部プロバイダーのロールマッピング設定では、ユーザーの属性をECEのロールにマッピングできるため、ユーザーの属性（グループメンバーシップなど）に対する変更は、ECEによって自動的に取得されます。

認証プロバイダーの概要ページで［Add provider］をクリックし、タイプを選択します。次のページでプロバイダーを設定します。基本的なLDAP設定の構成オプションを見てみましょう。

LDAPプロバイダー作成のデモ

LDAP認証プロバイダー

［General LDAP settings］：

  1. どのプロファイルにも名前があります。名前はプロファイルのラベルとしてだけではなく、レルムIDを生成するためにも使用されます。注意が必要なのは、一旦プロファイルを作成するとレルムIDは変更できないことです。
  2. 最初にldap:またはldaps:と入力してから、1つ以上のLDAPサーバーを設定する必要があります。DNSベースのロードバランス戦略を選択する場合は、1つのサーバーのみを指定します。
  3. 上記の制限を考慮しながら、ロードバランス戦略を選択します。

［Trusted CA certificates］：

  1. LDAPサーバーを保護するために、クライアントに特定のSSL/TLS証明書の保持を要求する場合は、バンドルファイルを用意し、URL経由によってECEで利用できるようにする必要があります。詳細に関しては、ドキュメントを参照してください。
  2. バンドルをパスワード保護する場合は、ここでパスワードを提示します。

［Bind credentials］：

  1. 認証情報をLDAPサーバーにバインドする必要がある場合は、ここで設定できます。
  2. または、認証情報を必要としない場合は［Bind anonymously］を有効にします。

［Search mode settings］：

  1. ユーザー検索の各詳細を指定できます。これらのフィールドについては、ドキュメントを参照してください。少なくとも［Base DN for users］に、たとえば「cn=users,dc=example,dc=com」と設定します。
  2. または、LDAPクエリーの実行にテンプレートを使用する必要がある場合は、［Template］ラジオボタンをクリックして1つ以上のテンプレートを提供します。

［Group search settings］：

  1. 検索モードの設定と同様、ユーザーのグループについてECEの検索方法を設定できます。［Base DN for users］に、たとえば「ou=groups,dc=example,dc=com」と設定します。

［Role mappings］：

  1. ユーザーがECEで何かを実行するには、1つ以上のロールが必要です。認証されたすべてのユーザーに割り当てられるデフォルトのロールを指定することができます。たとえば、すべてのユーザーに「デプロイメント閲覧者（Deployment viewer）」ロールを割り当てることで、全ユーザーがECEでホストされているすべてのデプロイメントを見られるようにすることができます（編集はできません）。
  2. また、ロールマッピングを使用してロールを割り当てる方法もあります。これは、ユーザーDNまたはグループDNが何らかの値に一致した場合に特定のロールが割り当てられるというルールを使用します。マッピングは必要な数だけ保持できます。たとえば、ITオペレーションのユーザーに「デプロイメント閲覧者（Deployment viewer）」を割り当てるマッピング、すべての開発者に「デプロイメント管理者（Deployment manager）」を割り当てるマッピング、およびすべての管理者に「プラットフォーム閲覧者（Platform viewer）」を割り当てるマッピングを使用できます。

完了したら［Create profile］をクリックします。すると、ECEによってセキュリティデプロイメントが再構成されます。ここで、さまざまなLDAPユーザーでログインし、認証されること、およびそれらユーザーのロールが正しいことをチェックします。ユーザー設定ページで明示的に確認することも、またはUIを操作して、表示できるものや操作できるものが想定どおりかを確認することもできます。

Active DirectoryおよびSAML認証プロバイダー

このプロセスの概要は、ECEの観点からはLDAPと同様です。SAMLまたはActive Directory認証プロバイダーを作成して名前を付け、ECEとサーバーの通信方法を指定し、適用するマッピングを定義します。

SAML認証プロバイダーまたはActive Directory認証プロバイダーの構成の詳細については、ドキュメントを参照してください。

REST APIのサポート

上記のすべてのオペレーションは、REST APIを使用して実行することもできます。たとえば、現在無効化されているユーザーを含む、全ユーザーのリストを取得できます。 

GET /api/v1/users?include_disabled=true

例として、新しいシステム管理者のサラにアクセス権を付与する必要があるとします。下記のようにして、サラのために新しいネイティブユーザーを作成できます。 

POST /api/v1/users
{
  "user_name": "sarah",
  "security": {
    "roles": ["ece_platform_admin"],
    "password": "deadb33f"
  }
}

その後、サラのアクセスを変更する場合は、変更するフィールドのみを明示して（ここではロール）、PATCHリクエストを送信します。 

PATCH /api/v1/users/sarah
{
  "security": {
    "roles": ["ece_platform_viewer"]
  }
}

サラのアカウントを削除する場合は、DELETEリクエストを送信します。 

DELETE /api/v1/users/sarah

詳細および認証プロバイダーエンドポイントについては、REST APIドキュメントを参照してください。

今すぐ使い始めましょう

ECE 2.3での変更の一覧については、リリースノートを確認してください。また、試用する場合は30日間の無料トライアルを今すぐ開始することができます。