Amazon OpenSearch Service での Identity and Access Management - Amazon OpenSearch Service

Amazon OpenSearch Service での Identity and Access Management

Amazon OpenSearch Service には、ドメインへのアクセスを制御するいくつかの方法が用意されています。このトピックでは、さまざまなポリシータイプ、それぞれがやり取りする方法、および独自のカスタムポリシーを作成する方法を説明します。

重要

VPC は OpenSearch Service のアクセス制御へのいくつかの追加考慮事項の導入をサポートしています。詳細については、「VPC ドメインのアクセスポリシーについて」を参照してください。

ポリシーのタイプ

OpenSearch Service はアクセスポリシーの 3 つのタイプをサポートしています。

リソースベースのポリシー

ドメインを作成するときに、ドメインアクセスポリシーと呼ばれる場合があるリソースベースのポリシーを追加します。これらのポリシーは、ドメインのサブリソースでプリンシパルが実行するアクションを指定します (cross-cluster 検索を除く)。サブリソースには、OpenSearch インデックスおよび API が含まれます。Principal 要素は、アクセスを許可するアカウント、ユーザー、またはロールを指定します。Resource 要素は、これらのプリンシパルがアクセスできるサブリソースを指定します。

次のリソースベースのポリシーは、test-user フルアクセス (es:*) を test-domain のサブリソースに付与します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }

このポリシーには、2 つの重要な考慮事項が適用されます。

  • これらの権限はこのドメインのみに適用されます。他のドメインで同様のポリシーを作成しない限り、test-usertest-domain にしかアクセスできません。

  • Resource 要素の末尾の /* は重要であり、リソースベースのポリシーがドメイン自体ではなく、ドメインのサブリソースにのみ適用されることを示します。リソースベースのポリシーでは、es:* アクションは es:ESHttp* と同等です。

    例えば、test-user はインデックス (GET https://search-test-domain.us-west-1.es.amazonaws.com/test-index) に対してリクエストを行うことができますが、ドメインの設定を更新できません (POST https://es.us-west-1.amazonaws.com/2021-01-01/opensearch/domain/test-domain/config)。2 つのエンドポイント間の違いに注目してください。設定 API へのアクセスには、ID ベースのポリシーが必要です。

ワイルドカードを追加することで、インデックス名の一部を指定できます。これにより、commerce で始まるすべてのインデックスを識別します。

arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce*

この場合、このワイルドカードを使用して指定すると、test-user は、commerce で始まる名前を持つ test-domain ドメインのインデックスにリクエストを送信できます。

test-user をさらに制限するには、次のポリシーを適用することができます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/_search" } ] }

これにより、test-usercommerce-data インデックスに対する検索で、1 つのオペレーションのみを実行できます。ドメインのその他すべてのインデックスはアクセス不可となり、、test-user は、es:ESHttpPut または es:ESHttpPost アクションを使用する許可なしにドキュメントを追加あるいは変更できなくなります。

次に、パワーユーザーのロールを設定することができます。このポリシーは、power-user-role にインデックスのすべての URI に対する HTTP GET メソッドおよび PUT メソッドへのアクセスを付与します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:role/power-user-role" ] }, "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/commerce-data/*" } ] }

ドメインが VPC 内にあるか、きめ細かなアクセスコントロールを使用している場合は、オープンドメインアクセスポリシーを使用できます。それ以外の場合、ドメインアクセスポリシーには、プリンシパルまたは IP アドレスによる制限が含まれている必要があります。

使用できるすべてのアクションの詳細については、「ポリシーエレメントのリファレンス」を参照してください。データをより細かく制御するには、きめ細かなアクセスコントロールとともにオープンドメインアクセスポリシーを使用します。

アイデンティティベースのポリシー

各 OpenSearch Service ドメインの一部であるリソースベースのポリシーとは異なり、アイデンティティベースのポリシーは AWS Identity and Access Management (IAM) サービスを使用してユーザーやロールにアタッチします。リソースベースのポリシーと同様に、アイデンティティベースのポリシーは、サービスに誰がアクセスできるか、どのアクションキーを実行できるか、そして該当する場合には、これらのアクションを実行できるリソースを指定します。

これらを実行する実際の義務はないため、アイデンティティベースのポリシーはより一般的になる傾向があります。これにより、多くの場合、ユーザーが実行できる設定 API アクションのみ管理されます。これらのポリシーの配置が完了したら、OpenSearch Service でリソースベースのポリシー (またはきめ細かなアクセスコントロール) を使用して、OpenSearch インデックスおよび API へのアクセスをユーザーに提供できます。

注記

AWS 管理の AmazonOpenSearchServiceReadOnlyAccess ポリシーが適用されたユーザーは、コンソールでクラスターのヘルスステータスを確認できません。これらのユーザーがヘルスステータス (および他の OpenSearch データ) を確認できるようにするには、アクセスポリシーに es:ESHttpGet アクションを追加し、これをユーザーのアカウントまたはロールにアタッチします。

アイデンティティベースのポリシーはユーザーあるいはロール (プリンシパル) にアタッチされるため、JSON はプリンシパルを指定しません。次のポリシーは、Describe および List で始まるアクションへのアクセスを付与します。このアクションの組み合わせはドメインの設定への読み取り専用のアクセスを提供しますが、ドメイン自体に保存されたデータへのアクセスは提供しません。

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:Describe*", "es:List*" ], "Effect": "Allow", "Resource": "*" } ] }

管理者には、OpenSearch Service およびすべてのドメインに保存された全データへのフルアクセス権がある場合があります。

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "es:*" ], "Effect": "Allow", "Resource": "*" } ] }

ID ベースのポリシーでは、タグを使用して設定 API へのアクセスを制御できます。例えば、次のポリシーでは、ドメインに team:devops タグがある場合、アタッチされたプリンシパルがドメインの設定を表示および更新できるようにします。

{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:UpdateDomainConfig", "es:DescribeDomain", "es:DescribeDomainConfig" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/team": [ "devops" ] } } }] }

タグを使用して、OpenSearch API へのアクセスを制御することもできます。OpenSearch API のタグベースのポリシーは、HTTP メソッドにのみ適用されます。例えば、次のポリシーでは、ドメインに environment:production タグがある場合、接続されたプリンシパルが GET および PUT リクエストを OpenSearch API に送信できます。

{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:ESHttpGet", "es:ESHttpPut" ], "Effect": "Allow", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] }

OpenSearch API をよりきめ細かく制御するには、きめ細かいアクセス制御 の使用を検討してください。

注記

1 つ以上の OpenSearch API をタグベースのポリシーに追加した後、変更をドメインで有効にするには、単一の タグオペレーション (タグの追加、削除、変更など) を実行する必要があります。タグベースのポリシーに OpenSearch API オペレーションを含めるには、サービスソフトウェア R20211203 以降を使用している必要があります。

OpenSearch サービスは、OpenSearch API ではなく、設定 API の RequestTag および TagKeys グローバル条件キーをサポートします。これらの条件は、リクエスト内にタグを含む API 呼び出し (CreateDomainAddTags、および RemoveTags など) にのみ適用されます。次のポリシーでは、アタッチされたプリンシパルがドメインを作成できるようにしますが、それは、team:it タグをリクエストに含めた場合のみです。

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "es:CreateDomain", "es:AddTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/team": [ "it" ] } } } }

アクセス制御でタグを使用する方法とリソースベースのポリシーとアイデンティティベースのポリシーの違いについての詳細は、「IAM ユーザーガイド」を参照してください。

IP ベースのポリシー

IP ベースのポリシーは、1 つ以上の IP アドレスあるいは CIDR ブロックにドメインへのアクセスを制限します。技術的には、IP ベースのポリシーは異なるタイプのポリシーではありません。代わりに、これらのポリシーは、匿名のプリンシパルを指定し、特別な Condition 要素を含む、リソースベースのポリシーです。

IP ベースのポリシーの最大の特徴は、OpenSearch Service ドメインへの署名なしのリクエストを許可することです。これにより、curlOpenSearch Dashboards などのクライアントを使用したり、プロキシサーバーを介してドメインにアクセスしたりすることができます。詳細については、「プロキシを使用して Dashboards から OpenSearch Service にアクセスする」を参照してください。

注記

ドメインで VPC アクセスを有効にすると、IP ベースのポリシーを設定することはできません。代わりに、どの IP アドレスがドメインにアクセスできるかを制御するセキュリティグループを使用できます。詳細については、「VPC ドメインのアクセスポリシーについて」を参照してください。

以下のポリシーは、指定された IP 範囲からのすべての HTTP リクエストが test-domain にアクセスする許可を付与します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" } ] }

ドメインにパブリックエンドポイントがあり、きめ細かなアクセスコントロールを使用しない場合は、IAM プリンシパルと IP アドレスを組み合わせることをお勧めします。このポリシーでは、指定した IP 範囲からのリクエストの場合にのみ、test-user HTTP アクセスを許可します。

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::987654321098:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24" ] } }, "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }] }

OpenSearch Service リクエストの作成と署名

完全にオープンなリソースベースのポリシーを設定する場合、OpenSearch Service 設定 API へのすべてのリクエストは署名付きである必要があります。ポリシーで IAM ユーザーまたはロールを指定している場合、OpenSearch API へのリクエストが AWS 署名バージョン 4 を使用して署名されていることも必要です。署名メソッドは API によって異なります。

  • OpenSearch Service 設定 API 呼び出しを行うには、AWS SDK のいずれかを使用することが推奨されます。SDK を使用するほうが、独自のリクエストを作成し署名するよりも、プロセスが簡素化し、大幅な時間の節約ができます。API エンドポイント設定には次の形式を使用します。

    es.region.amazonaws.com/2021-01-01/

    例えば、次のリクエストは、movies ドメインの設定を変更しますが、自分で署名する必要があります (お勧めしません)。

    POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/movies/config { "ClusterConfig": { "InstanceType": "c5.xlarge.search" } }

    Boto 3 などのいずれかの SDK を使用する場合、SDK はリクエスト署名を自動的に処理します。

    import boto3 client = boto3.client(es) response = client.update_domain_config( DomainName='movies', ClusterConfig={ 'InstanceType': 'c5.xlarge.search' } )

    Java コードの例については、「Amazon OpenSearch Service を操作するための AWS SDKの使用」を参照してください。

  • OpenSearch API への呼び出しを行うには、独自リクエストに署名する必要があります。各種言語のサンプルコードについては、「Amazon OpenSearch Service への HTTP リクエストの署名」を参照してください。OpenSearch API は、次の形式を使用します。

    domain-id.region.es.amazonaws.com

    例えば、次のリクエストは、thormovies インデックスを検索します。

    GET https://my-domain.us-east-1.es.amazonaws.com/movies/_search?q=thor
注記

このサービスは、署名バージョン 4 で署名された HTTP POST リクエストの URL で渡されるパラメータを無視します。

複数のポリシーが衝突する場合

複数のポリシーが同意しない、あるいはユーザーを明示的に指定しない場合、困難が生じます。IAM ユーザーガイドの「IAM の詳細を理解する」では、ポリシーの評価ロジックの適切な概要が説明されています。

  • デフォルトでは、すべてのリクエストが拒否されます。

  • 明示的な許可はこのデフォルトに優先します。

  • 明示的な拒否はすべての許可に上書きされます。

例えば、リソースベースのポリシーがドメインサブリソース (OpenSearch インデックスまたは API) にアクセスを許可しているが、アイデンティティベースのポリシーはアクセスを拒否するため、アクセスは拒否されます。アイデンティティベースのポリシーとリソースベースのポリシーによってユーザーがアクセス許可を持つべきかを指定いない場合、アクセスは許可されます。ドメインサブリソースのすべての結果の概要における交差するポリシーの図を以下で参照してください。

リソースベースのポリシーで許可 リソースベースのポリシーで拒否 リソースベースのポリシーで許可あるいは拒否されない
Allowed in identity-based policy

許可

Deny Allow
Denied in identity-based policy Deny Deny Deny
Neither allowed nor denied in identity-based policy Allow Deny Deny

ポリシーエレメントのリファレンス

OpenSearch Service では、「IAM ポリシーエレメントのリファレンス」のほとんどのポリシー要素がサポートされています (NotPrincipal は除く)。次の表は、最も一般的なエレメントを示しています。

JSON ポリシーエレメント 概要
Version

ポリシー言語の最新バージョンは 2012-10-17 です。すべてのアクセスポリシーでこの値を指定する必要があります。

Effect

このエレメントは、指定されたアクションへのアクセスをステートメントが許可するか拒否するかを指定します。有効な値は Allow または Deny です。

Principal

この要素は、リソースへのアクセスを許可する AWS アカウント、あるいは IAM ユーザーまたはロールを指定し、いくつかの形式を取ることができます。

  • AWS アカウント: "Principal":{"AWS": ["123456789012"]} または "Principal":{"AWS": ["arn:aws:iam::123456789012:root"]}

  • IAM ユーザー: "Principal":{"AWS": ["arn:aws:iam::123456789012:user/test-user"]}

  • IAM ロール: "Principal":{"AWS": ["arn:aws:iam::123456789012:role/test-role"]}

* ワイルドカードを指定すると、ドメインへの匿名アクセスが有効になります。これは IP ベースの条件を追加する、VPC サポートを使用する、またはきめ細かなアクセスコントロールを有効にしない限り、お勧めしません。

Action

OpenSearch Service は、OpenSearch HTTP メソッドに対して次のアクションを使用します。

  • es:ESHttpDelete

  • es:ESHttpGet

  • es:ESHttpHead

  • es:ESHttpPost

  • es:ESHttpPut

  • es:ESHttpPatch

OpenSearch Service では、設定 API として次のアクションを使用します。

  • es:AcceptInboundConnection

  • es:AddTags

  • es:AssociatePackage

  • es:CancelServiceSoftwareUpdate

  • es:CreateOutboundConnection

  • es:CreateDomain

  • es:CreatePackage

  • es:CreateServiceRole

  • es:DeleteDomain

  • es:DeleteInboundConnection

  • es:DeleteOutboundConnection

  • es:DeletePackage

  • es:DescribeDomain

  • es:DescribeDomains

  • es:DescribeDomainAutoTunes

  • es:DescribeDomainConfig

  • es:DescribeInboundConnections

  • es:DescribeInstanceTypeLimits

  • es:DescribeOutboundConnections

  • es:DescribePackages

  • es:DescribeReservedInstanceOfferings

  • es:DescribeReservedInstances

  • es:DissociatePackage

  • es:ESCrossClusterGet

  • es:GetCompatibleVersions

  • es:GetPackageVersionHistory

  • es:GetUpgradeHistory

  • es:GetUpgradeStatus

  • es:ListDomainNames

  • es:ListDomainsForPackage

  • es:ListInstanceTypeDetails

  • es:ListInstanceTypes

  • es:ListNotifications

  • es:ListPackagesForDomain

  • es:ListVersions

  • es:ListTags

  • es:PurchaseReservedInstanceOffering

  • es:RemoveTags

  • es:RejectInboundConnection

  • es:StartServiceSoftwareUpdate

  • es:UpdateDomainConfig

  • es:UpdateNotificationStatus

  • es:UpdatePackage

  • es:UpgradeDomain

ヒント

ワイルドカードを使用してアクションのサブネットを指定できます ("Action":"es:*""Action":"es:Describe*" など)。

特定の es: アクションは、リソースレベルの許可をサポートします。例えば、すべてのドメインを削除する許可を付与せずに、1 つの特定のドメインのみ削除する許可をユーザーに付与することができます。その他のアクションはサービス自体に適用されます。例えば、es:ListDomainNames は単一ドメインのコンテキストでは意味を成しませんが、それでもワイルドカードを必要とします。

重要

リソースベースのポリシーは、リソースレベルのアクセス権限とは異なっています。リソースベースのポリシー は、ドメインにアタッチする完全な JSON ポリシーです。リソースレベルのアクセス許可は、特定のドメインあるいはサブリソースにアクションを制限します。実際には、リソースレベルのアクセス許可はリソース、あるいはアイデンティティベースのポリシーのオプションの一部として捉えることができます。

次のアイデンティティベースのポリシーはすべての es: アクションを一覧表示し、ドメインのサブリソース (test-domain/*)、ドメインの設定 (test-domain)、あるいはサービスのみ (*) に適用されるかによってアクションをグループ化します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpDelete", "es:ESHttpGet", "es:ESHttpHead", "es:ESHttpPost", "es:ESHttpPut", "es:ESHttpPatch" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }, { "Effect": "Allow", "Action": [ "es:AddTags", "es:AssociatePackage", "es:CreateDomain", "es:CreateOutboundConnection", "es:DeleteDomain", "es:DescribeDomain", "es:DescribeDomainAutoTunes", "es:DescribeDomainConfig", "es:DescribeDomains", "es:DissociatePackage", "es:ESCrossClusterGet", "es:GetCompatibleVersions", "es:GetUpgradeHistory", "es:GetUpgradeStatus", "es:ListPackagesForDomain", "es:ListTags", "es:RemoveTags", "es:StartServiceSoftwareUpdate", "es:UpdateDomainConfig", "es:UpdateNotificationStatus", "es:UpgradeDomain" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain" }, { "Effect": "Allow", "Action": [ "es:AcceptInboundConnection", "es:CancelServiceSoftwareUpdate", "es:CreatePackage", "es:CreateServiceRole", "es:DeletePackage", "es:DescribeInboundConnections", "es:DescribeInstanceTypeLimits", "es:DescribeOutboundConnections", "es:DescribePackages", "es:DescribeReservedInstanceOfferings", "es:DescribeReservedInstances", "es:GetPackageVersionHistory", "es:ListDomainNames", "es:ListDomainsForPackage", "es:ListInstanceTypeDetails", "es:ListInstanceTypes", "es:ListNotifications", "es:ListVersions", "es:PurchaseReservedInstanceOffering", "es:RejectInboundConnection", "es:UpdatePackage" ], "Resource": "*" } ] }
注記

es:CreateDomain へのリソースレベルのアクセス権限は直観的ではないように見えることがあります。(つまり、すでに存在するドメインを作成するアクセス権限をなぜユーザーに付与するのでしょうか?) ワイルドカードの使用でドメインに簡単な命名スキームを適用できます ("Resource": "arn:aws:es:us-west-1:987654321098:domain/my-team-name-*" など)。

もちろん、次のように、制限がより緩和されたリソース要素のアクションを含めることもできます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "es:ESHttpGet", "es:DescribeDomain" ], "Resource": "*" } ] }

アクションとリソースのペアリングについての詳細は、テーブルの Resource 要素を参照してください。

Condition

OpenSearch Service は、IAM ユーザーガイドの「AWS グローバル条件コンテキストキー」に記載されているほとんどの条件をサポートします。注目すべき例外には、aws:SecureTransport および aws:PrincipalTag キーがあり、OpenSearch Service はこれらをサポートしていません。

IP ベースのポリシーを設定する場合、次に示すように、IP アドレスまたは CIDR ブロックを条件として指定します。

"Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/32" ] } }

アイデンティティベースのポリシー に記載されているように、aws:ResourceTagaws:RequestTag、および aws:TagKeys 条件キーは、設定 API と OpenSearch API に適用されます。

Resource

OpenSearch サービスは、3 つの基本的な方法で Resource エレメントを使用します。

  • es:ListDomainNames やフルアクセスを許可するといった、OpenSearch Service 自体に適用されるアクションには、次の構文を使用します。

    "Resource": "*"
  • es:DescribeDomain のように、ドメインの設定に関連するアクションには、次の構文を使用します。

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name"
  • es:ESHttpGet のように、ドメインのサブリソースを適用するアクションには、次の構文を使用します。

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/*"

    ワイルドカードを使用する必要はありません。OpenSearch Service は、各 OpenSearch インデックスまたは API に異なるアクセスポリシーを定義します。例えば、test-index インデックスへのユーザーのアクセス許可を制限できます。

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index"

    test-index へのフルアクセスの代わりに、検索 API のみにポリシーを制限することもできます。

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/_search"

    個々のドキュメントへのアクセスを制御することもできます。

    "Resource": "arn:aws:es:region:aws-account-id:domain/domain-name/test-index/test-type/1"

    基本的に、OpenSearch によってサブリソースが URI として表現される場合、アクセスポリシーを使用してサブリソースへのアクセスをコントロールできます。どのリソースにユーザーがアクセスできるかをさらに細かく制御するには、「Amazon OpenSearch Service のきめ細かなアクセスコントロール」を参照してください。

どのアクションがリソースレベルのアクセス権限をサポートするかの詳細については、このテーブルの Action 要素を参照してください。

詳細オプションと API に関する考慮事項

OpenSearch Service にはいくつかの詳細オプションがあり、その 1 つにはアクセスコントロールが関連します (rest.action.multi.allow_explicit_index)。デフォルト設定の true では、特定の状況下でユーザーがサブリソースへのアクセス権限を回避することが許可されます。

例えば、次のリソースベースのポリシーを考えます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttp*" ], "Resource": [ "arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*", "arn:aws:es:us-west-1:987654321098:domain/test-domain/_bulk" ] }, { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::123456789012:user/test-user" ] }, "Action": [ "es:ESHttpGet" ], "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }

このポリシーは、test-usertest-index および OpenSearch バルク API へのフルアクセスを付与します。また、GET への restricted-index リクエストを許可します。

次のインデックスリクエストは、見てわかるように、アクセス権限エラーによって失敗します。

PUT https://search-test-domain.us-west-1.es.amazonaws.com/restricted-index/movie/1 { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }

インデックス API とは異なり、バルク API では、単一の呼び出しで多くのドキュメントの作成、更新、削除を実行できます。多くの場合、これらのオペレーションはリクエスト URL ではなく、リクエストの本文で指定します。OpenSearch Service が URL を使用してドメインサブリソースへのアクセスを制御するため、test-user は、結果的にバルク API を使用して restricted-index に変更を加えることができます。ユーザーにはインデックスで POST アクセス権限が欠如していますが、次のリクエストは成功します。

POST https://search-test-domain.us-west-1.es.amazonaws.com/_bulk { "index" : { "_index": "restricted-index", "_type" : "movie", "_id" : "1" } } { "title": "Your Name", "director": "Makoto Shinkai", "year": "2016" }

このような状況では、アクセスポリシーはその目的達成に失敗します。ユーザーがこれらの制限を回避することを防ぐためには、rest.action.multi.allow_explicit_index を false に変更できます。この値が false の場合、リクエストボディでインデックス名を指定するバルク、mget、および msearch API へのすべての呼び出し動作は停止します。つまり、_bulk への呼び出しは機能しなくなりますが、test-index/_bulk への呼び出しは動作します。この 2 番目のエンドポイントにはインデックス名が含まれるため、リクエストボディにそれを指定する必要はありません。

OpenSearch Dashboards は mget および msearch に大きく依存しています。そのため、この変更後には正常に動作しないことが予想されます。部分的な解決策としては、rest.action.multi.allow_explicit_index を true のまま残して、特定のユーザーが 1 つ以上の API にアクセスすることを拒否します。

この設定の変更については、「高度なクラスター設定」を参照してください。

同様に、以下のリソースベースのポリシーには 2 つの小さな問題があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/*" }, { "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/test-user" }, "Action": "es:ESHttp*", "Resource": "arn:aws:es:us-west-1:987654321098:domain/test-domain/restricted-index/*" } ] }
  • 明示的な拒否にも関わらず、test-userGET https://search-test-domain.us-west-1.es.amazonaws.com/_all/_searchGET https://search-test-domain.us-west-1.es.amazonaws.com/*/_search などの呼び出しを実行して、restricted-index のドキュメントにアクセスできることです。

  • Resource エレメントレファレンス restricted-index/* により、test-user はインデックスのドキュメントに直接アクセスする権限がありません。しかし、ユーザーにはインデックス全体を削除する権限があります。アクセスと削除を防ぐには、このポリシーで restricted-index* を指定する必要があります。

広範囲な許可と一部の拒否を混合するよりは、最小限の権限の原則を守り、タスクを実行するために必要なアクセス権限のみを付与することが最も安全なアプローチです。個々のインデックスまたは OpenSearch オペレーションに対するアクセスコントロールの詳細については、Amazon OpenSearch Service のきめ細かなアクセスコントロール を参照してください。

アクセスポリシーの設定

  • リソースの作成あるいは変更、そして OpenSearch Service の IP ベースのポリシーに関する説明は、「アクセスポリシーの設定」を参照してください。

  • IAM でアイデンティティベースのポリシーを作成または変更する方法については、IAM ユーザーガイドの「IAM ポリシーの作成」を参照してください 。

追加のサンプルポリシー

この章には多くのサンプルポリシーが含まれていますが、AWS アクセスコントロールは複雑なテーマであり、例を使用することが一番の理解方法です。詳細については、IAM ユーザーガイドの「IAM アイデンティティベースのポリシーの例」を参照してください。