ルールベース認証プラグイン

Solrは、重要なSolr APIおよび機能へのきめ細かいユーザーアクセス制御を提供する認証プラグインを提供します。

Solrの認証プラグインは、ユーザーがSolrにアクセスできるかどうかを二進数的に制御します。ユーザーは認証されるか、認証されないかのいずれかです。よりきめ細かいアクセス制御については、Solrのルールベース認証プラグイン（RBAP）を使用できます。

Solrの管理UIは、通常のAPIを使用してSolrと対話します。ルールベースの認証が使用されている場合、これらのAPIのすべての範囲にアクセスする権限がないログインユーザーには、空白または「破損」しているように見えるUIの一部が表示される場合があります。

最良の結果を得るには、管理UIは、すべてのAPIアクセス権を持つユーザーのみがアクセスする必要があります。

ルールベース認証の概念

「ユーザー」、「ロール」、「権限」は、認証を正しく構成する上で中心的な役割を果たします。

ルールベースの認証では、管理者は、ロールに与えたい権限に基づいて一連のロールを定義します。次に、ユーザーに1つ以上のロールが割り当てられます。

ユーザー

RBAPが認識するユーザーは、構成されている認証プラグインから取得されます。RBAPは、Solrがすぐに提供するすべての認証プラグインと互換性があります。また、ユーザーが作成するカスタム認証プラグインとも互換性があります。ただし、プラグインが受信するHttpServletRequestにユーザープリンシパルを設定する必要があります。

各ケースでRBAPが認識するユーザーの値は、使用されている認証プラグインによって異なります。Kerberos認証プラグインが使用されている場合はKerberosプリンシパル、JWT認証プラグインが使用されている場合は「sub」JWTクレームなどです。

ロール

ロールは、ユーザーと権限の間のギャップを埋めます。ロールは、すべての認証プラグインまたはカスタム認証プラグインで使用できます。必要なのは、ログインユーザーがプラグインで定義されたロールにマッピングされていることを確認することだけです。

プラグインには2つの実装があり、ユーザーのロールの取得方法のみが異なります。

RuleBasedAuthorizationPlugin：ロールとユーザーのマッピングは、認証された可能性のあるすべてのユーザーについて、security.jsonで明示的に定義する必要があります。
ExternalRoleRuleBasedAuthorizationPlugin：ロールとユーザーのマッピングは外部で管理されます。このプラグインは、AuthenticationPluginがロール情報も持つプリンシパルを提供し、VerifiedUserRolesインターフェースを実装することを期待します。

権限

パーミッションは、どのロール（ひいてはどのユーザー）がどのSolr APIにアクセスできるかを制御します。

各パーミッションには、主に2つの要素があります。パーミッションが適用されるAPIの説明と、このAPIセットへのアクセスを許可する必要のあるロールのリストです。

管理者は、定義済みのオプションのリストからパーミッションを使用したり、独自のカスタムパーミッションを定義したりできます。これらを組み合わせて使用することも自由です。

ルールベース認証プラグインの設定

Solrのすべてのセキュリティプラグインと同様に、RBAPの設定はsecurity.jsonという名前のファイルまたはZooKeeperノードにあります。クラスターでのsecurity.jsonの設定方法については、security.jsonの設定を参照してください。

Solrは、RBAP設定を変更するための認証APIを提供しています。ほとんどの場合、認証された管理者はこれを使用して変更を行う必要があります。ユーザーは、ZooKeeperに保存されている場合は、security.jsonを直接編集することもできますが、これはエキスパートレベルの機能であり、ほとんどの場合推奨されません。APIは設定のいくつかの側面を簡素化し、ZooKeeperを直接編集するときには提供されないエラーフィードバックを提供します。

設定構文

RBAP設定は、少数の必須の設定プロパティで構成されています。これらの各プロパティは、security.jsonの最上位プロパティであるauthorizationの下にあります。

class

必須

デフォルト: なし

使用する認証プラグイン。3つのオプションがあります: solr.RuleBasedAuthorizationPlugin、solr.ExternalRoleRuleBasedAuthorizationPlugin、またはsolr.MultiAuthRuleBasedAuthorizationPlugin。

permissions

オプション

デフォルト: なし

SolrのAPIのセクションへのアクセスを制限するために使用されるパーミッションルールのJSON配列。例:

{
  "permissions": [
  { "name": "read", "collection": "techproducts", "role": ["admin", "dev"] },
  { "name": "all", "role": "admin"}
  ]
}

個々のパーミッションの構文はより複雑であり、下記で詳細に説明します。

classにExternalRoleRuleBasedAuthorizationPluginを使用する場合、ユーザーロールはリクエスト自体から取得される場合があります。この場合、permissionsの定義はスキップします。

ユーザーロールのマッピングをハードコードする必要がある場合は、classにRuleBasedAuthorizationPluginを定義し、security.jsonで次のようにユーザーロールのマッピングを定義します。

user-role

オプション

デフォルト: なし

個々のユーザーと割り当てられたロールのマッピング。このパラメーターの値はJSONマップであり、各プロパティ名はユーザーであり、各プロパティ値は、指定されたユーザーが属する単一のロールの名前または複数のロールのJSON配列です。

例:

{
  "user-role": {
  "user1": "role1",
  "user2": ["role1", "role2"]
  }
}

useShortName

オプション

デフォルト: false

ユーザーロールのマッピングを、完全なプリンシパルを使用するか、認証プラグインによって提供される短縮名を使用して解決するかを決定します。たとえば、KerberosAuthPluginは完全なプリンシパルをuser@EXAMPLE.COMとして提供する場合がありますが、対応する短縮名はuserになります。

一部のプラグインでは、プリンシパル名と短縮名が同じ場合があります。

RuleBasedAuthorizationPluginとBasicAuthの例

このsecurity.jsonの例は、基本認証プラグインがRuleBasedAuthorizationPluginプラグインと連携する方法を示しています。

{
  "authentication": {
    "class": "solr.BasicAuthPlugin", (1)
    "blockUnknown": true,
    "credentials": {
      "admin-user": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=",
      "dev-user": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="
    }
  },
  "authorization": {
    "class": "solr.RuleBasedAuthorizationPlugin", (2)
    "user-role": { (3)
      "admin-user": "admin",
      "dev-user": "dev"
    },
    "permissions": [ (4)
      { "name": "dev-private-collection", "collection": "dev-private", "role": "dev"},
      { "name": "security-read", "role": "admin"},
      { "name": "security-edit", "role": "admin"}
    ]
  }
}

1	Solrは認証に基本認証プラグインを使用しています。この設定では、`admin-user`と`dev-user`の2人のユーザーを確立します。
2	`authorization`プロパティは、認証設定を開始します。Solrは認証にRBAPを使用します。
3	`admin`と`dev`の2つのロールが定義されています。各ユーザーは1つのロールに属しています。`admin-user`は`admin`であり、`dev-user`は`dev`です。
4	3つのパーミッションがSolrへのアクセスを制限します。最初のパーミッション（「カスタム」パーミッション）は、`dev`ロールのみが`dev-private`という名前の特別なコレクションから読み取ることができることを示します。最後の2つのパーミッション（「定義済み」パーミッション）は、`admin`ロールのみがSolrのセキュリティAPIを使用できることを示します。パーミッション構文の詳細については、以下を参照してください。

全体として、この例では2つの制限付き領域を分割します。admin-userのみがSolrの認証および承認APIにアクセスでき、dev-userのみが自分のdev-privateコレクションにアクセスできます。その他のすべてのAPIは開いたままにしてあり、両方のユーザーがアクセスできます。

JWT認証を使用したExternal Role RuleBasedAuthorizationPluginの例

このsecurity.jsonの例は、JWTクレームからユーザーおよびユーザーロールを取得するJWT認証プラグインがExternalRoleRuleBasedAuthorizationPluginプラグインと連携する方法を示しています。

{
"authentication":{
   "class": "solr.JWTAuthPlugin", (1)
   "jwksUrl": "https://my.key.server/jwk.json", (2)
   "rolesClaim": "roles" (3)
},
"authorization":{
   "class":"solr.ExternalRoleRuleBasedAuthorizationPlugin", (4)
   "permissions":[{"name":"security-edit",
      "role":"admin"}] (5)
}}

この例を見ていきましょう。

1	JWT認証プラグインが有効になっています。
2	公開鍵はHTTPS経由で取得されます。
3	各JWTトークンには、認証に渡される「roles」クレームが含まれていると想定しています。
4	外部ロールベースの認証プラグインが有効になっています。
5	「admin」ロールが定義されており、セキュリティ設定を編集する権限があります。

「admin」ロールを持つJWTトークンを持つユーザーからのリクエストのみに、security-editパーミッションが付与されます。

複数の認証プラグイン

security.json設定でMultiAuthPluginを使用している場合は、MultiAuthRuleBasedAuthorizationPluginを使用して、認証プラグインごとに異なる認証プラグインを使用します。

次の例は、MultiAuthRuleBasedAuthorizationPluginを使用して、BasicおよびBearerスキームの認証プラグインを設定する方法を示しています。

{
  "authorization": {
    "class": "solr.MultiAuthRuleBasedAuthorizationPlugin",
    "schemes": [
      {
        "scheme": "basic",
        "class": "solr.RuleBasedAuthorizationPlugin",
        "user-role": {
          "k8s-oper": ["k8s"]
        }
      },
      {
        "scheme": "bearer",
        "class": "solr.ExternalRoleRuleBasedAuthorizationPlugin"
      }
    ],
    "permissions": []
  }
}

同じユーザーアカウントが両方のプラグインに存在することはまれです。ただし、MultiAuthRuleBasedAuthorizationPluginは、ユーザーのロールを決定するときに、すべてのプラグインからのロールを結合します。

ユーザーは、基本認証を使用する場合に、サービスアカウントがアクセスする必要のある正確なエンドポイントのセットをロックダウンするように特に注意する必要があります。たとえば、MultiAuthPluginがk8s-operユーザーに基本認証の使用を許可する場合（他のすべてのユーザーはOIDCを介してアクセス）、k8s-operユーザーに設定されたパーミッションは、/admin/info/systemなどの特定のエンドポイントへのアクセスのみを許可する必要があります。

パーミッション

Solrのルールベース認証プラグインは、柔軟で強力なパーミッション構文をサポートしています。RBAPは2種類のパーミッションをサポートしており、それぞれ構文が少し異なります。

カスタムパーミッション

管理者は、コレクション、リクエストハンドラー、HTTPメソッド、特定のリクエストパラメーターなどに基づいてリクエストを照合できる独自のカスタムパーミッションを作成できます。

各カスタムパーミッションは、permissionsパラメーターの下にあるJSONオブジェクトであり、以下のプロパティの1つ以上を含んでいます。

name

オプション

デフォルト: なし

パーミッションの識別子。

カスタムパーミッションの場合、これはこのパーミッションが何をするのかを管理者に示すヒントとしてのみ使用されます。

このパラメーターを設定するときは、名前が予約されているSolrの定義済みパーミッションのいずれかと衝突しないように注意する必要があります。この名前が定義済みパーミッションと一致する場合、Solrは他の設定されたプロパティを無視し、代わりに定義済みパーミッションのセマンティクスを使用します。

collection

オプション

デフォルト: * (すべて)

パーミッションが適用されるコレクションを定義します。値は、単一のコレクション名、または複数のコレクションを含むJSON配列にすることができます。

ワイルドカード*は、このルールがすべてのコレクションに適用されることを示すために使用されます。同様に、特別な値nullは、このパーミッションがSolrのコレクションに依存しない（「admin」）APIを制御することを示すために使用できます。

collectionパラメーターには、実際のコレクション名のみを含めることができます。現在、エイリアスを照合するために使用することはできません。

+ エイリアスは、Solrのセキュリティプラグインが呼び出される前に解決されます。エイリアスを値として指定したcollectionパラメーターは、RBAPがエイリアス名をすでに解決済みのコレクション名と比較するため、決して一致しません。

+ 代わりに、関係するエイリアスのすべてのコレクション（または*ワイルドカード）を含むcollectionパラメーターを設定します。

path

オプション

デフォルト: null

パーミッションが適用されるパスを定義します。値は、単一のパス文字列、または複数の文字列を含むJSON配列にすることができます。

コレクションにアクセスするAPIの場合、パス値はコレクション名の後から始める必要があり、多くの場合、リクエストハンドラー（例："/select"）のように見えます。

コレクションに依存しない（別名「admin」）APIの場合、パス値は"/adminパスセグメントから始める必要があります。ワイルドカード\*は、このパーミッションがすべてのパスに適用されることを示すために使用できます。

method

オプション

デフォルト: *

このパーミッションが適用されるHTTPメソッドを定義します。オプションには、HEAD、POST、PUT、GET、DELETE、およびワイルドカード\*が含まれます。複数の値はJSON配列を使用して指定することもできます。

params

オプション

デフォルト: なし

パーミッションが適用されるクエリパラメーターを定義します。値は、このパーミッションを適用するために一致する必要があるリクエストパラメーターの名前と値を含むJSONオブジェクトです。

たとえば、このパラメーターを使用して、ロールがコレクションAPIで実行できるアクションを制限できます。ロールがLISTまたはCLUSTERSTATUSリクエストのみを実行できるようにする必要がある場合は、次のように定義します。

{"params": {
   "action": ["LIST", "CLUSTERSTATUS"]
   }
 }

リクエストパラメーターの値は、単純な文字列または正規表現にすることができます。単純な文字列照合ではなく正規表現照合を使用するには、プレフィックスREGEX:を使用します。

コマンドLISTとCLUSTERSTATUSが大文字と小文字を区別しない場合、上記の例は次のように記述できます。

{"params": {
   "action": ["REGEX:(?i)LIST", "REGEX:(?i)CLUSTERSTATUS"]
 }
}

role

必須

デフォルト: なし

このパーミッションによって制御されるAPIへのアクセスを許可されるロール（またはロール）を定義します。複数の値はJSON配列を使用して指定できます。ワイルドカード*は、すべてのロールが記述された機能にアクセスできることを示すために使用できます。

定義済みパーミッション

カスタムパーミッションを使用すると、管理者はきめ細かいアクセス制御を柔軟に構成できます。ただし、構成をできるだけ簡単にするために、RBAPは多くの一般的なユースケースをカバーする、いくつかの定義済みパーミッションも提供しています。

管理者は、Solrの定義済みパーミッションオプション（以下にリスト）の1つと一致するnameを選択することにより、定義済みパーミッションを呼び出します。Solrにはこれらの各パーミッションの独自の定義があり、定義済みパーミッションが着信リクエストと一致するかどうかを確認するときにこの情報を使用します。これにより、柔軟性が簡素化されます。定義済みパーミッションは、カスタムパーミッションが許可するpath、params、またはmethodプロパティをサポートしていません。

定義済みパーミッションの名前（とその効果）は次のとおりです。

security-edit: このパーミッションはセキュリティ設定を編集することが許可されています。つまり、APIを介してsecurity.jsonを変更する更新アクションはすべて許可されます。
security-read: この権限は、セキュリティ設定の読み取りを許可します。つまり、APIを通じてsecurity.jsonの設定を読み取るすべてのアクションが許可されます。
schema-edit: この権限は、Schema APIを使用してコレクションのスキーマを編集することを許可します。これは、すべてのコレクションに対するスキーマ編集権限を許可することに注意してください。特定のコレクションにのみ編集権限を適用する必要がある場合は、カスタム権限を作成する必要があります。
schema-read: この権限は、Schema APIを使用してコレクションのスキーマを読み取ることを許可します。これは、すべてのコレクションに対するスキーマ読み取り権限を許可することに注意してください。特定のコレクションにのみ読み取り権限を適用する必要がある場合は、カスタム権限を作成する必要があります。
config-edit: この権限は、Config API、Request Parameters API、およびconfigoverlay.jsonを変更するその他のAPIを使用して、コレクションの設定を編集することを許可します。設定はさまざまな場所からライブラリ/カスタムコードを追加できるため、信頼されたSolrConfigを介して新しいコードをロードすることは、この権限を持つユーザーに対して明示的に許可されています。これは、すべてのコレクションに対する設定編集権限を許可することに注意してください。特定のコレクションにのみ編集権限を適用する必要がある場合は、カスタム権限を作成する必要があります。
config-read: この権限は、Config API、Request Parameters API、Configsets API、Admin UIのFiles Screen、および設定にアクセスするその他のAPIを使用して、コレクションの設定を読み取ることを許可します。これは、すべてのコレクションに対する設定読み取り権限を許可することに注意してください。特定のコレクションにのみ読み取り権限を適用する必要がある場合は、カスタム権限を作成する必要があります。
metrics-read: この権限は、SolrのMetrics API、solr/<collection>/admin/mbeansやsolr/<collection>/admin/segmentsなど、いくつかの暗黙的な管理ハンドラー、およびメトリクスを公開するその他の管理APIへのアクセスを許可します。
health: この権限は、ノードまたはコアが正常かどうかを監視するためによく使用される、SolrのヘルスチェックおよびPingエンドポイントへのアクセスを許可します。
core-admin-edit: システム状態を変更できるコア管理コマンド。
core-admin-read: コア管理APIでの読み取り操作。

collection-admin-edit: この権限は、Collections APIを使用してコレクションの設定を編集することを許可します。これは、すべてのコレクションに対する設定編集権限を許可することに注意してください。特定のコレクションにのみ編集権限を適用する必要がある場合は、カスタム権限を作成する必要があります。

具体的には、Collections APIの次のアクションが許可されます。

CREATE

RELOAD

SPLITSHARD

CREATESHARD

DELETESHARD

CREATEALIAS

DELETEALIAS

DELETE

DELETEREPLICA

ADDREPLICA

CLUSTERPROP

MIGRATE

ADDROLE

REMOVEROLE

ADDREPLICAPROP

DELETEREPLICAPROP

BALANCESHARDUNIQUE

REBALANCELEADERS

collection-admin-read: この権限は、Collections APIを使用してコレクションの設定を読み取ることを許可します。これは、すべてのコレクションに対する設定読み取り権限を許可することに注意してください。特定のコレクションにのみ読み取り権限を適用する必要がある場合は、カスタム権限を作成する必要があります。

具体的には、Collections APIの次のアクションが許可されます。

LIST
OVERSEERSTATUS
CLUSTERSTATUS
REQUESTSTATUS
update: この権限は、任意のコレクションで任意の更新アクションを実行することを許可します。これには、ドキュメントのインデックス作成のための送信（更新リクエストハンドラーを使用）が含まれます。これはデフォルトですべてのコレクションに適用されます（collection:"*"）。
read: この権限は、任意のコレクションで任意の読み取りアクションを実行することを許可します。これには、/select、/get、/tvrh、/terms、/clustering、/elevate、/export、/spell、/clustering、/sqlなどの検索ハンドラー（リクエストハンドラーを使用）を使用したクエリが含まれます。これはデフォルトですべてのコレクションに適用されます（collection:"*"）。
zk-read: ZKからコンテンツを読み取る権限（/api/cluster/zk/data/ , /api/cluster/zk/ls/）
all: Solrへのすべてのリクエスト。

権限の順序付けと解決

上記の権限構文では、複数の権限が重複し、同じSolr APIに適用されるのを防ぐことはできません。複数の権限が受信リクエストに一致する場合、Solrは最初に一致した権限を選択し、他のすべての権限を無視します。これらの他の権限が受信リクエストに一致する場合でもです！

Solrは最初に見つかった一致する権限のみを使用するため、管理者は権限リストを処理する際にSolrが使用する順序を理解することが重要です。

Solrが使用する順序は複雑です。Solrは、受信リクエストに固有または関連する権限を最初にチェックし、より具体的な権限が一致しない場合にのみ、より一般的な権限に移行しようとします。実際には、これは、異なるリクエストが非常に異なる順序で同じ権限をチェックする可能性があることを意味します。

受信リクエストがコレクションに依存しない場合（特定のコレクションに適用されない場合）、Solrは次の順序で権限をチェックします。

collectionの値がnullで、pathの値がリクエストのリクエストハンドラーに一致する権限
collectionの値がnullで、pathの値が*の権限
collectionの値がnullで、pathの値がnullの権限

受信リクエストがコレクションに対するものである場合、Solrは次の順序で権限をチェックします。

collectionとpathの値がリクエストと具体的に一致する（ワイルドカード一致ではない）権限
collectionがリクエストと具体的に一致し、pathの値が*の権限
collectionがリクエストと具体的に一致し、pathの値がnullの権限
pathがリクエストと具体的に一致し、collectionの値が*の権限
collectionとpathの値が両方とも*の権限。
collectionの値が*で、pathの値がnullの権限

例として、以下の権限を考えてみましょう。

{"name": "read", "role": "dev"}, (1)
{"name": "coll-read", "path": "/select", "role": "*"}, (2)
{"name": "techproducts-read", "collection": "techproducts", "role": "other", "path": "/select"}, (3)
{"name": "all", "role": "admin"} (4)

このリスト内のすべての権限は/selectクエリに一致します。ただし、クエリされるコレクションによって、異なる権限が使用されます。

"techproducts"コレクションへのクエリの場合、"techproducts"を具体的にターゲットとするため、権限3が使用されます。otherロールを持つユーザーのみが承認されます。

一方、collection1というコレクションへのクエリの場合、最も具体的な権限は権限2であるため、すべてのロールにアクセス権が付与されます。

認証API

認証APIエンドポイント

/admin/authorization: 権限を作成し、権限をロールにマッピングし、ロールをユーザーにマッピングする一連のコマンドを受け付けます。

権限の管理

3つのコマンドが権限の管理を制御します。

set-permission: 新しい権限を作成するか、既存の権限定義を上書きするか、事前定義された権限をロールに割り当てます。
update-permission: 既存の権限定義のいくつかの属性を更新します。
delete-permission: 権限定義を削除します。

作成されたプロパティは、カスタムまたは事前定義されたものにすることができます。

上記の権限構文に加えて、これらのコマンドでは、権限にbeforeプロパティを持たせることもできます。このプロパティの値は、security.jsonでこの新しい権限を配置する前に配置する必要がある権限のインデックスに一致します。

以下は、コレクションを作成およびリストすることを許可する「collection-mgr」という名前の新しい権限を作成します。権限は「read」権限の前に配置されます。また、Collections APIへのリクエストはコレクション固有ではないため、collectionをnullとして定義したことにも注意してください。

curl --user solr:SolrRocks -H 'Content-type:application/json' -d '{
  "set-permission": {"collection": null,
                     "path":"/admin/collections",
                     "params":{"action":["LIST", "CREATE"]},
                     "before": 3,
                     "role": "admin"}
}' https://127.0.0.1:8983/solr/admin/authorization

すべてのコレクションに対する更新権限をdevというロールに適用し、読み取り権限をguestというロールに適用します。

curl --user solr:SolrRocks -H 'Content-type:application/json' -d '{
  "set-permission": {"name": "update", "role":"dev"},
  "set-permission": {"name": "read", "role":"guest"}
}' https://127.0.0.1:8983/solr/admin/authorization

権限の更新または削除

権限には、リスト内のインデックスを使用してアクセスできます。既存の権限とそのインデックスを表示するには、/admin/authorization APIを使用してください。

次の例は、インデックス3の権限の'role'属性を更新します。

curl --user solr:SolrRocks -H 'Content-type:application/json' -d '{
  "update-permission": {"index": 3,
                       "role": ["admin", "dev"]}
}' https://127.0.0.1:8983/solr/admin/authorization

次の例は、インデックス3の権限を削除します。

curl --user solr:SolrRocks -H 'Content-type:application/json' -d '{
  "delete-permission": 3
}' https://127.0.0.1:8983/solr/admin/authorization

ユーザーへのロールのマッピング

単一のコマンドでロールをユーザーにマッピングできます。

set-user-role: ユーザーを権限にマッピングします。

ユーザーの権限を削除するには、ロールをnullに設定する必要があります。ユーザーロールを削除するコマンドはありません。

コマンドに指定される値は、ユーザーIDと、ユーザーが持つ必要のある1つ以上のロールだけです。

たとえば、次のコマンドでは、ユーザー「solr」に「admin」および「dev」ロールを付与し、ユーザーID「harry」からすべてのロールを削除します。

curl -u solr:SolrRocks -H 'Content-type:application/json' -d '{
   "set-user-role" : {"solr": ["admin","dev"],
                      "harry": null}
}' https://127.0.0.1:8983/solr/admin/authorization