コラボレーションは OpenSearch の中核です。チームは、ダッシュボードやビジュアライゼーションなどのアーティファクト、さらにはレポート、機械学習 (ML) モデル、異常検出器などのプラグイン定義リソースを、ユーザーやロール間で共有する必要があることがよくあります。同時に、管理者はアクセスが制御され、監査可能で、より広範なセキュリティポリシーと一貫していることを確認する必要があります。
OpenSearch 3.3 から、Security プラグインはリソース共有とアクセス制御を導入しました。これは、ユーザーが他のユーザーやロールとリソースを共有しながら、きめ細かいアクセスルールを適用できるフレームワークです。このモデルは、プラグインによって定義された上位レベルのオブジェクトにリソースレベルの認可をもたらし、OpenSearch 全体で一貫したコラボレーション体験を実現します。
リソース共有とアクセス制御が重要な理由
従来のロールベースのアクセス制御は、誰がインデックスをクエリしたりクラスターを管理したりできるかを定義しますが、ML モデル、レポート定義、異常検出器などの上位レベルのオブジェクトを共有するためのネイティブメカニズムは提供していません。
重複を避け、一貫性を確保し、コラボレーションを効率化するために、チーム間で上位レベルのオブジェクトを共有する必要がある場合があります。例えば以下のようなケースです。
- 中央データチームが週次のコンプライアンスレポートをスケジュールするレポート定義を作成する場合。他のチームは、それを複製することなく、このレポートを表示して実行する必要があります。
- 不正分析チームがトランザクションデータの異常検出器を定義する場合。セキュリティエンジニアは、アラートを構築したり監視を統合したりするために、検出器の設定を表示する必要があるかもしれません。
- データサイエンティストが ML Commons モデルをトレーニングし、再構築やエクスポートなしで部門間で共有したい場合。
リソース共有とアクセス制御は、これらのリソースをきめ細かい制御で所有、共有、監査できるようにすることで、欠けていたレイヤーを提供します。
主要な概念
リソース共有を効果的に使用するには、リソースがどのように管理され、アクセスされるかを定義する主要な概念を理解することが重要です。
- リソース: レポート定義、異常検出器、ML モデルなど、OpenSearch プラグインによって管理される上位レベルのオブジェクト。
- 所有権: すべてのリソースには所有者 (通常は作成者) がおり、リソースをどのように、誰と共有するかを決定できます。
- 共有ターゲット: リソースは特定のユーザーまたはロールと共有できます。
- アクセスレベル: アクセスレベル (アクショングループとも呼ばれる) は、ユーザーまたはロールがリソースに対して実行できる特定のアクションを定義します。
- 監査可能性: すべての共有操作は、透明性とコンプライアンスのためにログに記録されます。
レガシーアクセス制御モデル
歴史的に、多くの OpenSearch プラグインは、プラグイン定義リソースへのアクセスを制御するために、粗いバックエンドロールベースのモデルに依存してきました。このモデル (一般的に filter_by_backend_role と呼ばれる) では、あるユーザーが作成したリソースは、両方のユーザーが少なくとも 1 つのバックエンドロールを共有している場合にのみ、別のユーザーに表示されます。実際には、2 人のユーザーがバックエンドロールを共有すると、意図に関係なく、お互いのリソースに自動的にアクセスできるようになり、リソース所有者は誰がそれらのリソースを表示、変更、または使用できるかを制御できません。
このモデルにはいくつかの制限があります。
- 所有者が制御する共有がない: アクセスは自動的かつ暗黙的です。2 人のユーザーがバックエンドロールを共有すると、意図に関係なく、お互いの検出器、モデル、その他のリソースが表示されます。
- 過度に広いクラスター権限: 権限はリソースベースではなくロールベースであるため、管理者は単一のリソースのみに関係する操作を許可するために、大きなクラスターレベルの権限を付与する必要があります。
- ユーザー ID スナップショットの保存: プラグインは各リソースと一緒に ID メタデータを永続化する必要があり、これにより複雑さが増し、リソースメタデータがユーザーライフサイクルと密接に結合されます。
Anomaly Detection プラグインでは、このモデルを制御する設定は plugins.anomaly_detection.filter_by_backend_roles です。ML Commons プラグインでは、この設定は plugins.ml_commons.model_access_control_enabled です。
アクセスレベル
アクセスレベルは、単一のリソースに適用可能な権限のグループです。共有可能なリソースを作成する各プラグインは、共有可能なリソースに関連付けられたアクセスレベルのリストを指定する必要があります。アクセスレベルは、ユーザーがリソースに対して実行できるアクションを定義し、各レベルが上がるにつれて追加の機能が付与されます。
アクセスレベルの良いメンタルモデルは、おなじみの Google ドキュメントの共有モデルです。Google ドキュメントの所有者は、以下のレベルでドキュメントを共有できます。
- 閲覧者: 閲覧者レベルのユーザーはドキュメントを読むことができます。
- コメント投稿者: コメント投稿者レベルのユーザーはドキュメントを読み、コメントを残すことができます。
- 編集者: 編集者はドキュメントを読み、コメントし、編集できます。
- フルアクセス: フルアクセスを持つユーザーは、ドキュメントを読み、編集し、コメントし、共有できます。
API ウォークスルー
REST API を使用してリソース共有を管理できます。以下の例は、リソースの共有、ステータスの表示、アクセス権を持つユーザーの更新などの一般的な操作を示しています。これらの API は、Anomaly Detection や ML Commons などのサポートされているプラグイン全体で機能します。
1. リソースを共有する
PUT /_plugins/_security/api/resource/share
{
"resource_id": "resource-123",
"resource_type": "my-type",
"share_with": {
"read_only": {
"users": ["alice"],
"roles": ["readers"]
},
"read_write": {
"users": ["bob"]
}
}
}
2. 共有ステータスを確認する
GET /_plugins/_security/api/resource/share?resource_id=<id>&resource_type=<type>
レスポンス:
{
"sharing_info": {
"resource_id": "resource-123",
"created_by": { "username": "admin" },
"share_with": {
"read_only": {
"users": ["alice"],
"roles": ["readers"]
},
"read_write": {
"users": ["bob"]
}
}
}
}
3. 共有をパッチする (追加または取り消し)
PATCH /_plugins/_security/api/resource/share
{
"resource_id": "resource-123",
"resource_type": "my-type",
"add": {
"read_only": {
"users": ["charlie"]
}
},
"revoke": {
"read_only": {
"users": ["alice"]
},
"read_write": {
"users": ["bob"]
}
}
}
クラスター設定
クラスター設定を使用してリソース共有を有効にできます。
OpenSearch 3.3 では、opensearch.yml を更新してクラスターを再起動することでのみリソース共有設定を変更できます。
plugins.security.experimental.resource_sharing.enabled: true
plugins.security.experimental.resource_sharing.protected_types: ["anomaly-detector", "forecaster", "ml-model"]
OpenSearch 3.4 以降では、これらの設定は _cluster/settings API を使用して実行時に動的に更新できるようになります。
PUT _cluster/settings
{
"persistent": {
"plugins.security.experimental.resource_sharing.enabled": "true",
"plugins.security.experimental.resource_sharing.protected_types": [
"anomaly-detector",
"forecaster",
"ml-model"
]
}
}
plugins.security.experimental.resource_sharing.enabled はリソース共有をグローバルに有効または無効にします。plugins.security.experimental.resource_sharing.protected_types は、機能が有効な場合にリソースレベルの認可を使用するリソースタイプをマークします。
デフォルトでは、管理者が意図的にオプトインできるように、リソース共有は無効になっています。
現在のプラグインサポート
リソース共有の初期サポートは、以下のプラグインで利用可能です。
- Anomaly Detection: ユーザー間で検出器と予測器を共有します。
- ML Commons: 重複なしでチーム間でトレーニング済みモデルを共有します。
Reporting を含む追加のプラグインは、将来のリリースでこのフレームワークを採用する予定です。
マイグレーション API
既存のリソースを持つクラスターの場合、Security プラグインは、レガシーのバックエンドロールベースの可視性から新しい所有者ベースのモデルへの移行を支援するマイグレーション API を提供します。可能な場合、マイグレーションプロセスは username_path と backend_roles_path を使用して、既存のメタデータから所有権とアクセスデータを抽出します。所有権を特定できない場合は、リソースの default_owner を指定する必要があります。
マイグレーション後、所有者は OpenSearch Dashboards の Resource Access Control ページを使用して共有を管理できます。
POST /_plugins/_security/api/resources/migrate
{
"source_index": ".sample_resource",
"username_path": "/owner",
"backend_roles_path": "/backend_roles",
"default_access_level": {
"sample-resource": "read_only",
"sample-resource-group": "read-only-group"
}
}
ベストプラクティス
OpenSearch クラスターでリソース共有を実装する際は、安全で効果的なコラボレーションを確保するために、以下の推奨事項を検討してください。
- 慎重に有効化する: 本番クラスター全体でリソース共有を有効にする前に、ステージング環境でテストしてください。
- 最小権限モデルに従う: 必要最小限のアクセスレベルでリソースを共有してください。
今後の予定
追加のプラグインがこのフレームワークを採用するにつれて、ユーザーは OpenSearch 体験全体で一貫した、安全で、予測可能なコラボレーション方法を得ることができます。プラグイン開発者は、よりシンプルなセキュリティ統合とカスタムアクセスチェックへの依存度の低減から恩恵を受けます。
Dashboards、Visualizations、Reporting プラグインがリソース共有モデルを採用するにつれて、ユーザーは OpenSearch 全体で統一されたコラボレーションフレンドリーな共有モデルを得ることができます。
このブログ記事のパート 2 にご期待ください。パート 2 では、基盤となるメタデータモデルをレビューし、クエリ時にアクセス評価がどのように機能するかを探り、フレームワークを形作るスケーラビリティの考慮事項について説明します。
まとめ
OpenSearch 3.3 でのリソース共有とアクセス制御の導入により、チームはより高い柔軟性とセキュリティで上位レベルのリソースに対してコラボレーションできるようになりました。レポート定義、異常検出器、ML モデルを管理する場合でも、同僚やチームと安全に共有できるようになりました。
クラスター設定で有効にして API を探索することで、今日からこの機能を試すことができます。Anomaly Detection または ML Commons プラグインを使用している場合は、検出器またはモデルを共有して、このフレームワークが環境でのコラボレーションとセキュリティをどのように簡素化するかを確認してください。
OpenSearch Project(OSS) の Publicationです。 OpenSearch Tokyo User Group : meetup.com/opensearch-project-tokyo/
Discussion