elk笔记18--Secure a cluster
- 1 es secure 简介
- 1.1 概述
- 1.2 安全配置
- 1.3 es 安全工作原理
- 2 常见 secure 功能
- 2.1 User authentication
- 2.2 Configuring SAML single-sign-on on the Elastic Stack
- 2.3 Configuring single sign-on to the Elastic Stack using OpenID Connect
- 2.4 User authorization
- 2.5 Auditing security events
- 2.6 Encrypting communications
- 2.7 Cross cluster search, clients, and integrations
- 3 案例及注意事项
- 3.1 Tutorial: Getting started with security
- 3.2 Tutorial: Encrypting communications
- 3.3 Troubleshooting
- 3.4 Limitations
- 4 说明
1 es secure 简介
本文主要用于介绍es安全机制，以及实际中的操作步骤和注意事项；当前更新了一部分，后续会持续在此基础上补充完善相关内容。
1.1 概述
ES 通过以下 3 种方式来保护集群的安全：
1）通过密码保护、角色访问控制和 IP 过滤的方式防止未认证的访问；
2）通过SSL / TLS加密保持数据的完整性
3）维护审计跟踪，以便于知道哪些用户在集群上做来哪些操作，存储来哪些数据
1.2 安全配置
Elastic Stack 安全特性让用户非常容易地保护一个集群的安全。用户既可以通过密码来保护数据，也可以通过加密通信、基于角色访问控制、IP 过滤和审计 等高级安全策略来保护集群安全。
es 的安全配置包含以下常见步骤：
1）确认使用的许可证包含所需的特定安全功能；
2）验证每个节点上 xpack.security.enabled 设置为true，基础或者试用许可证中该参数默认为false；
3）验证是否计划在 Federal Information Processing Standard (FIPS) 140-2 enabled JVM 中运行es；
4）对内部节点通信配 TLS/SSL;
5）若未运行es，则先启动es；
6）设置所有内置用户的密码；
7）选择要用于验证用户身份的领域类型；
8）设置角色和用户来控制访问es；
9）启用审计功能，以便于跟踪与es集群的尝试或者成功的交互(可选)。
1.3 es 安全工作原理
es 集群很典型地通过很多移动的组件构成。通常情况下，多个es节点、logstash实例，kibana 实例、Beadts agents 和 客户端都会和集群通信。因此要保护这样一个集群的安全就需要考虑很多方面和层次的内容，这也就就不足为奇了。
Elastic Stack 安全特性提供如下几种方式从不同层面来保护es集群的安全：
1）用户认证；
2）用户认证和访问控制；
3）节点/客户端认证 和通信通道加密；
4）审计。
2 常见 secure 功能
2.1 User authentication
认证用于标识一个个体。当用户需要访问受限制的资源后，其必须通过某种方式证明其身份，例如密码、证书、或者其它的方式(认证tokens)。
es 中就可以使用原生支持的方式管理和认证用户，也可以继承外部用户管理系统来实现认证, 录入LDAP或者Active Directory。
Elastic Stack 安全特性提供来很多内部的认证领域，例如 native,ldap, active_directory, pki, file, saml, and oidc. 若上述都不满足用户需求，用户也可以创建自己特有的认证领域，并将其集成到 Elastic Stack 中。
2.2 Configuring SAML single-sign-on on the Elastic Stack
使用Elasticsearch作为后端服务, es 中可以配置SAML SSO，其支持将SAML单点登录（SSO）导入Kibana。 用SAML术语来说，Elastic Stack将作为服务提供者来运行。
启用SAML单点登录所需的另一个组件是Identity Provider，该服务可处理认证并执行用户的实际身份验证。
2.3 Configuring single sign-on to the Elastic Stack using OpenID Connect
es 也支持通过结合 OpenID 和 kibana 来实现登陆，这种方式把es做为保留大多数功能的后端服务。该方式下，kibana和es共同代表一个 OpenID Connect Relying Party (RP) ，该RP支持OpenID Connect 规范中定义的Authorization Code Flow。
2.4 User authorization
Elastic Stack 特性提供了认证功能，认证的过程决定了即将到来请求的用户是否被允许执行某个请求。当用户被识别和认证后，才会执行相应的请求。
es 的安全特性提供了一种基于用户访问控制的机制，该机制允许用户对角色授权、分配角色给指定用户和群组，其架构图如下所示：
该认证过程涉及到如下 6 个部分：
受保护的资源指的是被限制访问的资源，Indices, aliases, documents, fields, users 和 es 集群自身都是受保护的对象。
特权指的是对受保护资源执行的一个或多个操作的命名组。在es中，每个受保护的资源都有自己的可用特权集。例如，read是一个索引特权，它表示允许读取索引/存储数据的所有操作。特性相关的完整信息可参考7.2/security-privileges。
权限指的是对一个受保护的资源可以执行的一个或者多个特权的集合。例如：
对products索引的读权限;
对特定集群的管理权限;
对用户john的run_as 权限;
对所有匹配到 查询X 的文档的读权限;
对credit_card 字段的读权限;
角色指的是多个权限的命名集合;
用户指的是被授权认证的用户。
群组指的是一个用户所属的一个或者多个群组; 7.2 版本的群组暂时不支持 native, file, or PKI 等认证领域。
2.5 Auditing security events
es 可以通过允许审计功能来追踪安全相关的事件，例如认证失败、拒绝连接等。记录这些事件可以使集群管理员能够监视集群的可疑活动，并在发生攻击时提供证据。
默认情况下es没有开启审计日志，需要用户在 elasticsearch.yml 中配置 xpack.security.audit.enabled: true 。
2.6 Encrypting communications
Elasticsearch节点存储可能是机密的数据，这些数据可能受到来自网络的攻击。这些攻击可能包括嗅探数据、操纵数据，并试图访问服务器，从而访问存储数据的文件。因此，保护集群中节点有助于减少来自基于网络攻击的风险。
es 中可以通过设置 SSL/TLS 来实现加密通信。具体包括生成节点证书、配置集群加密通信、配置监控特性、配置kibana的安全、配置logstash的安全、配置Beats的安全，以及java客户端安全、ES for hadoop的安全等内容。
具体配置指引信息见 Setting up TLS on a cluster ， 也可以参考本文的 3.2 来配置集群的加密通信。
2.7 Cross cluster search, clients, and integrations
当配置了跨集群搜索后，需要对互联的集群进行一些额外配置。
方法1：对2个集群使用相同的认证证书（推荐在实际业务中使用该方法）;
方法2：在2个集群中创建相同的用户，并且需要在远程集群配置配置该用户的访问权限;
相关配置方法参考：7.2/cross-cluster-configuring
3 案例及注意事项
3.1 Tutorial: Getting started with security
此处使用单个节点，通过一个综合案例来熟悉es的安全配置，从最基本的节点属性配置，到生成用户密码、配置kibana用户和角色、配置logstash output等多个安全配置。
xpack.security.enabled: true
重启es，并开始创建密码, 此时会让用户逐一输入密码，笔者全部使用 elastic 做为密码：
./bin/elasticsearch-setup-passwords interactive
注:7.2.1 保留用户包括 elastic,apm_system,kibana,logstash_system,beats_system,remote_monitoring_user 6种；
elasticsearch.password: "elastic"
./bin/kibana-keystore add elasticsearch.username (会提示输入用户名 kibana)
./bin/kibana-keystore add elasticsearch.password (会提示输入密码 elastic)
此处输入 用户名：elastic 和 密码：elastic 即可正常登陆了，效果如下图；
同样使用curl时候也需要输入用户名和秘密，一般使用-u参数加上用户名和秘密即可，例如： curl -u elastic:elastic 10.120.75.102:9204
正常情况下需要在 elasticsearch.yml 中添加 xpack.security.authc.realms设置，但是在没有配置其它认证领域时，原生的认证领域默认是可用的，因此不需要额外配置。
在 Management / Security / Users 页面可以创建用户，也可以看到当前用户信息，如下图：
设置 jdoe 为 kibana_user 角色，此时 jdoe 可以正常登陆；此时其基具备了所有的kibana使用权限，Security中的users和roles除外。
添加 metricbeat_writer 角色，具备 cluster 的 manage_index_templates and monitor cluster privileges, as well as write, delete, and create_index privileges on the metricbeat-* indice；将 logstash_internal 用户授权该角色；
添加 metricbeat_reader 角色，具备read and view_index_metadata privileges on the metricbeat-* indices；将 jdoe 授权该角色；
8）在 logstash 中添加用户信息
添加认证后，logstash的output如果不设置user和password则无法正常访问es，因此实际中可以按照如下方式配置logstash的认证信息：
output {
elasticsearch {
hosts => "localhost:920" #此处端口需要根据实际业务调整
manage_template => false
index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}"
user => "logstash_internal"
password => "111111"
}
}
3.2 Tutorial: Encrypting communications
此处使用3个节点构成一个继续，集群间一方面需要加密通信，另一方面需要用户认证；此处案例更加符合实际生产配置，因此没有完全按照官方步骤来操作。
bin/elasticsearch-certutil ca
Please enter the desired output file [elastic-stack-ca.p12]: 空白
Enter password for elastic-stack-ca.p12 : 空白,生成目录就是es的根目录
bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
Enter password for CA (elastic-stack-ca.p12) : 空白
Please enter the desired output file [elastic-certificates.p12]: 空白
Enter password for elastic-certificates.p12 : 空白
此处生成的证书没有设置dns和ip限制，因此可以直接拷贝到集群的所有节点统一使用。
将 步骤2 生成的文件拷贝到另外2个节点
mkdir -p config/certs
es节点添加如下内容：
xpack.security.enabled: true # 如果注释掉这一步，集群可以加密通信，但是需要用户认证登陆，即不需要步骤5中生成密码的步骤
此处只需要在 h01 上设置，不需要3个节点都设置
bin/elasticsearch-setup-passwords interactive
笔者直接把输入密码的地方全部设为elastic
生成认证后，重启集群所有节点
kibana节点加入如下内：X
elasticsearch.username: “elastic”
elasticsearch.password: “elastic” （此处密码为步骤4中输入的密码）
重启kibana
3.3 Troubleshooting
to add
3.4 Limitations
to add
4 说明
7.2/secure-clusterEncrypting communications in Elasticsearchdocker+elk7.8实战之Elasticsearch安全配置与kibana配套修改
测试环境为 es 7.2.1