亚马逊 OpenSearch 服务中的身份和访问管理

Amazon OpenSearch 服务提供了多种方法来控制对您的域名的访问权限。本主题介绍了各种策略类型，其彼此交互的方式，以及如何创建您自己的自定义策略。

策略的类型

OpenSearch 服务支持三种类型的访问策略：

基于资源的策略

您可以在创建域时添加基于资源的策略（通常称为域访问策略）。这些策略指定主体可以对域的子资源执行哪些操作（跨集群搜索除外）。子资源包括 OpenSearch 索引和 API。Principal 元素指定账户、用户或允许访问的角色。Resource 元素指定这些委托人可以访问哪些子资源。

例如，以下基于资源的策略将授予 test-user 针对 test-domain 上的子资源的完全访问权限 (es:*)：

{
  "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/*"
    }
  ]
}

两个重要注意事项适用于此策略：

您可以通过添加通配符来指定部分索引名称。此示例将识别任何以 commerce 开头的索引：

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

在这种情况下，该通配符意味着 test-user 可以请求 test-domain 中名称以 commerce 开头的索引。

要进一步限制 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-user 只能执行一项操作：搜索 commerce-data 索引。域中的所有其他索引均不可访问，且如果没有使用 es:ESHttpPut 或 es:ESHttpPost 操作的权限，test-user 将无法添加或修改文档。

接下来，您可以决定为高级用户配置角色。此策略提供对索引中所有 URI 的 HTTP GET 和 PUT 方法的 power-user-role 访问权限：

{
  "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 服务域一部分的基于资源的策略不同，您可以使用 Amazon Identity and Access Management (IAM) 服务将基于身份的策略附加到用户或角色。与基于资源的策略一样，基于身份的策略指定谁可以访问服务，他们可以执行哪些操作，以及他们可以对哪些资源执行这些操作（如果适用）。

虽然不一定，但基于身份的策略往往更通用。它们通常仅控制用户可执行的配置 API 操作。制定这些策略后，您可以在 Service 中使用基于资源的策略（或精细的访问控制）为用户 OpenSearch 提供对 OpenSearch 索引和 API 的访问权限。

由于基于身份的策略附加到用户或角色 (委托人)，JSON 不会指定委托人。以下策略授予对以 Describe 和 List 开头的操作的访问权限。这种操作组合提供对域配置的只读访问权限，但不提供对域本身中存储的数据的访问权限：

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

管理员可能拥有对 OpenSearch 服务以及存储在所有域中的所有数据的完全访问权限：

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

借助基于身份的策略，您可以使用标签来控制对配置 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标签，则以下策略允许附加的委托人向 OpenSearch API 发送 GET 和 PUT 请求：

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

要对 OpenSearch API 进行更精细的控制，可以考虑使用精细的访问控制。

OpenSearch 服务支持配置 API 的RequestTag和TagKeys全局条件密钥，而不是 OpenSearch API。这些条件仅适用于在请求中包含标签的 API 调用，例如 CreateDomain、AddTags 和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 的策略将对域的访问限制在一个或多个 IP 地址或 CIDR 块。从技术上讲，基于 IP 的策略不是一种不同类型的策略。相反，它们仅仅是指定匿名委托人的基于资源的策略，且包含一个特殊的 Condition 元素。

基于 IP 的策略的主要吸引力在于它们允许向 OpenSearch 服务域发出未签名的请求，从而允许您使用 curl 和 OpenSearch Dashboards 等客户端，或者通过代理服务器访问该域。要了解更多信息，请参阅使用代理从 OpenSearch 仪表板访问 OpenSearch 服务。

以下策略向源自指定 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 服务请求

即使您配置了完全开放的基于资源的访问策略，对 OpenSearch 服务配置 API 的所有请求也必须经过签名。如果您的策略指定了 IAM 角色或用户，则还必须使用 Amazon 签名版本 4 签署对 OpenSearch API 的请求。签名方法因 API 而异：

当策略发生冲突时

当策略不一致或没有明确提到某个用户时，复杂性将提高。IAM 用户指南中的了解 IAM 的工作方式提供了策略评估逻辑的简明摘要：

例如，如果基于资源的策略授予您对域子资源（ OpenSearch 索引或 API）的访问权限，但基于身份的策略拒绝您访问，则您的访问将被拒绝。如果某个基于身份的策略授予访问权限，基于资源的策略不指定您是否应具有访问权限，则您将被允许访问。请参阅以下交叉策略表，了解域子资源结果的完整摘要。

策略元素参考

OpenSearch 服务支持 IAM 策略元素参考中的大多数策略元素，但除外NotPrincipal。下表显示了最常用的元素。

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

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

高级选项和 API 注意事项

OpenSearch 服务有几个高级选项，其中一个涉及访问控制：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/*"
    }
  ]
}

此政策授予对 OpenSearch 批量 API test-index 的test-user完全访问权限。它还允许对 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 中。由于 S OpenSearch ervice 使用 URL 来控制对网域子资源的访问权限，因此实际上可以使用批量 API 对域名子资源进行restricted-index更改。test-user即使该用户缺乏对索引的 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 的调用仍然有效。这第二个终端节点包含一个索引名称，因此您无需在请求正文中指定一个索引名称。

OpenSearch 仪表板严重依赖于 mget 和 msearch，因此更改后不太可能正常运行。若要进行部分补救，您可以将 rest.action.multi.allow_explicit_index 保留为 true 或拒绝特定用户访问这些 API 中的一个或多个。

有关更改此设置的信息，请参阅高级集群设置。

同样，以下基于资源的策略包含两个小问题：

{
  "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/*"
    }
  ]
}

与混合广泛的允许和集中的拒绝相比，最安全的方法是遵循最小特权原则，仅授予执行任务所需的权限。有关控制对单个索引或 OpenSearch操作的访问权限的更多信息，请参见Amazon 服务中的精细访问控制 OpenSearch 。

配置访问策略

其他示例策略

尽管本章包含许多示例策略，但 Amazon 访问控制是一个复杂的主题，最好通过示例来理解。有关更多信息，请参阅 IAM 用户指南中 IAM 基于身份的策略示例。