使用Search Guard加固Elasticsearch：用户、角色和权限

一、内部数据库

Search Guard 附带内部用户数据库，如果你没有任何外部身份验证系统（如 LDAP 或 Active Directory），则可以使用此用户数据库。用户信息及其散列密码和角色存储在群集内部的 Search Guard 索引中。

内部用户在 sg_internal_users.yml 文件中配置，你可以找到模板在<ES installation directory>/plugins/search-guard-6/sgconfig/sg_internal_users.yml。

语法：

示例：

请注意，用户名不能包含点。如果你需要带点的用户名，请使用username属性：

由于在配置 sg 时 sg_internal_users.yml 文件需要存在且不为能空，所以如果你不希望有内部用户则写入 {} 到文件中即可。

生成散列密码

你可以使用 Search Guard 附带的 hash.sh 脚本来生成它们：

这里注意一下，可能是官方写错了名字，没有名称叫 hasher.sh 的脚本，只有名称叫 hash.sh 的脚本。当然，不知道后面新版本是否会改为 hasher.sh名称。

配置

要使用内部用户数据库，请将 authentication_backend 设置为 internal 。例如，如果要使用 HTTP 基本身份验证和内部用户数据库，则配置如下所示：

授权

你还可以使用内部用户数据库进行授权，指分配后端角色。当你的主要身份验证方法不提供任何角色信息时，这非常有用。

例如，你可以使用 LDAP 或 JWT 进行身份验证，使用内部用户数据库进行授权/分配角色。

Search Guard 将使用 autenticated 用户的名称在内部用户数据库中查找相应的条目。如果找到，配置角色将被指定为该用户的后备角色。

如果仅使用内部用户数据库进行授权，则无需设置散列密码。这些条目仅用于分配后端角色。

配置：

二、操作组

操作组只是具有说明名称的权限集合，操作组在文件sg_action_groups.yml中定义，可以在 sg_roles.yml 中引用。另外，操作组也可以嵌套。

文件结构非常简单：

操作组名称不得包含点，使用操作组是为角色分配权限的首选方式。

预定义操作组

Search Guard 预定义了一个适用于大多数用例的操作组列表。

通用

索引级别

集群级别

多个和批量请求

要执行多个和批量请求，相应的用户需要具有：

• 群集级别的多个和/或批量权限。
• 索引级别的相应权限。

例如，如果用户执行包含 index1 删除请求和 index2 更新请求的批量请求，则需要三个权限：

• 群集级别的批量权限
• 删除 index1 的权限
• 写入 index2 的权限

自定义操作组

你可以在 sg_action_groups.yml 文件中定义自己的操作组，你可以使用任何你想要的名称，你还可以从另一个操作组中引用操作组：

然后，你可以通过名称在文件 sg_roles.yml 中引用这些操作组：

三、演示用户和角色

Search Guard 附带了一个演示配置，其中包含各种用例的用户和角色。你可以将这些用户和角色用作你自己的权限模式。

演示用户

Search Guard 附带以下演示用户：

Search Guard 附带以下演示角色：

注意：默认情况下，所有用户都映射到角色 sg_public 和 sg_own_index。你可以通过从 sg_roles_mapping.yml 中删除以下行来删除此映射：

默认映射到 sg_own_index 角色意味着，此用户只需要在 sg_internal_users 中定义以下用户即可。然后此用户就可以创建一个以自己名称命名的索引，并且对这个索引有所有操作权限；但无法创建其他索引且也没有权限操作。

其 sg_own_index 对应的具体角色如下（ sg_roles.yml ）：

四、定义角色和权限

Search Guard 角色及其关联权限在文件 sg_roles.yml 中定义。你可以根据需要定义任意数量的角色。定义角色并将权限与其关联的语法如下：

有关key _dls_ 和 _fls_  用于配置文档级和字段级安全性。有关详细信息，请参阅 Document- and Field-level security。

有关key tenants 用于配置Kibana多租户。有关详细信息，请参阅 Kibana multi-tenancy。

文档类型（Type）在 Elasticsearch 6 中已弃用，将使用 Elasticsearch 7 删除。Search Guard 仍支持文档类型以实现向后兼容性。此支持将在 Search Guard 7 中删除，要定义所有文档类型的权限，请使用星号（’*’）作为文档类型。

集群级别权限

群集条目用于定义群集级别的权限。群集级权限用于允许/禁止影响整个群集的操作，例如查询群集运行状况或节点统计信息。

它们还用于 allow/disallow 影响多个索引的操作，例如 mget，msearch 或 bulk 请求。

示例：

索引级别权限

索引条目用于 allow/disallow 影响单个索引的操作，你可以单独为索引中的每种文档类型定义权限。

动态索引名称：通配符和正则表达式

索引名称支持（过滤）索引别名，索引名称和文档类型条目都支持通配符和正则表达式。

• 星号（*）将匹配任何字符序列（或空序列）

*my*index将匹配my_first_index以及myindex，但不匹配myindex1。

• 问号（?）将匹配任何单个字符（但不是空字符）

?kibana将匹配.kibana但不匹配kibana。

• 正则表达式必须包含在 /:’/<java regex>/’ 中

‘/\S*/’将匹配任何非空白字符。

注意：索引名称不能包含点。相反，使用?通配符，如在kibana中。

示例：

动态索引名称：用户名替换

对于<indexname or alias>，也允许占位符 ${user.name} ，支持包含用户名的索引或别名。在评估权限期间，占位符将替换为此请求的经过身份验证的用户的用户名。

动态索引名称：用户属性

任何身份验证和授权后端都可以添加其他用户属性，然后你可以将这些属性用于变量替换。

使用操作组分配权限

Search Guard 具有对权限进行分组并为其指定名称的功能，这些组称为操作组，是为角色分配权限的首选方式。Search Guard 附带一些预定义的操作组，这些操作组将涵盖大多数用例。

示例：

使用单一权限

如果需要应用更细粒度的权限模式，Search Guard 还支持为角色分配单个权限。

单个权限以cluster: or indices: 开头，后跟 REST 样式的路径，进一步定义权限授予访问权限的确切操作。

例如，此权限将授予对索引执行搜索的权限：

此权限授予写入索引的权限：

在群集级别，此权限授予显示群集运行状况的权限：

单个权限也支持通配符，以下权限授予索引上的所有管理操作：

五、映射用户到角色

根据你的配置，你可以使用以下数据将请求分配给一个或多个 Search Guard 角色：

• username

经过身份验证的用户名称。

• backend roles

授权后端（如LDAP，JWT或内部用户数据库）获取的角色。

• hostname/IP

请求来自的主机名或IP。

• Common name

随请求一起发送的客户端证书的DN。

后端角色（backend roles）和Search Guard角色

后端角色是 Search Guard 在身份验证和授权过程中检索的角色。然后，这些角色将映射到 Search Guard 用于定义给定用户或主机拥有的权限的角色。权限本身可以在 sg_action_groups 中定义，Search Guard 角色在 sg_roles 中定义，而 sg_roles_mapping 定义了特定用户和特定角色之间的关联。

后端角色（backend roles）可以来自：

• 在 sg_config.yml 的 authz 部分中配置的 LDAP 服务器
• 在 sg_internal_users.yml 文件中为特定用户定义的角色
• 如果你正在使用 JWT 身份验证，则为 JSON Web Token
• HTTP headers，如果你正在使用代理身份验证

映射

后端用户、角色和主机映射到 Search Guard 角色，在sg_roles_mapping.yml 文件中定义。

语法：

Search Guard 角色名称不得包含点。

示例：

可以将请求分配给一个或多个 Search Guard 角色。如果请求映射到多个角色，则会合并这些角色的权限。

分配多个角色时的权限处理

用户可以根据需要拥有任意数量的角色，并为该用户分配所有角色的所有权限。但是，如果用户具有为同一索引定义不同权限的多个角色，则 Search Guard 将仅使用在第一个角色中找到的权限。

如果要组合该索引的所有权限，请在 sg_config.yml 中启用此功能，如：

这将成为 Search Guard 7 的默认行为。小于此版本的默认值为 false，以便向后兼容。

六、角色映射模式

默认情况下，Search Guard 通过将用户名，后端角色 and/or 主机名映射到一个或多个 Search Guard 角色，将每个传入请求映射到 Search Guard 角色。这是在角色映射配置中配置的。

在使用 LDAP 等外部身份验证系统时，这提供了极大的灵活性，LDAP 具有自己的角色管理：例如，你可以将存储在 LDAP 中的多个后端角色映射到一个 Search Guard 角色。这同样适用于来自 JWT 或内部用户数据库的后端角色。

通过指定角色映射模式，你可以配置 Search Guard 映射后端角色的方式。这可以通过设置在 elasticsearch.yml 中配置：

Mode: MAPPING_ONLY

这是默认值，表示所有后端角色都通过角色映射进行映射，如上所述。如果 sg_roles_mapping.yml 文件中没有特定后端角色的条目，则它不会映射到任何 Search Guard 角色。

Mode: BACKENDROLES_ONLY

后端角色直接映射到 Search Guard 角色，有效地完全跳过角色映射。如果使用此设置，则可以直接在 sg_roles.yml 文件中使用后端角色的名称，但不会进行其他映射。

例如，如果你的 LDAP 返回角色 ldap_finance，你可以直接在 sg_roles.yml 中定义权限，如：

Mode: BOTH

在此模式下，角色通过 sg_roles_mapping.yml 映射，如MAPPING_ONLY模式，但后端角色也会添加到最终角色集中。这基本上是MAPPING_ONLY和BACKENDROLES_ONLY的组合。

假设你已经定义了一个映射：

如果你的 LDAP 返回角色 ldap_finance，则该用户将拥有两个 Search Guard 角色：

• ldap_finance：来自LDAP的角色
• sg_finance：来自LDAP的映射角色

七、权限配置实践

Search Guard 对于用户权限配置这块还是有点绕的，得真的理解各个文件之间的关系才能真的用好。我也是大概的过了一遍，简单理解。就使用本地数据库而言，大概工作原理如下图：

一个简单的需求就是对一个用户给予索引基本操作权限，并要求用户能够看索引的 settings、mapping 信息，但不包括能新增或删除索引。比较符合线上使用实践。下面分别配置一下各个文件。

sg_internal_users

sg_action_groups

sg_roles

sg_roles_mapping

都配置完成后，使用 sgadmin.sh 工具把数据加载进 Elasticsearch 即可。可以自行多试试各种权限的组合，根据自己的需求定制即可。

喜欢 (1)赏

[资助本站您就扫码 谢谢]

分享 (0)