Elasticsearch的LDAP统一认证服务集成

ldap（Light Directory Access Portocol）是基于X.500标准的轻量级目录访问协议。LDAP协议使用了一种树状的数据形式，可以很方便的定义一个组织或者公司内的用户结构。基于开放的LDAP协议的LDAP服务（如Microsoft的Active Directory）可以提供用户身份验证的能力。由于LDAP的开放性，它的使用非常广泛。而elasticsearch服务，通过使用Opendistro的security插件，可以加入Active Directory作为身份验证后端，无缝接入到已有的LDAP服务中。本文会讲解Elasticsearch接入LDAP认证的基本方式，并会讲解基本原理。

一、 security插件基础

Opendistro的security插件实现了ES的安全功能，包含用户的认证的鉴权。它包含了六个配置文件:

config.yml

负责配置额外后端的认证（与内部认证相对应）和授权，如LDAP（下文会详述）、Kerberos、JWT等。

internal_users.yml

负责配置内部认证的用户和对应的密码.

roles.yml

负责配置角色和其对应的操作权限。

roles_mapping.yml

负责配置角色、用户和后端角色的映射关系。

action_groups.yml

负责配置各种不同的操作，包括集群级和索引级操作。

tenants.yml

负责配置租户信息。

这其中，除了config.yml这个核心的认证授权配置，其他配置都可以通过REST API或者Kibana页面的方式修改。想要修改config.yml，必须通过插件提供的securityadmin.sh脚本来实现：

# 将config.yml配置文件写入索引并生效 securityadmin.sh -h {{ip}} -p 9300 -f ./config.yml -icl -nhnv -cacert root-ca.pem -cert kirk.all.pem -key kirk.all.pem -t config

这个脚本会将相应的配置存在ES的特殊索引中，以实现节点间的共享。

也可以通过脚本来导出当前的配置情况：

# 将当前生效的六个配置文件导出到temp路径下 securityadmin.sh -r -h {{ip}} -p 9300 -cd ./temp -icl -nhnv -cacert root-ca.pem -cert kirk.all.pem -key kirk.all.pem

二、LDAP集成

首先打开华为云控制台创建一个Windows Server的ECS（Windows Server自带支持LDAP协议的Active Directory服务），并且创建一个云搜索服务CSS，这里选择7.1.1版本，并开启安全模式（安全模式自带Opendistro security插件）。登录ECS开启Active Directory服务，新建域，本例为test.ldap.com。新建以下管理员、用户和用户组:

然后，修改config.yml：

# 省略 authc： # 省略 ldap: description: "Authenticate via LDAP or Active Directory" http_enabled: true transport_enabled: true order: 5 http_authenticator: type: "basic" challenge: false authentication_backend: type: "ldap" config: enable_ssl: false enable_start_tls: false enable_ssl_client_auth: false verify_hostnames: true hosts: - "10.0.0.115:389" bind_dn: "CN=adminAD,DC=test,DC=ldap,DC=com" password: "" userbase: "OU=ITDepartment,DC=test,DC=ldap,DC=com" usersearch: "(sAMAccountName={0})" username_attribute: "uid" authz: roles_from_myldap: description: "Authorize via LDAP or Active Directory" http_enabled: true transport_enabled: true authorization_backend: type: "ldap" config: enable_ssl: false enable_start_tls: false enable_ssl_client_auth: false verify_hostnames: true hosts: - "10.0.0.115:389" bind_dn: "CN=adminAD,DC=test,DC=ldap,DC=com" password: "" rolebase: "OU=groups,DC=test,DC=ldap,DC=com" rolesearch: "(member={0})" userroleattribute: null userrolename: "disabled" rolename: "CN" resolve_nested_roles: true userbase: "OU=ITDepartment,DC=test,DC=ldap,DC=com" usersearch: "(uid={0})" roles_from_another_ldap: description: "Authorize via another Active Directory" http_enabled: false transport_enabled: false authorization_backend: type: "ldap"

配置文件主要分为两个部分authc和authz，其中authc(authentication, 认证)主要起到验证用户是否是其宣称的人（验证密码），authz(authorization,授权)主要起到判断当前用户是否具有相应权限的作用。

需要修改的为以下四项：hosts、bind_dn、password、userbase

hosts为Active Directory服务的地址，端口为389

bind_dn相当于LDAP的用户名（Distinguished Name），以下为X.500目录协议（包含LDAP）的相关定义：

CN = Common Name

OU = Organizational Unit

DC = Domain Component

必须按顺序一一对应，否则无法认证。

userbase为es连接上Active Directory之后获取用户所属的DN，本例中就会同步所有ITDepartment目录下的用户

authz中没有了userbase，变成了rolebase，获取的对应DN下的组，这个组会与es中的role一一对应，如下：

一个用户通过认证后通过AD查询到所属的group，再一一对应es中的role，role则又对应了action groups（如create、search等）

使用特性或者脚本将修改后的config.yml生效后，进入kibana修改roles和role_mapping:

接下来进行验证，

使用userGoogleInAD用户创建google索引，创建失败：

使用admin用户创建，创建成功:

使用userGoogleInAD用户对google索引进行查询，查询成功:

使用userTwitterInAD对google索引进行查找，查找失败：

注意到，如果用户名密码错误（不满足认证）的话，返回与不满足授权不同：

Elasticsearch 云搜索服务 CSS

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。