目录

对Elasticsearch和Active Directory之间的通信进行加密

为了保护发送给身份验证的用户凭据，强烈建议对Elasticsearch和Active Directory服务器之间的通信进行加密。通过SSL/TLS连接可以确保Active Directory服务器的身份在X-Pack安全传输用户凭据之前得到验证，并在传输过程中对用户名和密码进行加密。

通过SSL/TLS连接到Active Directory服务器的客户机和节点需要将Active Directory服务器的证书或服务器的根CA证书安装在它们的密钥存储库或信任存储库中。

1、在elasticsearch.yml文件中为xpack.security.authc.realms命名空间创建域配置。参见 Configuring an Active Directory realm。

2、在领域配置中设置url属性，以指定LDAPS协议和安全端口号。例如，url: ldaps://ad.example.com:636

3、将每个节点配置为信任证书颁发机构(CA)签署的证书，该证书签署了Active Directory server证书。
下面的示例演示如何信任位于配置目录中的CA证书(cacer .pem)：

xpack:
　security:
　　authc:
　　　realms:
　　　　active_directory:
　　　　　type: active_directory
　　　　　order: 0
　　　　　domain_name: ad.example.com
　　　　　url: ldaps://ad.example.com:636
　　　　　ssl:
　　　　　　certificate_authorities: [ "ES_PATH_CONF/cacert.pem" ]

CA证书必须是PEM编码的证书。
有关这些设置的更多信息，参见Active Directory realm settings

4、重启Elasticsearch

注意：默认情况下，当您使用SSL/TLS配置X-Pack安全性以连接到Active Directory时，X-Pack安全性尝试使用证书中的值验证域配置中的url属性指定的主机名或IP地址。如果证书和域配置中的值不匹配，X-Pack安全性不允许连接到Active Directory服务器。这样做是为了防止中间人的攻击。如果需要，可以通过设置ssl.verification_mode属性为certificate禁用此行为。

对Elasticsearch和LDAP之间的通信进行加密

为了保护发送到LDAP域中进行身份验证的用户凭据，强烈建议加密Elasticsearch和LDAP服务器之间的通信。通过SSL/TLS连接可以确保在X-Pack安全传输用户凭证和加密连接内容之前验证LDAP服务器的身份。通过TLS连接到LDAP服务器的客户机和节点需要将LDAP服务器的证书或服务器的根CA证书安装在它们的密钥存储库或信任存储库中。

更多信息，参见Configuring an LDAP realm

1、在每个节点上配置域的TLS设置，以信任由签署LDAP服务器证书的CA签名的证书。下面的示例演示如何信任位于X-Pack配置目录中CA证书cacert.pem：

xpack:
　security:
　　authc:
　　　realms:
　　　　ldap1:
　　　　　type: ldap
　　　　　order: 0
　　　　　url: "ldaps://ldap.example.com:636"
　　　　　ssl:
　　　　　　certificate_authorities: [ "ES_PATH_CONF/cacert.pem" ]

CA证书必须是PEM编码的。
*注意：您还可以指定单个服务器证书，而不是CA证书，但是只有在您拥有单个LDAP服务器或证书是自签名的情况下，才建议这样做。

2、在领域配置中设置url属性，以指定LDAPS协议和安全端口号。例如，url: ldaps://ldap.example.com:636

3、重启Elasticsearch。

注意：默认情况下，当您使用SSL/TLS配置X-Pack安全性以连接到LDAP服务器时，X-Pack安全性尝试使用证书中的值验证域配置中的url属性指定的主机名或IP地址。如果证书和领域配置中的值不匹配，X-Pack安全性不允许连接到LDAP服务器。这样做是为了防止中间人的攻击。如果需要，可以通过设置ssl.verification_mode属性为certificate禁用此行为。

在一个ELasticsearch Docker容器中加密通信

从版本6.0.0开始，X-Pack安全性(黄金用户、白金用户或企业订阅)要求传输网络层使用SSL/TLS加密。

本节演示了一个使用Elasticsearch Docker映像为HTTPS和传输启动SSL/TLS的简单方法。该示例使用Docker组合来管理容器。

更多细节，请参考Encrypting Communications和available subscriptions

准备环境

Install Elasticsearch with Docker

在一个新的空目录中，创建以下四个文件：
instances.yml：

instances:
　- name: es01
　　dns:
　　　- es01 #1
　　　- localhost
　　ip:
　　　- 127.0.0.1
　- name: es02
　　dns:
　　　- es01
　　　- localhost
　　ip:
　　　- 127.0.0.1

#1：允许使用嵌入式Docker DNS服务器名称

.env：

CERTS_DIR=/usr/share/elasticsearch/config/certificates #1
ELASTIC_PASSWORD=PleaseChangeMe #2

#1：Docker映像中的路径，希望在其中找到证书。
#2：elastic用户的初始密码。

create-certs.yml：

version: '2.2'
services:
　create_certs:
　　container_name: create_certs
　　image: docker.elastic.co/elasticsearch/elasticsearch:6.5.3
　　command: >
　　　bash -c '
　　　　if [[ ! -d config/certificates/certs ]]; then
　　　　　mkdir config/certificates/certs;
　　　　fi;
　　　　if [[ ! -f /local/certs/bundle.zip ]]; then
　　　　　bin/elasticsearch-certgen --silent --in config/certificates/instances.yml --out config/certificates/certs/bundle.zip;
　　　　　unzip config/certificates/certs/bundle.zip -d config/certificates/certs;　　#1
　　　　fi;
　　　　　chgrp -R 0 config/certificates/certs
　　　'
　　user: ${UID:-1000}
　　working_dir: /usr/share/elasticsearch
　　volumes: ['.:/usr/share/elasticsearch/config/certificates']

#1：新的节点证书和CA证书+密钥放在本地目录certs下。

docker-compose.yml：

version: '2.2'

services:
  es01:
    container_name: es01
    image: docker.elastic.co/elasticsearch/elasticsearch:6.5.3
    environment:
      - node.name=es01
      - discovery.zen.minimum_master_nodes=2
      - ELASTIC_PASSWORD=$ELASTIC_PASSWORD    `#1`
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - xpack.license.self_generated.type=trial     `#2`
      - xpack.security.enabled=true
      - xpack.security.http.ssl.enabled=true
      - xpack.security.transport.ssl.enabled=true
      - xpack.security.transport.ssl.verification_mode=certificate     `#3`
      - xpack.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
      - xpack.ssl.certificate=$CERTS_DIR/es01/es01.crt
      - xpack.ssl.key=$CERTS_DIR/es01/es01.key
    volumes: ['esdata_01:/usr/share/elasticsearch/data', './certs:$CERTS_DIR']
    ports:
      - 9200:9200
    healthcheck:
      test: curl --cacert $CERTS_DIR/ca/ca.crt -s https://localhost:9200 >/dev/null; if [[ $$? == 52 ]]; then echo 0; else echo 1; fi
      interval: 30s
      timeout: 10s
      retries: 5
  es02:
    container_name: es02
    image: docker.elastic.co/elasticsearch/elasticsearch:6.5.3
    environment:
      - node.name=es02
      - discovery.zen.minimum_master_nodes=2
      - ELASTIC_PASSWORD=$ELASTIC_PASSWORD
      - discovery.zen.ping.unicast.hosts=es01
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - xpack.license.self_generated.type=trial
      - xpack.security.enabled=true
      - xpack.security.http.ssl.enabled=true
      - xpack.security.transport.ssl.enabled=true
      - xpack.security.transport.ssl.verification_mode=certificate
      - xpack.ssl.certificate_authorities=$CERTS_DIR/ca/ca.crt
      - xpack.ssl.certificate=$CERTS_DIR/es02/es02.crt
      - xpack.ssl.key=$CERTS_DIR/es02/es02.key
    volumes: ['esdata_02:/usr/share/elasticsearch/data', './certs:$CERTS_DIR']
  wait_until_ready:
    image: docker.elastic.co/elasticsearch/elasticsearch:6.5.3
    command: /usr/bin/true
    depends_on: {"es01": {"condition": "service_healthy"}}
volumes: {"esdata_01": {"driver": "local"}, "esdata_02": {"driver": "local"}}

#1：用.env中的密码引导elastic。参见 the Elastic Bootstrap Password
#2：自动生成和应用试用版订阅，以启用X-Pack安全性。
#3：禁用节点间通信的真实性验证。允许创建自签名证书，而无需固定特定的内部IP地址。

运行这个例子

1、生成证书(只需要一次)：

docker-compose -f create-certs.yml up

2、启动为SSL/TLS配置的两个Elasticsearch节点：

docker-compose up -d

3、通过SSL/TLS使用引导密码访问Elasticsearch API：

curl --cacert certs/ca/ca.crt -u elastic:PleaseChangeMe https://localhost:9200

4、elasticsearch-setup-passwords工具可以用来为所有用户生成随机密码：
警告：不运行PowerShell的Windows用户需要删除下面代码片段中的\和连接线。

docker exec es01 /bin/bash -c "bin/elasticsearch-setup-passwords
auto --batch
-Expack.ssl.certificate=certificates/es01/es01.crt
-Expack.ssl.certificate_authorities=certificates/ca/ca.crt
-Expack.ssl.key=certificates/es01/es01.key
--url https://localhost:9200"

为更强的加密启用密码套件

TLS和SSL协议使用一个密码套件来确定用于保护数据的加密强度。您可能希望在使用Oracle JVM时增强加密的强度；IcedTea OpenJDK没有这些限制。成功使用加密通信此步骤不是必须的。

Java加密扩展(JCE)无限制强度管辖策略文件允许在需要添加到Java安装中的单独JAR文件中为Java使用额外的密码套件。您可以从Oracle的下载页面下载这个JAR文件。密钥长度大于128位的加密需要JCE无限强度管辖策略文件，如256位AES加密。

安装之后，JCE中的所有密码套件都可以使用，但是需要配置才能使用它们。要启用具有X-Pack安全性的更强的密码套件，请配置cipher_suites参数。具体参数信息，参见 Default TLS/SSL settingsedit。

注意：必须在集群中的所有节点上安装JCE Unlimited Strength管辖策略文件，以提高加密强度。

分离节点到节点和客户端流量编辑

Elasticsearch具有所谓TCP传输配置文件的特性，允许它绑定到多个端口和地址。X-Pack安全性扩展了这个功能，通过支持节点到节点的传输流与客户机传输流的分离，增强集群的安全性。如果客户机传输流量不受信任，并且可能是恶意的，那么这一点非常重要。要将节点到节点的流量与客户端流量分离，请将以下内容添加到elasticsearch.yml：

transport.profiles.client: #1
　port: 9500-9600 #2
　xpack.security:
　　type:client #3

#1：client是这个示例概要文件的名字
#2：端口范围将用于传输客户机与此集群的通信
#3：将概要文件分类为client。通过拒绝来自该概要文件的内部集群操作(例如，碎片级动作和ping请求)的请求尝试，这可以解释额外的安全筛选。

如果您的环境支持，可以通过向elasticsearch.yml中添加以下内容，将内部网络用于节点到节点的流量，并将公共网络用于客户端流量：

transport.profiles.default.bind_host: 10.0.0.1 #1
transport.profiles.client.bind_host: 1.1.1.1 #2

#1：用于节点到节点通信的网络的绑定地址
#2：用于客户端通信的网络的绑定地址

如果没有独立的网络，则可以启用IP过滤来限制对概要文件的访问。

当使用SSL进行传输时，还可以通过向elasticsearch.yml中添加以下内容来为客户机通信使用另一组证书：

transport.profiles.client.xpack.security.ssl.truststore:
　　path: /path/to/another/truststore #1
　　password: x-pack-test-password #2

transport.profiles.client.xpack.security.ssl.keystore:
　　path: /path/to/another/keystore #3
　　password: x-pack-test-password #4

#1：另一个信任存储库的路径
#2：其对应的密码
#3：另一个秘钥存储库路径
#4：其对应的密码

要更改传输客户机需要证书的默认行为，请在elasticsearch.yml文件中设置以下值：

transport.profiles.client.xpack.security.ssl.client_authentication: none

此设置使证书身份验证对于节点到节点的通信保持活动状态，但是取消了向传输客户机分发签名证书的要求。更多信息，参见Configuring the Transport Client to work with a Secured Cluster。

配置Active Directory域

您可以配置X-Pack安全性来与Active Directory通信以验证用户。要与Active Directory集成，需要配置active_directory领域，并将Active Directory用户和组映射到角色映射文件中的X-Pack安全角色。

有关Active Directory领域的更多信息，参见 Active Directory User Authentication。

1.在elasticsearch.yml文件中在xpack.security.authc.realms命名空间下，增加active_directory类型的域配置。在最低限度上， 你必须设置域的type为active_directory并且指定Active Directory的domain_name。如果你正在配置多个域，您还应该显式地设置order属性，以控制在身份验证期间查询领域的顺序。

参考 Active Directory realm settings查看你可以为active_directory域设置的所有选项。

注意： 如果域名没有映射到DNS中，则绑定到Active Directory失败。如果Windows DNS服务器不提供DNS，请在本地/etc/hosts文件中添加该域的映射。

例如，以下领域配置配置X-Pack security连接ldaps://example.com:636，通过Active Directory对用户进行身份验证:

xpack:
　security:
　　authc:
　　　realms:
　　　　active_directory:
　　　　　type: active_directory
　　　　　order: 0 #1
　　　　　domain_name: ad.example.com
　　　　　url: ldaps://ad.example.com #2

#1：领域顺序控制在对用户进行身份验证时检查配置的领域的顺序。
#2：如果不指定URL，默认为ladp:<domain_name>:389.

重要当您在elasticsearch.yml中配置领域时，只有您指定的领域用于身份验证。如果您还想使用本机或文件领域，则必须在领域链中包含它们。

2、如果在一个林中跨多个域对用户进行身份验证，则需要额外的步骤。在配置和用户身份验证方式方面有一些细微的差异。

将设置domain_name设置项为森林根域名。

您还必须设置url设置，因为您必须根据全局编录进行身份验证，全局编录使用不同的端口，可能不会在每个域控制器上运行。

例如，以下领域配置配置X-Pack安全性，以连接到全局编录端口上的特定域控制器，域名设置为forest根:

xpack:
　security:
　　authc:
　　　realms:
　　　　active_directory:
　　　　　type: active_directory
　　　　　order: 0
　　　　　domain_name: example.com #1
　　　　　url: ladps://dc1.ad.example.com:3269, ldaps://dc2.ad.example.com:3269 #2
　　　　　load_balance:
　　　　　　type: "round_robin" #3

#1：domain_name设置为林中根域的名称。
#2：本例中使用的url值包含两个不同域控制器的url，这两个域控制器也是全局编录服务器。端口3268是与全局编录进行未加密通信的默认端口;端口3269是SSL连接的默认端口。正在连接的服务器可以位于林中的任何域，只要它们也是全局编录服务器。
#3：在选择要连接的服务器时，提供了负载平衡设置来指示所需的行为。

在此配置中，用户需要使用完整用户主体名称(UPN)或低级登录名称。UPN通常是用户名与@<DOMAIN_NAME>的连接例如johndoe@ad.example.com。下一级登录名是NetBIOS域名，后面是一个**和用户名，如AD\johndoe。使用低级登录名需要连接到常规LDAP端口(389或636)，以便查询配置容器以从NetBIOS名称检索域名。

3、（可选的）配置X-Pack安全性应该如何与多个Active Directory服务器交互。

load_balance.type设置可以在领域级别使用。支持两种操作模式:故障转移和负载平衡。参见：Active Directory realm settings

4、(可选的)保护密码，参见encrypt communications between Elasticsearch and the Active Directory server

5、重启Elasticsearch

6、配置绑定用户。
Active Directory领域使用LDAP绑定请求对用户进行身份验证。默认情况下，所有LDAP操作都由X-Pack安全性正在验证的用户运行。在某些情况下，普通用户可能无法访问Active Directory中的所有必需项，需要绑定用户。绑定用户可以配置，并用于执行LDAP绑定请求之外的所有操作，LDAP绑定请求是对用户提供的凭据进行身份验证所必需的。

绑定用户的使用使run as特性能够与Active Directory领域一起使用，并能够维护到Active Directory的一组池连接。这些池连接减少了每次用户身份验证必须创建和销毁的资源数量。

下面的示例通过bind_dn和secure_bind_password设置的用户显示绑定用户的配置：

xpack:
　security:
　　authc:
　　　realms:
　　　　active_directory:
　　　　　type: active_directory
　　　　　order: 0
　　　　　domain_name: ad.example.com
　　　　　url: ldaps://ad.example.com:63６
　　　　　bind_dn: es_svc_user@ad.example.com　　#1

#1：这是执行所有Active Directory搜索请求的用户。在没有配置绑定用户的情况下，所有请求都作为使用Elasticsearch进行身份验证的用户运行。

bind_dn用户的密码应该通过向Elasticsearch密钥存储区添加适当的secure_bind_password设置来配置。下面的命令为上面的示例域添加密码：

bin/elasticsearch-keystore add
xpack.security.authc.realms.active_directory.secure_bind_password

在配置绑定用户时，默认情况下启用连接池。可以使用user_search.pool.enabled设置禁用连接池。

7、将Active Directory用户和组映射到角色。
领域身份验证过程的一个重要部分是解析与经过身份验证的用户关联的角色。角色定义用户在集群中的特权。

因为使用active_directory领域，用户在Active Directory服务器中进行外部管理，所以期望他们的角色也在那里进行管理。事实上，Active Directory支持组的概念，组通常表示组织中不同系统的用户角色。

active_directory域允许您通过Active Directory组或其他元数据将Active Directory用户映射到角色。可以通过角色映射api或使用存储在每个节点上的文件配置此角色映射。当用户根据Active Directory域进行身份验证时，该用户的特权是由用户映射到的角色定义的所有特权的联合。

在映射定义中，可以使用组的专有名称指定组。例如，下面的映射配置将Active Directory admins组映射到监视和用户角色，将用户组映射到用户角色，并将John Doe用户映射到用户角色。

通过角色映射API配置：

curl -X PUT "localhost:9200/_xpack/security/role_mapping/admins" -H 'Content-Type: application/json' -d'
　{
　　"roles" : [ "monitoring" , "user" ],
　　"rules" : { "field" : {
　　　"groups" : "cn=admins,dc=example,dc=com" 　　#1
　　} },
　　"enabled": true
}
'

#1：管理员组的活动目录专有名称(DN)。

curl -X PUT "localhost:9200/_xpack/security/role_mapping/basic_users" -H 'Content-Type: application/json' -d'
{
　"roles" : [ "user" ],
　"rules" : { "any": [
　　{ "field" : {
　　　"groups" : "cn=users,dc=example,dc=com" 　　#1
　　} },
　　{ "field" : {
　　　"dn" : "cn=John Doe,cn=contractors,dc=example,dc=com" #2
　　} }
　] },
　"enabled": true
}
'

#1：用户组的活动目录专有名称(DN)。
#2：用户John Doe的活动目录专有名称(DN)。

或者，也可以通过角色映射文件配置：

monitoring: #1
　- "cn=admins,dc=example,dc=com" #2
user:
　- "cn=users,dc=example,dc=com" #3
　- "cn=admins,dc=example,dc=com"
　- "cn=John Doe,cn=contractors,dc=example,dc=com" #4

#1：角色的名称。
#2：管理员组的活动目录专有名称(DN)。
#3：用户组的活动目录专有名称(DN)。
#4：用户John Doe的活动目录专有名称(DN)。

更多信息，参见Mapping users and groups to roles。

8、(可选)在Active Directory域中配置metadata设置，以便在用户的元数据中包含额外的属性。

默认情况下，ldap_dn和ldap_groups填充在用户的元数据中。更多信息，参见 User Metadata in Active Directory Realms。

下一章 —— Elasticsearch学习笔记（12）