本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
中的精细访问控制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 主用户。

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

Example
考虑向 GET
发出 movies/_search?q=thor
请求。 用户是否有权搜索 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 访问 Kibana 或者具有支持签名版本 4 签名的 Amazon Cognito 客户端,我们建议使用 Elasticsearch。
-
如果您选择内部用户数据库,则可以使用 HTTP 基本身份验证(以及 IAM 凭证)向集群发出请求。大多数客户端支持基本身份验证,包括 curl
. 内部用户数据库存储在 Elasticsearch 索引中,因此您无法与其他集群共享该数据库。 在以下情况下,我们建议您使用内部用户数据库:不需要跨多个集群重用用户,使用 HTTP 基本身份验证访问 Kibana(而不是 Amazon Cognito)或客户端仅支持基本身份验证。内部用户数据库是开始使用 的最简单方法。Amazon ES.
启用精细访问控制
使用控制台、AWS CLI 或配置 API 启用精细访问控制。控制台提供了最简单的体验。要查看相关步骤,请参阅 创建和管理 Amazon Elasticsearch Service 域. 以下是启用精细访问控制的要求:
无法对现有域启用精细访问控制,只能对新域执行此操作。一旦启用精细访问控制,便无法将其禁用。
以主用户身份访问 Kibana
精细访问控制具有一个可简化管理任务的 Kibana 插件。可以使用 Kibana 管理用户、角色、映射、操作组和租户。但是,Kibana 登录页面和底层身份验证方法会有所不同,具体取决于您管理用户和配置域的方式。
-
如果要使用 IAM 进行用户管理,请使用 Amazon Cognito用于 Kibana 的 身份验证 访问 Kibana。否则,Kibana 将显示一个不起作用的登录页面。请参阅Limitations.
使用 Amazon Cognito 身份验证时,身份池中的某个代入角色必须与为主用户指定的 IAM 角色匹配。有关此配置的更多信息,请参阅(可选) 配置精细访问和教程:IAM 主用户和 Amazon Cognito.
-
如果您选择使用内部用户数据库,则可以使用您的主用户名和密码登录 Kibana。您必须通过 HTTPS 访问 Kibana。Kibana 的 Amazon Cognito 和 SAML 身份验证均会替换此登录屏幕。
有关此配置的更多信息,请参阅教程:内部用户数据库和 HTTP 基本身份验证.
-
如果您选择使用 SAML 身份验证,则可以使用来自外部身份提供商的凭证进行登录。有关更多信息,请参阅 用于 Kibana 的 SAML 身份验证.
管理权限
如重要概念中所述,您可以使用角色、用户和映射管理精细访问控制权限。此部分介绍如何创建和应用这些资源。我们建议您以主用户身份登录 Kibana 来执行这些操作。

创建角色
可以使用 Kibana 或 REST API 中的 _opendistro/_security
操作创建新角色以实施精细访问控制。有关更多信息,请参阅 Open Distro for 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 文档
字段遮罩
字段遮罩是字段级安全性的替代方法,它允许您匿名化字段中的数据,而不是将其完全删除。创建角色时,添加要遮罩的字段的列表。字段遮罩将影响搜索时是否能查看字段内容.
如果将标准遮罩应用于字段,则 Amazon ES 将使用可能导致不准确聚合结果的安全随机哈希。要对遮蔽字段执行聚合,请改用基于模式的遮蔽。
创建用户
如果启用了内部用户数据库,则可以使用 Kibana 或 REST API 中的 _opendistro/_security
操作创建用户。有关更多信息,请参阅 Open Distro for Elasticsearch 文档
如果您为主用户选择了 IAM,请忽略 Kibana 的此部分。而是应创建 IAM 用户和 IAM 角色。有关更多信息,请参阅IAM 用户指南.
将角色映射到用户
角色映射是精细访问控制的最重要的方面。精细访问控制具有一些预定义的角色来帮助您入门,但除非您将角色映射到用户,否则,向集群发出的每个请求都会以权限错误结束。
后端角色也称为外部身份,提供另一种将角色映射到用户的方式。您可以将同一角色映射到单个后端角色,然后确保所有用户都具有该后端角色,而不是将同一角色映射到几十个不同的用户。后端角色可以是 IAM 角色或任意字符串。
-
在 ARNsUsers (用户)Amazon Cognito 部分中指定用户、IAM 用户 和 用户字符串。Cognito 用户字符串采用的形式为
Cognito/
.user-pool-id
/username
-
在 ARNsExternal identities (外部身份) 部分中指定后端角色和 IAM 角色 。

可以使用 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 文档
查看当前租户或更改租户
-
导航到 Kibana 并进行登录。
-
在右上角,选择您的用户图标。
-
选择 Switch tenanters。
-
在创建可视化内容或控制面板之前验证租户。如果您想与所有其他 Kibana 用户共享您的工作,请选择 Global (全球). 要与一部分 Kibana 用户共享您的工作,请选择其他共享租户。否则,请选择 Private (私有).
推荐配置
由于精细访问控制与其他安全功能的交互方式,我们建议使用适用于大多数使用案例的多种精细访问控制配置。
描述 | 主用户 | 域访问策略 |
---|---|---|
将 IAM 凭证用于对 Elasticsearch APIs 的调用,并使用 SAML 身份验证访问 Kibana。使用 Kibana 或 REST API 管理精细访问控制角色。 |
IAM 用户或角色 |
|
使用 IAM 凭证或基本身份验证来调用 Elasticsearch APIs。 使用 Kibana 或 REST API 管理精细访问控制角色。 此配置提供了大量灵活性,特别是当您的 Elasticsearch 客户端仅支持基本身份验证时。 如果您有现有身份提供商,请使用 SAML 身份验证访问 Kibana。否则,请在内部用户数据库中管理 Kibana 用户。 |
用户名和密码 |
|
将 IAM 凭证用于对 Elasticsearch APIs 的调用,并使用 Amazon Cognito 访问 Kibana。使用 Kibana 或 REST API 管理精细访问控制角色。 |
IAM 用户或角色 |
|
将 IAM 凭证用于对 Elasticsearch APIs 的调用,并阻止对 Kibana 的大多数访问。使用 REST API 管理精细访问控制角色。 |
IAM 用户或角色 |
|
教程:IAM 主用户和 Amazon Cognito
本教程介绍了一个常见的使用案例:具有针对 Kibana 的 Amazon Cognito 身份验证的 IAM 主用户。尽管这些步骤使用 Amazon Cognito 用户池进行身份验证,但相同的基本过程适用于任何 Cognito 身份验证提供商,从而允许您将不同的 IAM 角色分配给不同的用户。
本教程假定您有两个现有 IAM 角色,一个用于主用户,另一个用于更受限的用户。如果您没有两个角色,请创建它们.
开始使用精细访问控制
-
使用以下设置创建域
-
Elasticsearch 7.8
-
公有访问权限
-
已启用精细访问控制,并将 IAM 角色作为主用户(在本教程的其余内容中,为
IAMMasterUserRole
-
以下访问策略:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:ESHttp*" ], "Resource": "arn:aws:es:
region
:account
:domain/domain-name
/*" } ] } -
所有到达域的流量所需的 HTTPS
-
节点到节点加密
-
静态数据加密
-
-
导航到 IAM 控制台,然后选择 Roles (角色).
-
选择
IAMMasterUserRole
,然后选择 Trust relationships (信任关系) 选项卡。 -
选择 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" } } }] } -
选择 Update Trust Policy.
-
将相同的信任策略添加到第二个 IAM 角色(对于本教程的其余部分,为
IAMLimitedUserRole
-
导航到 Amazon Cognito 控制台,然后选择 Manage User Pools (管理用户池).
-
选择您的用户池,然后选择 Users and groups (用户和组).
-
选择 Create user (创建用户),指定用户名
master-user
和密码,然后选择 Create user (创建用户). -
创建另一个名为 的用户。
limited-user
. -
选择 Groups (组) 选项卡,然后选择 Create group (创建组).
-
将组命名为
master-user-group
,在IAMMasterUserRole
IAM role (IAM 角色) 下拉列表中选择 ,然后选择 Create group (创建组)。 -
创建另一个名为
limited-user-group
的组,该组使用IAMLimitedUserRole
. -
选择
master-user-group
,再选择 Add users (添加用户),然后添加master-user
. -
选择
limited-user-group
,再选择 Add users (添加用户),然后添加limited-user
. -
选择 App client settings (应用程序客户端设置) 并记下您的域的应用程序客户端 ID。
-
选择 Federated Identities (联合身份),再选择您的身份池,然后选择 Edit identity pool (编辑身份池).
-
展开 Authentication providers (身份验证提供商),查找域的用户池 ID 和应用程序客户端 ID,然后将 Use default role (使用默认角色) 更改为 Choose role from token (从令牌中选择角色).
-
对于 Role resolution (角色解析),选择 DENY (拒绝). 在使用此设置时,用户必须位于组中才能在身份验证后接收 IAM 角色。
-
选择 Save Changes.
-
导航到 Kibana。
-
使用 进行登录。
master-user
. -
选择 Try our sample data (试用我们的示例数据).
-
添加示例飞行数据。
-
依次选择 Security (安全性)、Roles (角色) 和 Create role (创建角色)。
-
将角色命名为
new-role
. -
对于索引权限,请为索引模式指定
kibana_sample_data_fli*
。 -
对于操作组,选择 read (读取)。
-
对于 Document Level Security Query (文档级安全查询),请指定以下查询:
{ "match": { "FlightDelay": true } }
-
对于字段级安全性,请选择 Exclude fields (排除字段) 并指定
FlightNum
。 -
对于 Anonymize fields (匿名化字段),指定
Dest
。 -
选择创建.
-
依次选择 Mapped users (映射的用户) 和 Manage mapping (管理映射)。然后,添加
IAMLimitedUserRole
的 ARN 作为外部身份,并选择 Map。 -
返回角色列表并选择 kibana_user。依次选择 Mapped users (映射的用户) 和 Manage mapping (管理映射)。然后,添加
IAMLimitedUserRole
的 ARN 作为外部身份,并选择 Map。 -
在新的私有浏览器窗口中,导航到 Kibana,使用
limited-user
进行登录,然后选择 Explore on my own (自行浏览). -
选择 Dev Tools (开发人员工具),然后运行默认搜索:
GET _search { "query": { "match_all": {} } }
请注意权限错误。
limited-user
无权运行集群范围的搜索。 -
运行另一个搜索:
GET kibana_sample_data_flights/_search { "query": { "match_all": {} } }
请注意,在所有匹配的文档中,有一个为
FlightDelay
的true
字段,一个匿名化的Dest
字段,但没有FlightNum
字段。 -
在原始浏览器窗口中,以
master-user
身份登录,选择 Dev Tools (开发人员工具),然后执行相同的搜索。请注意权限、命中数、匹配文档和包含字段的差异。
教程:内部用户数据库和 HTTP 基本身份验证
本教程介绍了另一个常见的使用案例:内部用户数据库和针对 Kibana 的 HTTP 基本身份验证中使用的主用户。
开始使用精细访问控制
-
使用以下设置创建域
-
Elasticsearch 7.9
-
公有访问权限
-
对内部用户数据库中的主用户的精细访问控制(对于本教程的其余部分,为
TheMasterUser
-
Amazon Cognito 用于 Kibana 的 身份验证已禁用
-
以下访问策略:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:ESHttp*" ], "Resource": "arn:aws:es:
region
:account
:domain/domain-name
/*" } ] } -
所有到达域的流量所需的 HTTPS
-
节点到节点加密
-
静态数据加密
-
-
导航到 Kibana。
-
使用 进行登录。
TheMasterUser
. -
选择 Try our sample data (试用我们的示例数据).
-
添加示例飞行数据。
-
依次选择 Security (安全性)、Internal users (内部用户) 和 Create internal user (创建内部用户)。
-
将用户命名为
new-user
并指定密码。然后选择 Create (创建). -
依次选择 Roles (角色)、Create role (创建角色).
-
将角色命名为
new-role
. -
对于索引权限,请为索引模式指定
kibana_sample_data_fli*
。 -
对于操作组,选择 read (读取)。
-
对于 Document Level Security Query (文档级安全查询),请指定以下查询:
{ "match": { "FlightDelay": true } }
-
对于字段级安全性,请选择 Exclude fields (排除字段) 并指定
FlightNum
。 -
对于 Anonymize fields (匿名化字段),指定
Dest
。 -
选择创建.
-
选择 Mapped users (映射的用户)、Manage mapping (管理映射)。然后,将
new-user
添加到 Users (用户),并选择 Map (映射)。 -
返回角色列表并选择 kibana_user。依次选择 Mapped users (映射的用户) 和 Manage mapping (管理映射)。然后,将
new-user
添加到 Users (用户),并选择 Map (映射)。 -
在新的私有浏览器窗口中,导航到 Kibana,使用
new-user
进行登录,然后选择 Explore on my own (自行浏览). -
选择 Dev Tools (开发人员工具) 并运行默认搜索:
GET _search { "query": { "match_all": {} } }
请注意权限错误。
new-user
无权运行集群范围的搜索。 -
运行另一个搜索:
GET kibana_sample_data_flights/_search { "query": { "match_all": {} } }
请注意,在所有匹配的文档中,有一个为
FlightDelay
的true
字段,一个匿名化的Dest
字段,但没有FlightNum
字段。 -
在原始浏览器窗口中,以
TheMasterUser
身份登录,选择 Dev Tools (开发人员工具) 并执行相同的搜索。请注意权限、命中数、匹配文档和包含字段的差异。
Limitations
精细访问控制具有几个重要限制:
-
如果域位于 VPC 中,则角色映射的
hosts
部分(将角色映射映射到主机名或 IP 地址)会不起作用。您仍可以将角色映射到用户和后端角色。 -
内部用户数据库中的用户无法更改其自己的密码。主用户(或具有等效权限的用户)必须自行更改其密码。
-
如果您为主用户选择 IAM,但不启用 Amazon Cognito 或 SAML 身份验证,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 重新配置它。
修改主用户(控制台)
-
转至 https://aws.amazon.com
,然后选择 Sign In to the Console (登录控制台). -
在 Analytics (分析) 下,选择 Elasticsearch Service.
-
选择您的域。
-
选择 Actions (操作)、Modify authentication (修改身份验证)。
-
选择 Set IAM role as master user (将 IAM 角色设置为主用户) 或 Create new master user (创建新的主用户).
-
如果您之前使用了 IAM 主用户,则精细访问控制会将
all_access
角色重新映射到您指定的新 IAM ARN。 -
如果您之前使用了内部用户数据库,则精细访问控制会创建一个新的主用户。您可以使用新的主用户删除旧的主用户。
-
从内部用户数据库切换到 IAM 主用户不 从内部用户数据库中删除任何用户。相反,它只是禁用 HTTP 基本身份验证。从内部用户数据库中手动删除用户,或者保留它们,以防您需要重新启用 HTTP 基本身份验证。
-
-
选择 Submit.
其他主用户
在创建域时指定主用户,但如果需要,可以使用此主用户创建其他主用户。您有两种选择:Kibana 或 REST API。
-
在 Kibana 中,依次选择 Security (安全性) 和 Role Mappings (角色映射),然后将新的主用户映射到
all_access
和security_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 角色向域发送已签名请求,如中所述。注册手动快照存储库.
Integrations
如果您将其他 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
请求以验证预期请求正文。例如,对 GET
的 _opendistro/_security/api/user
请求将返回所有用户,然后您可以修改并使用这些用户来发出有效的 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'