ES安全searchguard落地实践

携程技术
1,491 阅读9分钟
作者简介  

江榕，携程信息安全部高级信息安全工程师，目前主要负责公司运维安全日志分析平台搭建、参与日常运维安全事件响应、参与运维安全评审。


1、背景


随着大数据技术在互联网行业的快速发展，应用于日志分析领域的技术趋向于多元化，而elasticsearch以其作为开源分布式搜索引擎所带来的诸多特点与优势，逐渐成为各家互联网公司实时日志分析、甚至风控离线数据分析的主要战力。


然而在享受到elasticsearch带来便利和优势的同时，不可避免地存在将elasticsearch作为db用于存储敏感信息，由于elasticsearch本身不支持安全特性，带来极大的访问控制安全风险。


为了对elasticsearch的访问控制进行安全加固，我们针对市面上的仅有两款安全插件进行调研，由于shield为收费插件，故本文仅对searchguard开源插件的配置部署及落地进行详细阐述，希望提供给各位一个快速上手配置searchguard指南。

 

search-guard 更新到2.x后与 shield配置上很相似。 除了必须的RBAC认证授权外，searchguard 优点有:


  • 节点之间的RPC流量通过 SSL/TLS 传输（强制性）；

  • 支持 JDK SSL 和 Open SSL（建议用openssl，降低性能消耗）；

  • 支持热载入；

  • 支持audit日志记录（商用功能）；

  • 支持restful接口流量加密（可选）；

  • 支持ldap认证接入（商用功能）；

  • 权限配置基本与shield保持一致；

  • 索引级别访问控制（重点！）；

  • 字段级别访问控制（商用功能）；


在我们考虑正式落地前，需要确认必要的安全特性，例如字段级别访问控制、内网restful流量加密是否必要等。结合现有业务实际场景，最后选择仅做到索引级别的访问控制，且仅加密RPC流量。


2、安装


当前配置的是es5.1.1对应的版本，故对应的配置文件安装如下:


安装search-guard-5 

https://search.maven.org/remotecontent?filepath=com/floragunn/search-guard-5/5.1.1-11/search-guard-5-5.1.1-11.zip 

bin/elasticsearch-plugininstall file:/// search-guard-5-5.1.1-11.zip


3、配置证书


下载： 

https://codeload.github.com/floragunncom/search-guard-ssl/zip/es-5.1.1 


解压文件，进入example-pki-scripts目录。


注意，该步骤用于制作节点用的truststore及keystore，故无需部署在生产节点上，创建完成上述文件后部署到对应节点即可。另外，记得备份example-pki-scripts 生成后的相关内容。


创建 root ca


调整etc/root-ca.conf及signing-ca.conf中[ ca_dn ]内容，默认如下：


[ ca_dn ]

0.domainComponent      = "com"

1.domainComponent      = "example"

organizationName       = "Example Com Inc."

organizationalUnitName  ="Example Com Inc. Root CA"

commonName             ="Example Com Inc. Root CA"


执行./gen_root_ca.shcapassword_use_a_strong_one truststorepassword 其中两个参数分别为ca密码及truststore密码，请将该密码设置足够强壮。


该操作完成后生成truststore.jks


创建 keystore


用于部署data/master节点执行命令


./gen_node_cert.sh nodenumkeystorepassword capassword_use_a_strong_one


用于部署client节点执行命令


./gen_client_node_cert.sh nodenamekeystorepassword capassword_use_a_strong_one


该操作完成后生成xxxkeystore.jks


将各自生成的truststore.jks及xxxkeystore.jks上传至各个节点的conf目录下。


4、配置elasticsearch.yml


在elasticsearch.yml进行配置：


searchguard.authcz.admin_dn:

  -cn=admin,ou=Test,ou=ou,dc=company,dc=com

searchguard.ssl.transport.keystore_filepath:xxxkeystore.jks

searchguard.ssl.transport.keystore_password:keystorepassword

searchguard.ssl.transport.truststore_filepath:truststore.jks

searchguard.ssl.transport.truststore_password:truststorepassword

searchguard.ssl.transport.enforce_hostname_verification:false


重启elasticsearch服务。


5、配置文件


searchguard 主要有5个配置文件在 plugins/search-guard-5/sgconfig 下：


sg_config.yml:

  • 功能配置文件，配置包括认证授权都多种方式的功能，在本次searchguard部署中，除了增添kibana认证外，其余不需要做改动。

sg_internal_users.yml:

  •  本地用户文件，定义用户密码以及对应的权限。例如：对于 ELK 我们需要一个 kibana 登录用户用于读，及一个 logstash 用户用于写：


Kibana5:

 hash:  $2a$12$.kM9IYaRm1uWeywD0Xyo8eynR6fAjVnHKrkxEAfIlZ1PeszTUovW6

 #password is: kibana5

 roles:

 - kibana5

logstash:

 hash:  $2a$12$pLs.IeT/Ea8w81xQPqSRwOXah6h736UVjyvaHgXp9IjNjDxjQkKb6

 roles:

 - logstash

#password is: logstash


密码hash用plugins/search-guard-5/tools/hash.sh生成。


sg_roles.yml:


  • 权限配置文件，这里提供 kibana4 和 logstash 的权限样例


sg_kibana5:

  indices:

    '*':#需要读权限目标索引，可通配

      '*':#目标 type，可通配

        -'*'# 具体权限

    '?kibana':

      '*':

        -KIBANA_SERVER

       cluster:

      - cluster:monitor/nodes/info

      - cluster:monitor/health

      - CLUSTER_MONITOR

      - CLUSTER_COMPOSITE_OPS

 

sg_logstash:

  cluster:

    - indices:admin/template/get

-indices:admin/template/put

-indices:data/write/bulk*

-CLUSTER_MONITOR

-CLUSTER_COMPOSITE_OPS

  indices:

    '*': #需要写权限目标索引，可通配

      '*': #目标 type，可通配

        -CRUD

        -CREATE_INDEX


关于详细权限，可参考shield的权限文档：

https://www.elastic.co/guide/en/shield/2.1/reference.html#ref-actions-list


sg_roles_mapping.yml:


  • 定义用户的映射关系，添加 kibana5 及 logstash 用户对应的映射：


sg_logstash:

 users:

 - logstash

sg_kibana5:

users:

 - kibana5


sg_action_groups.yml:


  • 定义权限组，将同一行为目的的权限作为权限组，降低权限复杂度。权限组直接在sg_roles内角色定义中使用，很多权限组已有定义，如KIBANA_SERVER的子权限定义如下：


KIBANA_SERVER:

 - "indices:admin/exists*"

 - "indices:admin/mapping/put*"

 - "indices:admin/mappings/fields/get*"

 - "indices:admin/refresh*"

 - "indices:admin/validate/query*"

 - "indices:data/read/get*"

 - "indices:data/read/mget*"

 - "indices:data/read/search*"

 - "indices:data/write/delete*"

 - "indices:data/write/index*"

 - "indices:data/write/update*"

 

6、加载配置并启用


在任意节点执行sgadmin命令进行配置同步：


plugins/search-guard-5/tools/sgadmin.sh -cntestcluster -cd plugins/search-guard-5/sgconfig/ -ksconfig/node-0-keystore.jks -ts config/truststore.jks  -nhnv


  • testcluster为es集群名。

  • 其中keystore为该节点上的keystore文件路径，另外建议各节点的sg配置文件统一。

  • 用户权限相关信息改动无需重启集群，仅执行上述sgadmin命令即可同步配置进es内的index。且仅需要在一台节点执行即可。


7、logstash配置


在logstash.conf中作如下设置：


output {

    elasticsearch{

       user =>logstash

       password=> logstash

       ...

    }

}


该设置中的用户名密码为sg_internal_users.yml对应用户


logstash用户名对应的权限在sg_roles.yml中设置：


sg_logstash:

  cluster:

    - indices:admin/template/get

- indices:admin/template/put

   - CLUSTER_MONITOR

   - CLUSTER_COMPOSITE_OPS

  indices:

    'logstash-*':

      '*':

        - CRUD

        - CREATE_INDEX

    '*beat*':

      '*':

        - CRUD

        - CREATE_INDEX


在sg_roles_mapping.yml设置对应的logstash映射：


sg_logstash:

users:

- logstash


sgadmin命令加载配置。


8、kibana配置

kibana.yml内作如下配置：


elasticsearch.username: "kibanaserver"

elasticsearch.password:"kibanaserver"


sg_roles作如下配置：


sg_kibana5_server:

 cluster:

      - cluster:monitor/nodes/info

      - cluster:monitor/health

      - CLUSTER_MONITOR

      - CLUSTER_COMPOSITE_OPS

 indices:

   '?kibana':

      '*':

        - ALL


sg_roles_mapping作如下配置：


sg_kibana5_server:

  users:

    -kibanaserver


sg_internal_users.yml作如下配置：


kibanaserver:

  hash:  $2a$12$4AcgAt3xwOWadA5s5blL6ev39OXDNhmOesEoo33eZtrq2N0YrU3H.

  #password is:kibanaserver


sg_config作如下配置：


authc:

      kibana_auth_domain:

        enabled:true

        order:1

        http_authenticator:

          type:basic

          challenge:true

        authentication_backend:

          type:internal


sgadmin命令加载配置。


9、searchguard集群性能测试

对于集群是否落地searchguard，可能更多考量在与是否会对性能有影响。


从searchguard工作原理上说，加入searchguard会分别从认证、授权及节点间流量加解密上有所消耗。对于性能强如物理机，认证授权这块可以忽略不计，但即使取消了restful的加密，仍然有rpc流量需要加解密（如背景中所述，该加密功能不可避免）。为了验证影响，我们采用了esrally进行相关测试。


测试方案为在两台物理机上各部署两个不同集群（有无searchguard）的节点，分别用esrally进行测试，比对测试结果如下，baseline为无searchguard集群，写入数据量为280w条，bulk size为5000，各位可以有个参考：


Metric            Operation    Baseline   Contender                 Diff    Unit

MinThroughput         index-append     26188.1     19700.9    -6487.21094  docs/s

             Median Throughput         index-append     59589.7     53227.7    -6361.99219  docs/s

                Max Throughput         index-append     63968.8     57558.9    -6409.82812  docs/s

     90.0th percentile latency         index-append     699.846     882.144     +182.29781      ms

     99.0th percentile latency         index-append     797.955     1161.74     +363.78743      ms

     100.0thpercentile latency         index-append     802.317     1236.58     +434.26428      ms

 90.0th percentile servicetime         index-append     699.846     882.144     +182.29781      ms

 99.0th percentile servicetime         index-append     797.955     1161.74     +363.78743    ms

100.0th percentile servicetime         index-append     802.317     1236.58     +434.26428   ms

 

10、结语

由于能够支持es安全方案可选少，且searchguard这类开源方案对于性能上的影响需要时间去验证（实际落地情况复杂）。对于多业务集群（存在多个角色进行集群使用且有访问控制需求），可选择尝试searchguard，即使该方案的配置有点麻烦。


推荐阅读：



少量余票，抓紧上车~

7月22日本周六，携程技术中心首场架构沙龙，邀请携程、去哪儿、新美大、唯品会小伙伴分享他们的最佳实践。等你来~


点击下图查看详情

长按识别二维码，直接报名

avatar
文章
阅读
粉丝