Amazon Elasticsearch Service 中的精细访问控制 - Amazon Elasticsearch Service
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

Amazon Elasticsearch Service 中的精细访问控制

精细访问控制提供了用于控制对 Amazon Elasticsearch Service 上的数据的访问的其他方法。例如,根据请求发出者,您可能希望搜索仅返回一个索引中的结果。您可能想隐藏文档中的某些字段或完全排除某些文档。精细访问控制提供了以下功能:

  • 基于角色的访问控制

  • 索引、文档和字段级别的安全性

  • Kibana 多租户

  • 适用于 Elasticsearch 和 Kibana 的 HTTP 基本身份验证

重点:精细访问控制和 Amazon ES 安全性

Amazon Elasticsearch Service 安全性有三大层:

Network

第一个安全层是网络,该层决定请求是否会到达 Amazon ES 域。如果您在创建域时选择 Public access (公共访问),则来自任何连接到 Internet 的客户端的请求都能到达域终端节点。如果您选择 VPC access (VPC 访问),则客户端必须连接到 VPC(并且关联的安全组必须允许它)才能使请求到达终端节点。有关更多信息,请参阅Amazon Elasticsearch Service 域的 VPC 支持

域访问策略

第二个安全层是域访问策略。在请求到达域终端节点后,基于资源的访问策略允许或拒绝请求访问给定 URI。访问策略在请求本身到达 Elasticsearch 前在域“边缘”接受或拒绝请求。

访问权限的精细控制

第三个也是最后一个安全层是精细访问控制。在基于资源的访问策略允许请求到达域终端节点后,精细访问控制对用户凭证进行评估,并对用户进行身份验证或拒绝请求。如果精细访问控制对用户进行身份验证,它将获取映射到该用户的所有角色,并使用完整的权限集来确定如何处理请求。

注意

如果基于资源的访问策略包含 IAM 用户或角色,则客户端必须发送使用 AWS 签名版本 4 进行签名的请求。因此,访问策略可能会与精细访问控制发生冲突,特别是在您使用内部用户数据库和 HTTP 基本身份验证时。您无法使用用户名和密码以及 IAM 凭证对请求进行签名。通常,如果您启用精细访问控制,我们建议您使用不需要已签名请求的域访问策略。

第一个示意图说明了一个常见配置:启用了精细访问控制的 VPC 访问域、基于 IAM 的访问策略和 IAM 主用户。


        针对 VPC 域的精细访问控制授权流程

第二个示意图说明了另一个常见配置:启用了精细访问控制的公共访问域、不使用 IAM 委托人的访问策略以及内部用户数据库中的主用户。


        针对公共访问域的精细访问控制授权流程

示例

考虑向 movies/_search?q=thor 发出 GET 请求。用户是否有权搜索 movies 索引? 如果是这样,用户是否有权查看该索引中的所有文档? 响应是否应忽略或匿名化任何字段? 对于主用户,响应可能如下所示:

{ "hits": { "total": 7, "max_score": 8.772789, "hits": [{ "_index": "movies", "_type": "_doc", "_id": "tt0800369", "_score": 8.772789, "_source": { "directors": [ "Kenneth Branagh", "Joss Whedon" ], "release_date": "2011-04-21T00:00:00Z", "genres": [ "Action", "Adventure", "Fantasy" ], "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.", "title": "Thor", "actors": [ "Chris Hemsworth", "Anthony Hopkins", "Natalie Portman" ], "year": 2011 } }, ... ] } }

如果具有更有限的权限的用户发出完全相同的请求,则响应可能如下所示:

{ "hits": { "total": 2, "max_score": 8.772789, "hits": [{ "_index": "movies", "_type": "_doc", "_id": "tt0800369", "_score": 8.772789, "_source": { "year": 2011, "release_date": "3812a72c6dd23eef3c750c2d99e205cbd260389461e19d610406847397ecb357", "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.", "title": "Thor" } }, ... ] } }

响应的命中次数较少,并且每次命中的字段较少。此外,release_date 字段是匿名的。如果不具有权限的用户发出相同的请求,集群将返回错误:

{ "error": { "root_cause": [{ "type": "security_exception", "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]" }], "type": "security_exception", "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]" }, "status": 403 }

如果用户提供的凭证无效,则集群将返回 Unauthorized 异常。

主要概念

角色 是使用精细访问控制的核心方式。在此情况下,角色与 IAM 角色不同。角色包含任意权限组合:集群范围的、特定于索引的、文档级别的和字段级别的。

配置一个角色后,可以将该角色映射 到一个或多个用户。例如,您可以将三个角色映射到单个用户:一个角色提供对 Kibana 的访问权限,一个角色提供对 index1 的只读访问权限,还有一个角色提供对 index2 的写入访问权限。您也可以将所有这些权限包含在单个角色中。

用户 是向 Elasticsearch 集群发出请求的人员或应用程序。用户具有他们在发出请求时指定的凭证,即 IAM 访问密钥或用户名和密码。在对 Amazon Elasticsearch Service 启用精细访问控制后,您可以在配置域时为主用户 选择其中一种方式。主用户具有集群的完全权限,并管理角色和角色映射。

  • 如果您为主用户选择 IAM,则必须使用 AWS 签名版本 4 对集群的所有请求进行签名。有关示例代码,请参阅 签署对 Amazon Elasticsearch Service 的 HTTP 请求

    在以下情况下,我们建议您使用 IAM:在多个集群上使用相同的用户,使用 Amazon Cognito 访问 Kibana(有或没有外部身份提供商)或具有支持签名版本 4 签名的 Elasticsearch 客户端。

  • 如果您选择内部用户数据库,则可以使用 HTTP 基本身份验证(以及 IAM 凭证)向集群发出请求。大多数客户端支持基本身份验证,包括 curl。内部用户数据库存储在 Elasticsearch 索引中,因此您无法与其他集群共享该数据库。

    在以下情况下,我们建议您使用内部用户数据库:不需要跨多个集群重用用户,使用 HTTP 基本身份验证访问 Kibana(而不是 Amazon Cognito)或客户端仅支持基本身份验证。内部用户数据库是开始使用 Amazon ES 的最简单方法。

启用精细访问控制

使用控制台、AWS CLI 或配置 API 启用精细访问控制。控制台提供了最简单的体验。要查看相关步骤,请参阅 创建和管理 Amazon Elasticsearch Service 域。以下是启用精细访问控制的要求:

无法对现有域启用精细访问控制,只能对新域执行此操作。一旦启用精细访问控制,便无法将其禁用。

以主用户身份访问 Kibana

精细访问控制具有一个可简化管理任务的 Kibana 插件。可以使用 Kibana 管理用户、角色、映射、操作组和租户。不过,根据您配置域的方式,Kibana 登录页面和底层身份验证方法是不同的。

管理权限

主要概念中所述,您可以使用角色、用户和映射管理精细访问控制权限。此部分介绍如何创建和应用这些资源。我们建议您以主用户身份登录 Kibana 来执行这些操作。


        Kibana 中的安全性主页

创建角色

可以使用 Kibana 或 REST API 中的 _opendistro/_security 操作创建新角色以实施精细访问控制。有关更多信息,请参阅 Open Distro for Elasticsearch 文档

精细访问控制还包含大量预定义角色。Kibana 和 Logstash 等客户端向 Elasticsearch 发出各种各样的请求,这使得难以使用最小权限集手动创建角色。例如,kibana_user 角色包括用户处理索引模式、可视化内容、控制面板和租户所需的权限。我们建议将它映射到任何访问 Kibana 的用户或后端角色,以及其他允许访问其他索引的角色。

集群级安全性

集群级权限包括用于执行广泛请求(例如 _mget_msearch_bulk)、监控运行状况、拍摄快照等操作的功能。在创建角色时,使用 Cluster Permissions (集群权限) 选项卡管理这些权限。有关集群级操作组的列表,请参阅 Open Distro for Elasticsearch 文档

索引级安全性

索引级权限包括用于执行创建新索引、搜索索引、读取和写入文档、删除文档、管理别名等操作的功能。在创建角色时,使用 Index Permissions (索引权限) 选项卡管理这些权限。有关索引级操作组的列表,请参阅 Open Distro for Elasticsearch 文档

文档级安全性

文档级安全性允许您限制用户可在索引中查看的文档。在创建角色时,请指定索引模式和 Elasticsearch 查询。映射到该角色的任何用户只能查看与查询匹配的文档。文档级安全性将影响搜索时收到的命中数

有关更多信息,请参阅 Open Distro for Elasticsearch 文档

字段级安全性

字段级安全性允许您控制用户可查看的文档字段。创建角色时,添加要包含或排除的字段的列表。如果包含字段,则映射到该角色的任何用户都只能查看这些字段。如果排除字段,则他们可以查看 排除的字段之外的所有字段。字段级安全性将影响搜索时包含在命中内的字段数

有关更多信息,请参阅 Open Distro for Elasticsearch 文档

字段遮罩

字段遮罩是字段级安全性的替代方法,它允许您匿名化字段中的数据,而不是将其完全删除。创建角色时,添加要遮罩的字段的列表。字段遮罩将影响搜索时是否能查看字段内容

创建用户

如果启用了内部用户数据库,则可以使用 Kibana 或 REST API 中的 _opendistro/_security 操作创建用户。有关更多信息,请参阅 Open Distro for Elasticsearch 文档

如果您为主用户选择了 IAM,请忽略 Kibana 的此部分。而是应创建 IAM 用户和 IAM 角色。有关更多信息,请参阅 IAM 用户指南

将角色映射到用户

角色映射是精细访问控制的最重要的方面。精细访问控制具有一些预定义的角色来帮助您入门,但除非您将角色映射到用户,否则,向集群发出的每个请求都会以权限错误结束。

后端角色 提供了另一种将角色映射到用户的方法。您可以将同一角色映射到单个后端角色,然后确保所有用户都具有该后端角色,而不是将同一角色映射到几十个不同的用户。后端角色可以为您在内部用户数据库中创建用户时指定的 IAM 角色或任意字符串。

  • Users (用户) 部分中指定用户、IAM 用户 ARN 和 Amazon Cognito 用户字符串。Cognito 用户字符串采用的形式为 Cognito/user-pool-id/username

  • Backend roles (后端角色) 部分中指定后端角色和 IAM 角色 ARN。


          角色映射页面

可以使用 Kibana 或 REST API 中的 _opendistro/_security 操作将角色映射到用户。有关更多信息,请参阅 Open Distro for Elasticsearch 文档

创建操作组

操作组是可以在不同的资源中重用的权限集。可以使用 Kibana 或 REST API 中的 _opendistro/_security 操作创建新的操作组,尽管默认操作组对于大多数使用案例来说已够用了。有关默认操作组的更多信息,请参阅 Open Distro for Elasticsearch 文档

Kibana 多租户

租户是用于保存索引模式、可视化内容、控制面板和其他 Kibana 对象的空间。Kibana 多租户可让您安全地与其他 Kibana 用户共享您的工作(或保持您工作的私密性)。您可以控制哪些角色有权访问租户,以及这些角色是否具有读取或写入访问权限。要了解更多信息,请参阅 Open Distro for Elasticsearch 文档

查看当前租户或更改租户

  1. 导航到 Kibana 并进行登录。

  2. 选择 Tenants (租户)

  3. 在创建可视化内容或控制面板之前验证租户。如果您想与所有其他 Kibana 用户共享您的工作,请选择 Global (全球)。要与一部分 Kibana 用户共享您的工作,请选择其他共享租户。否则,请选择 Private (私有)

推荐配置

由于精细访问控制与其他安全功能的交互方式,我们建议您使用适用于大多数使用案例的多种精细访问控制配置。

Description 主用户 用于 Kibana 的 Amazon Cognito 身份验证 域访问策略
将 IAM 凭证或基本身份验证用于对 Elasticsearch API 的调用,并使用基本身份验证访问 Kibana。使用 Kibana 或 REST API 管理精细访问控制角色。 用户名和密码 Disabled
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
将 IAM 凭证用于对 Elasticsearch API 的调用,并使用 Amazon Cognito 访问 Kibana。使用 Kibana 或 REST API 管理精细访问控制角色。 IAM 用户或角色 Enabled
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }
将 IAM 凭证用于对 Elasticsearch API 的调用,并阻止对 Kibana 的大多数访问。使用 REST API 管理精细访问控制角色。 IAM 用户或角色 Disabled
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/_plugin/kibana*" } ] }

教程:IAM 主用户和 Amazon Cognito

本教程介绍了一个常见的使用案例:具有针对 Kibana 的 Amazon Cognito 身份验证的 IAM 主用户。尽管这些步骤使用 Amazon Cognito 用户池进行身份验证,但相同的基本流程适用于任何 Cognito 身份验证提供商,从而允许您将不同的 IAM 角色分配给不同的用户(例如 SAML)。

注意

本教程假定您有两个现有 IAM 角色,一个用于主用户,另一个用于更受限的用户。如果您没有两个角色,请创建它们

开始使用精细访问控制

  1. 使用以下设置创建域

    • Elasticsearch 7.4

    • 公有访问权限

    • 已启用精细访问控制,并将 IAM 角色作为主用户(在本教程的其余内容中,为 IAMMasterUserRole

    • 已启用用于 Kibana 的 Amazon Cognito 身份验证

    • 以下访问策略:

      { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:ESHttp*" ], "Resource": "arn:aws:es:region:account:domain/domain-name/*" } ] }
    • 所有到达域的流量所需的 HTTPS

    • 节点到节点加密

    • 静态数据加密

  2. 导航到 IAM 控制台,然后选择 Roles (角色)

  3. 选择 IAMMasterUserRole,然后选择 Trust relationships (信任关系) 选项卡。

  4. 选择 Edit trust relationship (编辑信任关系),并确保 Amazon Cognito 身份池可代入该角色。您应看到以下语句:

    { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "cognito-identity.amazonaws.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "cognito-identity.amazonaws.com:aud": "identity-pool-id" }, "ForAnyValue:StringLike": { "cognito-identity.amazonaws.com:amr": "authenticated" } } }] }
  5. 选择 Update Trust Policy

  6. 将相同的信任策略添加到第二个 IAM 角色(对于本教程的其余部分,为 IAMLimitedUserRole)。

  7. 导航到 Amazon Cognito 控制台,然后选择 Manage User Pools (管理用户池)

  8. 选择您的用户池,然后选择 Users and groups (用户和组)

  9. 选择 Create user (创建用户),指定用户名 master-user 和密码,然后选择 Create user (创建用户)

  10. 创建另一个名为 limited-user 的用户。

  11. 选择 Groups (组) 选项卡,然后选择 Create group (创建组)

  12. 将组命名为 master-user-group,选择 IAM role (IAM 角色) 下拉列表中的 IAMMasterUserRole,然后选择 Create group (创建组)

  13. 创建另一个名为 limited-user-group 的组,该组使用 IAMLimitedUserRole

  14. 选择 master-user-group,再选择 Add users (添加用户),然后添加 master-user

  15. 选择 limited-user-group,再选择 Add users (添加用户),然后添加 limited-user

  16. 选择 App client settings (应用程序客户端设置),并记下域的应用程序客户端 ID。

  17. 选择 Federated Identities (联合身份),再选择您的身份池,然后选择 Edit identity pool (编辑身份池)

  18. 展开 Authentication providers (身份验证提供商),查找域的用户池 ID 和应用程序客户端 ID,然后将 Use default role (使用默认角色) 更改为 Choose role from token (从令牌中选择角色)

  19. 对于 Role resolution (角色解析),选择 DENY (拒绝)。在使用此设置时,用户必须位于组中才能在身份验证后接收 IAM 角色。

  20. 选择 Save Changes

  21. 导航到 Kibana。

  22. 使用 master-user 进行登录。

  23. 选择 Try our sample data (试用我们的示例数据)

  24. 添加示例飞行数据。

  25. 依次选择 Security (安全性)Roles (角色)Add a new role (添加新角色)

  26. 将角色命名为 new-role,然后选择 Index Permissions (索引权限)

  27. 选择 Add index permissions (添加索引权限),然后为索引模式指定 kibana_sample_data_fli*

  28. 依次选择 Add Action (添加操作)read (读取)

  29. 对于 Document Level Security Query (文档级安全查询),请指定以下查询:

    { "match": { "FlightDelay": true } }

    然后选择 Test DLS query syntax (测试 DLS 查询语法)

  30. 对于 Include or exclude fields (包含或排除字段),选择 Exclude fields (排除字段),然后选择 Add Field (添加字段).指定 FlightNum

  31. 对于 Anonymize fields (匿名化字段),选择 Add Field (添加字段)。指定 Dest

  32. 选择 Save Role Definition (保存角色定义)

  33. 依次选择 Back (返回)Role Mappings (角色映射)Add a new role mapping (添加新角色映射)

  34. 对于 Role (角色),选择 new-role。选择 Add Backend Role (添加后端角色),然后为 IAMLimitedUserRole 指定 ARN。然后,选择 Submit (提交)

  35. 再次选择 Add a new role mapping (添加新角色映射)

  36. 对于 Role (角色),选择 kibana_user。选择 Add Backend Role (添加后端角色),然后为 IAMLimitedUserRole 指定 ARN。然后,选择 Submit (提交)

  37. 在新的私有浏览器窗口中,导航到 Kibana,使用 limited-user 进行登录,然后选择 Explore on my own (自行浏览)

  38. 选择 Dev Tools (开发人员工具),然后运行默认搜索:

    GET _search { "query": { "match_all": {} } }

    请注意权限错误。limited-user 没有运行集群范围内搜索的权限。

  39. 运行另一个搜索:

    GET kibana_sample_data_flights/_search { "query": { "match_all": {} } }

    请注意,在所有匹配的文档中,有一个为 trueFlightDelay 字段,一个匿名化的 Dest 字段,但没有 FlightNum 字段。

  40. 在原始浏览器窗口中,以 master-user 身份登录,选择 Dev Tools (开发人员工具),然后执行相同的搜索。请注意权限、命中数、匹配文档和包含字段的差异。

教程:内部用户数据库和 HTTP 基本身份验证

本教程介绍了另一个常见的使用案例:内部用户数据库和针对 Kibana 的 HTTP 基本身份验证中使用的主用户。

开始使用精细访问控制

  1. 使用以下设置创建域

    • Elasticsearch 7.4

    • 公有访问权限

    • 对内部用户数据库中的主用户的精细访问控制(对于本教程的其余部分,为 TheMasterUser

    • 已禁用 用于 Kibana 的 Amazon Cognito 身份验证

    • 以下访问策略:

      { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:ESHttp*" ], "Resource": "arn:aws:es:region:account:domain/domain-name/*" } ] }
    • 所有到达域的流量所需的 HTTPS

    • 节点到节点加密

    • 静态数据加密

  2. 导航到 Kibana。

  3. 使用 TheMasterUser 进行登录。

  4. 选择 Try our sample data (试用我们的示例数据)

  5. 添加示例飞行数据。

  6. 依次选择 Security (安全性)Internal User Database (内部用户数据库)Add a new internal user (添加新的内部用户)

  7. 将用户命名为 new-user,指定密码,并为用户提供后端角色 new-backend-role。然后,选择 Submit (提交)

  8. 依次选择 Back (返回)Roles (角色)Add a new role (添加新角色)

  9. 将角色命名为 new-role,然后选择 Index Permissions (索引权限)

  10. 选择 Add index permissions (添加索引权限),然后为索引模式指定 kibana_sample_data_fli*

  11. 依次选择 Add Action Group (添加操作组)read (读取)

  12. 对于 Document Level Security Query (文档级安全查询),请指定以下查询:

    { "match": { "FlightDelay": true } }

    然后选择 Test DLS query syntax (测试 DLS 查询语法)

  13. 对于 Include or exclude fields (包含或排除字段),选择 Exclude fields (排除字段),然后选择 Add Field (添加字段).指定 FlightNum

  14. 对于 Anonymize fields (匿名化字段),选择 Add Field (添加字段)。指定 Dest

  15. 选择 Save Role Definition (保存角色定义)

  16. 依次选择 Back (返回)Role Mappings (角色映射)Add a new role mapping (添加新角色映射)

  17. 对于 Role (角色),选择 new-role。选择 Add Backend Role (添加后端角色),然后指定 new-backend-role。然后,选择 Submit (提交)

  18. 再次选择 Add a new role mapping (添加新角色映射)

  19. 对于 Role (角色),选择 kibana_user。选择 Add User (添加用户),然后指定 new-user。然后,选择 Submit (提交)

    new-user 具有 kibana_user 角色,但所有具有 new-backend-role 后端角色的用户都具有 new-role 角色。

  20. 在新的私有浏览器窗口中,导航到 Kibana,使用 new-user 进行登录,然后选择 Explore on my own (自行浏览)

  21. 选择 Dev Tools (开发人员工具),然后运行默认搜索:

    GET _search { "query": { "match_all": {} } }

    请注意权限错误。new-user 没有运行集群范围内搜索的权限。

  22. 运行另一个搜索:

    GET kibana_sample_data_flights/_search { "query": { "match_all": {} } }

    请注意,在所有匹配的文档中,有一个为 trueFlightDelay 字段,一个匿名化的 Dest 字段,但没有 FlightNum 字段。

  23. 在原始浏览器窗口中,以 TheMasterUser 身份登录,选择 Dev Tools (开发人员工具),然后执行相同的搜索。请注意权限、命中数、匹配文档和包含字段的差异。

限制

精细访问控制具有几个重要限制:

  • 如果域位于 VPC 中,则角色映射的 hosts 部分(将角色映射映射到主机名或 IP 地址)会不起作用。您仍可以将角色映射到用户和后端角色。

  • 内部用户数据库中的用户无法更改其自己的密码。主用户(或具有等效权限的用户)必须自行更改其密码。

  • 如果您为主用户选择 IAM,但不启用 Amazon Cognito 身份验证,Kibana 将显示一个不起作用的登录页面。

  • 如果您为主用户选择 IAM,则仍可以在内部用户数据库中创建用户。但是,由于此配置下未启用 HTTP 基本身份验证,因此,使用这些用户凭证签名的任何请求都将被拒绝。

  • 如果您使用 SQL 查询您无权访问的索引,则您会收到“no permissions (无权限)”错误。如果索引不存在,则会收到“no such index (无此类索引)”错误。错误消息中的此类差异意味着,如果您碰巧猜到其名称,则可以确认索引的存在。

    要最大程度地减小问题,请不要在索引名称中包含敏感信息。要拒绝所有对 SQL 的访问,请将以下元素添加到您的域访问策略:

    { "Effect": "Deny", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_opendistro/_sql" }

修改主用户

如果您忘记了主用户的详细信息,则可以使用控制台、AWS CLI 或配置 API 重新配置它。

修改主用户(控制台)

  1. 转至 https://aws.amazon.com,然后选择 Sign In to the Console (登录控制台)

  2. Analytics (分析) 下,选择 Elasticsearch Service

  3. 选择您的域。

  4. 依次选择 Actions (操作)Modify master user (修改主用户)

  5. 选择 Set IAM role as master user (将 IAM 角色设置为主用户)Create new master user (创建新的主用户)

    • 如果您之前使用了 IAM 主用户,则精细访问控制会将 all_access 角色重新映射到您指定的新 IAM ARN。

    • 如果您之前使用了内部用户数据库,则精细访问控制会创建一个新的主用户。您可以使用新的主用户删除旧的主用户。

  6. 选择 Submit

其他主用户

在创建域时指定主用户,但如果需要,可以使用此主用户创建其他主用户。您有两种选择:Kibana 或 REST API。

  • 在 Kibana 中,依次选择 Security (安全性)Role Mappings (角色映射),然后将新主用户映射到 all_accesssecurity_manager 角色。

    
            角色映射页面
  • 要使用 REST API,请发送以下请求:

    PUT _opendistro/_security/api/rolesmapping/all_access { "backend_roles": [ "arn:aws:iam::123456789012:role/fourth-master-user" ], "hosts": [], "users": [ "master-user", "second-master-user", "arn:aws:iam::123456789012:user/third-master-user" ] }
    PUT _opendistro/_security/api/rolesmapping/security_manager { "backend_roles": [ "arn:aws:iam::123456789012:role/fourth-master-user" ], "hosts": [], "users": [ "master-user", "second-master-user", "arn:aws:iam::123456789012:user/third-master-user" ] }

    这些请求将替换 当前角色映射,因此,首先执行 GET 请求,以便您可以在 PUT 请求中包含所有当前角色。如果您无法访问 Kibana,并且希望将 IAM 角色从 Amazon Cognito 映射到 all_access 角色,则 REST API 会特别有用。

手动快照

精细访问控制会给拍摄手动快照带来一些额外的复杂性。要注册快照存储库—即使您使用 HTTP 级别身份验证以实现所有其他目的—您必须将 manage_snapshots 角色映射到具有 iam:PassRole 权限的 IAM 角色来代入 TheSnapshotRole,如手动快照先决条件中所定义。

然后,使用该 IAM 角色向域发送已签名请求,如注册手动快照存储库中所述。

集成

如果您将其他 AWS 服务与 Amazon ES 结合使用,则必须为这些服务提供具有适当权限的 IAM 角色。例如,Kinesis Data Firehose 交付流通常使用名为 firehose_delivery_role 的 IAM 角色。在 Kibana 中,创建一个用于精细访问控制的角色,并将 IAM 角色映射到该角色。在此情况下,新角色需要以下权限:

{ "cluster_permissions": [ "cluster_composite_ops", "cluster_monitor" ], "index_permissions": [{ "index_patterns": [ "firehose-index*" ], "allowed_actions": [ "create_index", "manage", "crud" ] }] }

权限将因每个服务执行的操作而异。为数据建立索引的 AWS IoT 规则或r AWS Lambda 函数可能需要对 Kinesis Data Firehose 的类似权限,而仅执行搜索的 Lambda 函数可使用更有限的集合。

REST API 差异

精细访问控制 REST API 会因您的 Elasticsearch 版本而略为不同。在发出 PUT 请求之前,请发出 GET 请求以验证预期请求正文。例如,对 _opendistro/_security/api/userGET 请求将返回所有用户,然后您可以修改并使用这些用户来发出有效的 PUT 请求。

在 Elasticsearch 6.x 上,用于创建用户的请求与以下内容类似:

PUT _opendistro/_security/api/user/new-user { "password": "some-password", "roles": ["new-backend-role"] }

在 Elasticsearch 7.x 上,请求与以下内容类似:

PUT _opendistro/_security/api/user/new-user { "password": "some-password", "backend_roles": ["new-backend-role"] }

此外,在 Elasticsearch 6.x 中,租户是角色的属性:

GET _opendistro/_security/api/roles/all_access { "all_access": { "cluster": ["UNLIMITED"], "tenants": { "admin_tenant": "RW" }, "indices": { "*": { "*": ["UNLIMITED"] } }, "readonly": "true" } }

在 Elasticsearch 7.x 中,租户是具有自己的 URI 的对象:

GET _opendistro/_security/api/tenants { "global_tenant": { "reserved": true, "hidden": false, "description": "Global tenant", "static": false } }

有关 7.x REST API 的文档,请参阅 Open Distro for Elasticsearch 文档

提示

如果您使用内部用户数据库,则可以使用 curl 发出请求并测试您的域。尝试以下示例命令:

curl -XGET -u master-user:master-user-password 'domain-endpoint/_search' curl -XGET -u master-user:master-user-password 'domain-endpoint/_opendistro/_security/api/user'