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: "<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: "<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索引进行查找，查找失败：

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