はじめに
皆さんこんにちは。いよいよ年の瀬ですね。
今回は、Amazon OpenSearch Serviceのユーザーとロールの設定についてまとめてみようと思います。
ドキュメントにも記載はありますが、初見だとなかなかわかりにくいので、一度図でまとめてみます。
少しネタバレすると、Backend Rolesをうまく使うのがコツです。
前提
Amazon OpenSearch Serviceバージョン1.2での内容になります。
OpenSearch ServerlessやElasticsearch、OSSのOpenSearchでは挙動が異なる場合があるのでご注意ください。
OpenSearchのロールって何？
Amazon OpenSearch Serviceでは、きめ細やかなアクセスコントロール（Fine-grained access control）という機能を用いることで、OpenSearch内でのロールを定義することができます。
このロールは、IAMロールとは異なりますが、イメージは似ています。ロールごとに、読み込みや書き込みなどの許可するアクションなどを定義することができます。
以下が実際のロールのEdit画面です。雰囲気だけつかんでください。
さて、IAMロールでも、そのロール自体に色々なものを紐づけられますよね。（IAMユーザー、SAML認証使ったIdP、Lambda関数などのリソースなど）
同じく、OpenSearchのロールにも色々なものが紐づけられます。
その紐づけを紹介する前に、また実際のスクリーンショットを見てみましょう。
これは、あるロールに何を紐づけるかを設定する画面です。
UsersとBackend rolesという2つの項目があることが分かります。
Backend rolesとは何か？
公式ドキュメントにはこのように記載があります。
バックエンドロールは、ロールをユーザーにマッピングする別の方法です。同じロールを多数の異なるユーザーにマッピングするのではなく、ロールを 1 つのバックエンドロールにマッピングしてから、すべてのユーザーがそのバックエンドロールを持つようにできます。バックエンドロールは、IAM ロールまたは任意の文字列にすることができます。
Backend rolesを使うと、ロールに直接紐づけるのではなく、もう一層Backend rolesを挟んで紐づけることができるようになります。
また、Backend rolesはInternal usersだけでなく、IAMロールやSAML認証の際のIdPにも利用可能です。
Backend rolesを使ってInternal usersとロールを紐づけるときは、以下のスクショのように両者のBackend roleに同じ文字列を入力します。（例ではback-sampleという名前のBackend roleとしています）
Backend roleはどこかでロールのように作成するのではなく、自由に文字列で記載できます。
Internal usersの設定
ロールの設定
ロールと何が紐づけられる？
さて、先ほどロールの紐づけ画面にはUsersとBackend rolesという2つの項目がありました。
それを踏まえて、ロールの紐づけを図にしたものが以下です。
CognitoユーザーやIAMユーザーは、Usersの項目から紐づけます。
IAMロールやIdPは、Backend rolesの項目から紐づけます。
Internal usersは、Usersの項目から直接ロールに紐づけられますし、Backend rolesを介して紐づけることもできます。
では、Internal usersを利用するとき、どのようにロールと紐づけるのが良いでしょうか？
どのようにInternal usersとロールを紐づける？
結論から言うと、
テナントごとに必要なロールを作成して、それをBackend rolesと紐づけて管理しよう
となります。Backend rolesを、ユーザーグループのように使っていきます。
（ちなみに、このユーザーグループのような使い方は、OSSの方のOpenSearchのドキュメントにも記載があります。）
以下の図を用いて詳しく説明します。
テナントとは？
まずは、テナントという概念についてです。
公式ドキュメントには以下のようにあります。
テナントは、インデックスパターン、可視化、ダッシュボード、その他の Dashboards オブジェクトを保存するための領域です。Dashboards マルチテナンシーを使用すると、他の Dashboards ユーザーと作業を安全に共有できます (プライベートに保持できます)。どのロールがテナントにアクセスできるか、それらのロールに読み取りアクセスがあるか書き込みアクセスがあるかを制御できます。グローバルテナントがデフォルトです。詳細については、「OpenSearch Dashboards マルチテナンシー」を参照してください。
つまり、ダッシュボードなどのオブジェクトを分けて管理するときの単位ということになります。
図中だと、tenantAには棒グラフのダッシュボード、tenantBには円グラフのダッシュボードが分けて配置されていますね。
テナントとロールの関係性は？
テナントに関係するのは、ダッシュボードのオブジェクトとロールです。
逆に、Backend rolesやInternal usersはテナントに紐づけられません。
そのため、テナントごとにロールを作成して、それをBackend rolesと紐づけます。
その際、図のRole_allのように、1つのロールを複数のテナントと紐づけることも可能です。
ただ、これをやりすぎると管理が煩雑になるため、管理者権限用のロールだけにしておくことをお勧めします。
なぜBackend rolesを介して紐づけるのか？
Backend rolesを介するということは、ユーザーとロールを直接依存関係にさせないということです。
これにより、以下のようなメリットがあります。
- ユーザーグループごとの権限が変わった場合、Backend rolesを変更すればよい。
- もし直接Internal usersを紐づけていた場合は、その人数分の権限を変更する必要があります。
- 図中にはないですが、Backend rolesから複数のRolesを紐づけることも可能です。
- Internal usersを作成するときに、Rolesのことを考えなくてよい。
- Internal usersを作成するときは、Backend rolesを指定すればよいので、どのRolesを紐づけるか考える必要がありません。
- そのため、ユーザー作成の運用負担が軽減されます。
- IdPとの統合が容易になる。
- IdPを利用する場合は、Backend rolesを介する必要があります。
- その際、既に権限が設定されているBackend roleが存在すれば、Internal usersと同じように権限管理ができます。
- 直接紐づいていた場合、Internal usersとIdPで別々にロールを設定しなければなりません。
おわりに
タイトルのよりも少し広い概念から記載してしまいましたが、具体的な操作の方法というよりは概念的なお話ができて良かったかなと思います。
ただ、最近話題のOpensearch Serverlessでは、ダッシュボードのサインイン方法が「Sign in with your access key and secret key.」とのことなので、Internal usersは使わなくなっていくのかもしれません。
一方で、従来のOpenSearchのクラスタ構築ではこのロールとユーザーの紐づけはかなり使うところだと思うので、今後もこの認証認可周りのところは試していきたいと思います。
特に、Cognito連携やIdP連携は実際に触ってみたいですね。
それでは！