[memo] Amazon OpenSearch (security configuration)

doc: https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html

3要素

Network ... N/W レイヤの制限
Domain access policy ... ES における操作（メソッド）の許可をリソースベースで制御。IAM ポリシーの構文
FGAC (Fine grained access control)

Domain レベルのポリシーは、リクエストを受け付けた段階で判定。裏の ES にリーチする前 (domain edge) に accept/rejetct を判断する。このレベルのセキュリティは「リクエストが domain endpoint に到達してもいいかどうか」を制御している と言える

FGAC では、前段 (domain レベル) で対象リソースへのアクセスが許可されていた場合に評価される。

FGAC では、ユーザーが認証している場合は、そのユーザーにマップしている ES ロールを取得して、そのロールの設定に基づいてリクエストの処遇を決定する

以下注意事項

リソースベースのポリシーで IAM user/role を指定している場合は、クライアントはリクエスト時に SigV4 署名しなければならない
（上記のように）アクセスポリシーは FGAC と競合する場合がある。特に、ES 内部の DB（ロールとか）や HTTP Basic を併用している場合など
一般的なケースでは、FGAC を有効化する場合は (SigV4) 署名付きリクエストは不要とするのが推奨

hassaku63

アクセスポリシーの評価フロー。よくあるコンフィグをした場合をケーススタディする

まず、VPC アクセスで、かつ FGAC 有効状態で、IAM ベースのポリシーを設定し IAM のマスターユーザーを作っている場合。

以下は public なドメインで、かつ FGAC が有効、IAM Principal が不使用、マスターユーザーは ES の内部 DB で設定している場合

見た感じ、FGAC までで弾かれてしまった場合は Access denied になり、その後 ES のユーザー DB で弾かれてしまった場合は ES API としてのレスポンスになる感じで、HTTP response code が違ってくるように見える

hassaku63

FGAC

Role という概念を用いる。（IAM のそれとは別物）

Role では ES Cluster/ Index/ Document/ Field レベルのコントロールを任意に組み合わせ可能。

Role は ES ユーザーに紐付け (mapping) することで機能する。

User はアイデンティティの単位（っぽい）。リクエスト時に認証情報を付与する。認証情報とは、例えば IAM のアクセスキーや Id/Password のこと

マスターユーザーの認証方法の選択によって、リクエストに対する認証情報の付与方法が変わってくる。

IAM を選択すると、クラスターに対するすべてのリクエストは SigV4 署名が必要になる。
Internal DB を選択すると、 HTTP Basic （および IAM）を使用してリクエストすることが可能。このとき、認証情報はクラスター内の DB に保持するので、他のクラスターと認証情報を共有することはできない。（つまり、 複数のクラスターを運用したい 場合には IAM ベースの方がユーザーとしての利便性が高い）。ユーザーの使いまわしをしたい場合は Cognito の選択肢がある