認証と承認の設定

Solr は、ユーザーの認証、承認、および監査をサポートするためのセキュリティフレームワークを備えています。これにより、ユーザーの身元を確認し、Solr クラスタ内のリソースへのアクセスを制限することができます。

Solr には、すぐに使用できるプラグインがいくつか含まれており、以下で説明する認証、承認、および監査ログフレームワークを使用して追加のプラグインを開発できます。

すべての認証、承認、および監査ログプラグインは、クラスタとして実行されているか、単一ノードインストールとして実行されているかに関係なく、Solr で動作します。ユーザーや許可ルールを含むすべての関連設定は、security.json という名前のファイルに保存されます。 SolrCloud を使用する場合、このファイルは ZooKeeper 構造の chroot に配置する必要があります。 chroot が指定されていない場合は、ルートに配置する必要があります。 Solr をスタンドアロンモード（ZooKeeper なし）で実行する場合、このファイルは $SOLR_HOME ディレクトリにある必要があります。抽出されたアーカイブから Solr を手動で実行する場合、これはおそらく server/solr になります。サービスインストーラースクリプトを使用する場合、デフォルトの場所は /var/solr/data になり、これはサービスインストーラーに指定されたオプションで変更できます。

security.json の設定

セキュリティプラグインの初期化に必要なすべての情報は、security.json ファイルに保存されます。このファイルには、認証、承認、および監査ログのそれぞれに 1 つずつ、3 つのセクションが含まれています。

security.json の例
{
  "authentication" : {
    "class": "class.that.implements.authentication"
  },
  "authorization": {
    "class": "class.that.implements.authorization"
  },
  "auditlogging": {
    "class": "class.that.implements.auditlogging"
  }
}

Solr インスタンスが起動する前に /security.json ファイルを適切な場所に配置する必要があります。そのため、Solr はセキュリティプラグインが有効になっている状態で起動します。これを行う方法については、以下の Solr での security.json の使用 セクションを参照してください。

使用中のプラグインに応じて、ユーザー情報やロールとアクセス許可を作成するためのルールなど、他の情報が security.json に保存されます。この情報は、Solr によって提供される各プラグインの API、またはカスタムプラグインの場合は、設計したアプローチを通じて追加されます。

より詳細なsecurity.jsonの例を以下に示します。この例では、Basic認証とルールベースの承認プラグインが有効になっており、いくつかのデータが追加されています。

{
"authentication":{
   "class":"solr.BasicAuthPlugin",
   "credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
},
"authorization":{
   "class":"solr.RuleBasedAuthorizationPlugin",
   "permissions":[{"name":"security-edit",
      "role":"admin"}],
   "user-role":{"solr":"admin"}
}}

Solrでのsecurity.jsonの使用

SolrCloudクラスタの場合

Solrで認証または承認プラグインを使用するように設定する場合、security.jsonファイルをZooKeeperにアップロードする必要があります。

以下の内容でsecurity.jsonファイルを作成します。

{"authentication": {"class": "solr.KerberosPlugin"}}

この例では、認証にKerberosPluginが定義されていることに注意してください。使用しているプラグインに合わせて、このセクションを適切に変更する必要があります。

次に、bin/solr zkコマンドを使用してファイルをアップロードします。

>bin/solr zk cp ./security.json zk:security.json -z localhost:2181
solr.in.sh/solr.in.cmdでZK_HOSTを定義している場合（Solrインクルードファイルの更新を参照）、上記のコマンドから-z <zk host string>を省略できます。

セキュリティプラグインを使用し、security.jsonをZooKeeperに保存する場合は、ZooKeeperノードにアクセス制御を実装することを強くお勧めします。有効化する方法については、ZooKeeperアクセス制御のセクションを参照してください。

security.jsonがZooKeeperにアップロードされたら、使用しているプラグインに適切なAPIを使用して更新する必要があります。手動で編集することもできますが、すべてのZooKeeperノードで適切に更新されるように、バージョンデータを削除する必要があります。バージョンデータはsecurity.jsonファイルの最後にあり、「v」の後に数字が続きます（例：{"v":138}）。

ユーザー管理クラスタまたはシングルノードインストールの場合

ユーザー管理クラスタまたはシングルノードインストールでSolrを実行する場合、security.jsonファイルを作成し、インストールの$SOLR_HOMEディレクトリに配置します（これはsolr.xmlと同じ場所で、通常はserver/solrです）。

ユーザー管理クラスタでは、クラスタの各ノードにsecurity.jsonを配置する必要があります。

認証および承認APIを使用できますが、ユーザー管理クラスタでは、各ノードで同じAPIリクエストを個別に実行する必要があります。必要に応じて、security.jsonを手動で編集することもできます。

認証

認証プラグインは、受信リクエストを認証することにより、Solrのエンドポイントのセキュリティ保護に役立ちます。カスタムプラグインは、AuthenticationPluginクラスを拡張することで実装できます。

認証プラグインは2つの部分で構成されています。

  1. サーバー側コンポーネント：Kerberos、Basic認証などのプラグインで定義されたメカニズムを使用して、Solrへの受信リクエストをインターセプトして認証します。

  2. クライアント側コンポーネント：HttpClientConfigurerの拡張機能。SolrJクライアントが、サーバーが理解できる認証メカニズムを使用して、セキュアなSolrインスタンスにリクエストを送信できるようにします。

認証プラグインの有効化

この例のように、/security.jsonで認証プラグインを指定します。

{
  "authentication": {
    "class": "class.that.implements.authentication",
    "other_data" : "..."}
}

security.jsonのauthenticationブロック内のすべてのコンテンツは、初期化中にマップとしてプラグインに渡されます。

認証プラグインは、起動時に-DauthenticationPlugin=<plugin class name>を渡すことにより、シングルノードSolrインスタンスでも使用できます。

現在利用可能な認証プラグインは次のとおりです。

ベーシック認証プラグイン

Kerberos 認証プラグイン

JWT 認証プラグイン

証明書認証プラグイン

Hadoop 認証プラグイン

承認

AuthorizationPluginインターフェースを拡張することにより、Solrの承認プラグインを作成できます。

承認プラグインの有効化

プラグインの実装はクラスパスに存在する必要があります。その後、security.jsonで次のように指定することで、プラグインを初期化できます。

{
  "authorization": {
    "class": "org.apache.solr.security.MockAuthorizationPlugin",
    "other_data" : "..."}
}

security.jsonのauthorizationブロック内のすべてのコンテンツは、初期化中にマップとしてプラグインに渡されます。

プラグインの再読み込みはまだサポートされておらず、Solrインストールの再起動が必要です（つまり、コアの再読み込みではなく、JVMを再起動する必要があります）。

現在利用可能な承認プラグインは次のとおりです。

ルールベースの承認プラグイン

外部ロールルールベース承認プラグイン

管理UIでの認証

認証プラグインが有効になっている場合は、管理UIのすべてまたは一部の操作にも認証が必要です。管理UIはブラウザ内で実行されるAngularJSアプリケーションであり、Solrによって他の外部クライアントと同様に扱われます。

認証が必要な場合、管理UIにログインダイアログが表示されます。管理UIで現在サポートされている認証プラグインは次のとおりです。

選択したプラグインがサポートされていない場合でも、管理UIでは制限のない操作を実行できます。制限付きの操作の場合は、管理UIのグラフィカルユーザーインターフェースではなく、HTTPリクエストを送信してSolrと対話する必要があります。管理UIでサポートされているすべての操作は、SolrのAPIを介して実行できます。

ノード間リクエストのセキュリティ保護

Solrノード自体から発信されるリクエストは多数あります。たとえば、overseerからノードへのリクエスト、リカバリ スレッドなどです。これらを「ノード間」リクエストと呼びます。Solrには、ノード間トラフィックを保護するために常に利用できる組み込みのPKIAuthenticationPlugin（下記参照）があります。

各認証プラグインは、独自のノード間リクエストを保護することもできます。これらは、いわゆるHttpClientBuilderメカニズムを通じて行うことも、HTTPヘッダーを設定できる基本クラスのinterceptInternodeRequest()メソッドをオーバーライドすることにより、PKIに委任するかどうかをリクエストごとに選択することもできます。

PKIAuthenticationPlugin

PKIAuthenticationPluginは、各Solrノードがスーパーユーザーであり、公開鍵基盤（PKI）の使用を通じて他のSolrノードによって完全に信頼される組み込みの認証メカニズムを提供します。各認証プラグインは、すべてまたは一部のノード間トラフィックをPKIプラグインに委任することを選択できます。

現在、SolrではPKI認証プロトコルの2つのバージョンが利用可能です。送信リクエストごとに、PKIAuthenticationPluginはリクエストのタイムスタンプとユーザープリンシパルを保持する特別なヘッダーを追加します。ノードがこの特別なヘッダーを含むリクエストを受信すると、対応する送信元ノードの公開鍵を使用してメッセージを検証します。メッセージの検証は、ZooKeeperに登録されている他のSolrノードからの受信トラフィックに対してのみ試行されます。リクエストがPKI検証に合格し、タイムスタンプが5秒未満の場合、リクエストは信頼されます。

注：PKI認証プラグインは比較的短いタイムスタンプの有効期限に依存してリクエストを検証するため、クラスタ内の個別のノードのクロックを同期させる必要があります。

プロトコルのバージョン2はデフォルトバージョンです。このバージョンでは、SolrAuthV2ヘッダーには、送信元ノード名、ユーザープリンシパル、リクエストタイムスタンプ、およびbase64エンコードされたRSA署名が含まれています。すべてのノードは、最初にこのヘッダーの検証を試みます。

古いバージョンからのローリング再起動をサポートするために、プロトコルv1を使用してPKI認証を受け入れて検証するようにSolrを設定できます。これは、システムプロパティsolr.pki.sendVersion=v1とsolr.pki.acceptVersions=v1,v2を設定することで有効になります。有効にすると、リクエストには、送信者の秘密鍵を使用して暗号化されたユーザープリンシパルとタイムスタンプを含むSolrAuthヘッダーが含まれます。

SolrAuthV2ヘッダーが存在するが検証に失敗した場合、SolrはSolrAuthのチェックにフォールバックしません。レガシー認証ヘッダーは、最新のヘッダーが存在しない場合にのみ参照されます。

solr.pki.acceptVersionの不明な値は警告ログメッセージを出力しますが、将来のプロトコルリビジョンをよりスムーズにサポートするためにエラーは発生しません。

タイムアウトは、pkiauth.ttlというシステムプロパティで設定できます。たとえば、有効期間を10秒（10,000ミリ秒）に増やす場合は、各ノードをプロパティ'-Dpkiauth.ttl=10000'で起動します。