セキュリティドメイン

セキュリティドメインは、Elastic Stackがこれらのレルムで単一のユーザーが認証されたときに認識できるように、同じドメインの下に複数の realms をグループ化する方法です。ユーザーはドメイングループ内の任意のレルムで認証でき、どのレルムで認証したかに関係なく、同じリソースセットにアクセスできます。

たとえば、単一の user profile がユーザーに関連付けられており、設定、通知、および他のユーザーデータがレルム間で共有されます。ユーザーは、非同期検索リクエストまたはレルム間のスクロール検索の結果を表示できます。ユーザーが必要な権限を持っている場合、レルム間でAPIキーを表示および管理することもできます。

ドメイン間のリソース共有

Elasticsearchの一部のリソースタイプは、async search contextsAPI keys、および user profiles のように、単一のユーザーによって所有されます。ユーザーがリソースを作成すると、Elasticsearchはリソースのメタデータの一部としてユーザーのユーザー名とレルム情報をキャプチャします。同様に、ユーザーがAPIキーなどのリソースを更新すると、Elasticsearchは自動的にユーザーの現在のレルム情報を再キャプチャします。

その後、ユーザーがリソースにアクセスしようとすると、Elasticsearchはキャプチャされたユーザー名とレルム情報をアクセスするユーザーの情報と比較します。レルムとユーザー名の両方が一致しない限り、Elasticsearchはアクセスを拒否します。Elasticsearchが異なる2つのレルムからのユーザー名がリソースにアクセスしようとしていることを検出した場合、Elasticsearchはこれらのユーザーが異なるものであると見なし、リソースを共有することを許可しません。

ただし、同じユーザーが複数のレルムで認証でき、レルム間で同じリソースセットを共有する必要がある場合があります。たとえば、LDAP realmSAML realm は、同じディレクトリサービスをバックにすることができます。さらに、authorization delegation により、1つのレルムが別のレルムに権限を委任できます。両方のレルムが同じユーザー名でユーザーを認証する場合、リソース所有権の観点からこれらのユーザーを同じユーザーとして扱うことは合理的です。

セキュリティドメインは、これらのレルムを同じドメインの下にグループ化することによって、レルム間のリソース共有を可能にします。Elasticsearchは常に現在認証されているユーザーに関連付けられた権限を強制し、これはセキュリティドメインでも同様です。リソース共有が必要な場合、セキュリティドメインは user authorization をバイパスしません。たとえば、ユーザーは自分のAPIキーを管理するために manage_own_api_key 権限を必要とします。そのユーザーが1つのレルムで認証する際にこの権限を持っていない場合、別のレルムで認証している間はAPIキーを管理できません。

レルム間のロール管理

Elasticsearchは、レルム間でロールを一貫して適用するための複数の方法を提供します。たとえば、authorization delegation を使用して、ユーザーが複数のレルムから同じロールを割り当てられるようにすることができます。また、同じディレクトリサービスをバックにした複数のレルムを手動で構成することもできます。異なるレルムで認証する際に同じユーザーに対して異なる roles を構成することは可能ですが、推奨されません

セキュリティドメインの構成


セキュリティドメインは、慎重な構成を必要とする高度な機能です。誤った構成や誤用は、予期しない動作を引き起こす可能性があります。

セキュリティドメインは、クラスター内のすべてのノードで一貫して構成する必要があります。不一致の構成は、次のような問題を引き起こす可能性があります:

  • 重複したユーザープロファイル
  • 認証ノードの構成に応じたリソースの異なる所有権

セキュリティドメインを構成するには:

  • 1. elasticsearch.yml 名前空間の xpack.security.authc.domains にセキュリティドメイン構成を追加します:

Yaml

  1. xpack:
  2. security:
  3. authc:
  4. domains:
  5. my_domain:
  6. realms: [ 'default_native', 'saml1' ]
この構成は、my_domain というセキュリティドメインを定義し、default_nativesaml1 という2つのレルムを含みます。

指定されたレルムは elasticsearch.yml で定義する必要がありますが、有効にする必要はありません。
file realmnative realm は、明示的な構成なしにそれぞれ default_filedefault_native として自動的に有効になります。これらのレルムは、elasticsearch.yml で明示的に定義されていなくても、ドメインの下にリストできます。

  • 2. Elasticsearchを再起動します。
    ドメイン構成が無効な場合、Elasticsearchは起動に失敗する可能性があります。たとえば:
    • 同じレルムが複数のドメインの下に構成されている。
    • 未定義のレルム、合成レルム、または予約されたレルムがドメインの下に構成されている。
  • 3. セキュリティドメインに関連する操作を実行する前に、クラスター内のすべてのノードに同じ構成を適用します。これには、user profilesAPI keys、および async search などのリソースの作成と管理が含まれます。
    セキュリティドメインにレルムを追加する際は、変更がすべてのノードに完全に適用されるまで、新しく追加されたレルムで認証することを避けてください。

セキュリティドメインからのレルムの削除

セキュリティドメインからレルムを削除すると、予期しない動作を引き起こす可能性があり、推奨されません。削除前に作成または更新されたリソースは、リソースタイプに応じて異なるユーザーによって所有される可能性があります:

  • User profiles は、最後に activated されたユーザーによって所有されます。所有者ユーザーと同じドメインにないレルムのユーザーの場合、次回ユーザープロファイルAPIが呼び出されると、新しいユーザープロファイルが作成されます。
  • APIキーは、元々 created したユーザーまたは最後に updated したユーザーによって所有されます。APIキーの元の作成者を含むユーザーは、現在のAPIキー所有者のドメインにない場合、所有権を失います。
  • 非同期検索コンテキストなどのリソースは、元々それらを作成したユーザーによって所有されます。

レルムを削除する代わりに、それらを無効にしてセキュリティドメインの一部として保持することを検討してください。すべての状況において、レルム間のリソース共有は、同じユーザー名を持つユーザー間でのみ可能です。