Elastic Stack容器化部署拓展（Https、AD域集成）并收集Cisco设备的日志信息

格洛米爱学习

已于 2022-11-21 17:40:49 修改

阅读量1.9k

点赞数 7

于 2022-11-19 22:38:05 首次发布

本文链接：https://blog.csdn.net/tushanpeipei/article/details/127934963

版权

NetDevOps 专栏收录该内容

55 篇文章 53 订阅

订阅专栏

前言：

还记得在去年的笔记中提到过EFK（Elasticsearch-Filebeat-Kibana）的部署，但是其中的内容相对简单，也没有提到一些额外的Elastic Stack的特性。链接如下：https://blog.csdn.net/tushanpeipei/article/details/117373204

前段时间为了进一步提升EFK套件的安全性和好用性，对之前的部署方案进行调整，实现了Https加密以及AD域用户的集成。因此，借着这次机会，重新梳理了一下Elastic Stack中的各个套件的用处以及其他特性的集成。

一、认识Elastic Stack

Elastic Stack之前也被称为ELK Stack。ELK是三个首字母的缩写，分别是 Elasticsearch，Logstash，Kibana。除此之外，Elastic Stask 中还包括了各种 Beats。所有涉及到的组件如图1所示：
在这里插入图片描述

图1：Elastic Stack 组件

首先，ElasticSearch作为套件的核心，是一个分布式的免费开源搜索和分析引擎（Restful风格），适用于包括文本、数字、地理空间、结构化和非结构化数据等在内的所有类型的数据。并且，Elasticsearch 会以 JSON 文档的形式存储数据。每个文档都会在一组键（字段或属性的名称）和它们对应的值（字符串、数字、布尔值、日期、数值组、地理位置或其他类型的数据）之间建立联系。此外，它的性能十分优越，与典型的 SQL 数据库在 10 秒以上检索数据相比，ElasticSearch 通过分布式倒排索引的技术，实现了可以在不到 10 毫秒的时间内完成该工作的效率巨大提升。

因此，围绕这该拳头产品，Elastic Stack的其他相关配套软件也相继被开发了出来。首先是Logstash，它可以被称为世界上最流行的日志分析平台。进一步说，Logstash 是服务器端数据处理管道（图2所示），能够通过input plugin，（详见https://www.elastic.co/guide/en/logstash/current/input-plugins.html#input-plugins）聚合来自各种来源的日志和事件能够同时从多个来源采集数据，转换数据。此外，Logstash的另一大优势是通过各种筛选器（filter plugin，详见https://www.elastic.co/guide/en/logstash/current/filter-plugins.html#filter-plugins），解析各个事件，识别已命名的字段以构建结构，并将它们转换成通用格式。最后，Logstash可以将解析后的通过output plugin（详见，https://www.elastic.co/guide/en/logstash/current/output-plugins.html）发送到数据存储库中，例如ElasticSearch。
在这里插入图片描述

图2：Logstash pipeline

通过上述两个组件，已经可以实现将日志等信息从网络设备，服务器等目标中收集，分析识别并存储到了数据库中。但是，如何将收集的信息进行可视化呈现依然没有实现。因此，Kibana 诞生了。Kibana 是一款适用于 ElasticSearch 的数据可视化和管理工具。通过读取 ElasticSearch 中收集并处理好的数据，Kibana 可以生成实时的直方图、线形图、饼状图和地图，方便运维人员进行查看和分析。简而言之，三个部件的作用如下：

Logstash将摄取、转换数据并将其发送到正确的目的地。
Elasticsearch将为摄取的数据编制索引，并且分析和搜索这些数据。
Kibana会将分析结果可视化。

到这一步，看似Elastic Stack的功能已经完善了，然而实际上还是存在一个突出的问题。这个不足在于 Logstash 的性能。首先Logstash作为一个通用的，可以针对多个用例进行配置，因此它将占用交大的系统资源。具体来说，Logstash 需要 JVM 才能运行，这种依赖性加上 Ruby 中的实现成为显着内存消耗的根本原因，尤其是在涉及多个管道和高级过滤时。因此，后续为了弥补这一缺陷，工程师们开发出来Beats工具。

简单来说，Beats 是轻量级数据发送器，运维人员可以将其作为代理安装在服务器上，以将特定类型的操作数据发送到 Elasticsearch或者Logstash。与 Logstash 相比，Beats使用的系统资源更少，性能更优。此外，Bests种类有很多，如图3所示，其中每一种Beat有着独特的功能，例如运用广泛的Filebeat是用来收集设备的日志信息。在实际部署过程中，仅需要激活所需使用的Beat即可。
在这里插入图片描述

图3：Beats 类别

加上Beats后，整体的Elastic Stack架构图如4所示。Beats作为轻量级日志传送器，通常部署在目标节点上收集所需的信息。作为单纯的传送收集器，他们并不需要解析收集到的这些数据。相比之下，Logstash则作为数据的聚合器，它监听Beats，并解析Beats收集到的信息。当 Logstash 处理完成数据后，会将处理后的数据发送到 ElasticSearch。最终 Kibana 将 ElasticSearch 中的数据可视化呈现。
在这里插入图片描述

图4：Elastic Stack 架构

最后，还有一种特殊的情况，Beats可以直接将从目标节点上收集的信息发送到ElasticSearch，跳过Logstash。在这种情况下，Beats既要收集目标的数据，也需要对这些数据进行解析。具体来说就是启动Beats中对应的模块即可。例如，在小型网络中，Filebeat可以直接收集网络设备的日志信息进行解析，然后跳过Logstash直接发送到Elasticsearch，这也是后续的实验案例。

总之，运维人员可以根据不同的具体场景，选择是否Beats和Logstash需要同时使用。根据上述的描述，我们可以整理出来三种组合：Logstash only，Beats only，Beats with Logstash。根据leandrojmp 的在stack overflow上的回答（https://stackoverflow.com/questions/58585855/difference-between-using-filebeat-and-logstash-to-push-log-file-to-elasticsearch）。以Filebeat为例，三种组合应用的场景分别是：

对于组合1，使用Logstash file输入。运维人员需要在要收集日志的机器上运行一个Logstash 实例，如果日志与我们已经在运行 Logstash 的机器在同一台机器上，这不是问题。但如果日志已打开远程机器，并不总是推荐使用 Logstash 实例，因为它比 Filebeat 需要更多的资源。
对于组合2和3，为了在远程机器上收集日志，建议使用 Filebeat，因为它需要的资源少于 Logstash 实例。如果要解析日志、添加或删除字段或对数据进行一些丰富，则可以使用 Logstash 输出。如果我们不需要做任何类似的事情，则可以直接使用 Filebeat 输发送到 Elasticsearch。
此外，即使在 Logstash 机器上使用 Filebeat 的另一个优点是，如果我们的 Logstash 实例关闭，并不会丢失任何日志，因为filebeat 将重新发送事件，使用Logstash file输入在某些情况下我们可能会丢失事件。

接下来会进一步解释Elastic Stack部署流程。

二、Elastic Stack 容器配置简介

官方docker ELK Stack的配置下载地址：https://github.com/deviantony/docker-elk。下载完成后，可以看到图5所示的界面：
在这里插入图片描述

图5：Elastic Stack Docker 代码

上图中，有5个重要的文件和目录。其中，elasticsearch目录的config子目录下，存在elasticseach.yml文件。该文件是elasticsearch组件的配置文件。同理，kibana.yml，logstash.yml文件分别是kibana组件和logstash组件的配置文件。此外，在extensions目录下包含了各种额外的套件，例如各种Beats，例如Filebeat，Hearbeat。在这些Beats的目录下，同样有config子目录，其中有对应Beat的配置文件。最后，docker-compose.yml则是最终部署整个Elastic Stack 的容器配置文件。

三、Elastic Stack 容器化部署

测试目的：

收集 Cisco 网络设备的日志信息进行分析。
部署访问 Kibana 的可视化平台的Https流量保护。
Elastic Stack 集成AD域，实现对于用户的管理。

实验分析和准备：

根据实现的目标，本次实验仅需要使用Filebeat而无需配置Logstash，以提高性能。
提前通过Windows AD服务器部署AD域，创建域用户，并且部署证书CA服务器。
提前配置Cisco网络设备，通过syslog将日志发送到Elastic Stack所在的服务器上。

实验步骤：
Tips：由于本次实验中不涉及Logstash，所以无需对Logstash进行配置。

首先修改Elasticsearch的配置文件elasticsearch.yml，以连接Elastic Stack和AD域。代码如图6所示：
在这里插入图片描述

图6：Elasticsearch.yml 文件

具体来说，Elasticsearch额外功能是通过X-Pack实现的。X-Pack 是一个 Elastic Stack 扩展，提供安全、警报、监控、报告、机器学习和许多其他功能，其中部分X-Pack功能需要收费。在这里，激活了Elastic Stack ldap集成的功能。其中，AD域的名称为project.com，url是ldap://project.com，绑定的用户搜索的base_dn为"DC=project, DC=com"。具体的配置根据自己环境中AD域进行替换即可。进一步说，我们还需要在role-mapping.yml文件中进一步指定AD域用户与Elastic Stack管理员的权限映射关系。权限配置文件如7所示：
在这里插入图片描述

图7：Role-mapping.yml 文件

这里将ELKAdmin用户赋予了superuser的权限，因此，后续可以通过ELKAdmin用户对该Elastic Stack进行所有操作。此外还有user，monitor等不同的用户授权等级，具体请参考：https://www.elastic.co/guide/en/elasticsearch/reference/current/active-directory-realm.html

上述工作完成了对于 Elasticsearch 组件的配置。接着我们需要配置Filebeat对Cisco设备日志信息收集。Filebeat配置文件如图8所示:
在这里插入图片描述

图8：Filebeat.yml 文件

在Filebeat配置文件中需要注意配置的是如下三点：首先在modules下配置所需要启用的modules，这里指定了启用modules.d目录下所有的模块。第二，在Elastic Stack官网下载与自己Elastic Stack相同版本版本且需要的module。例如这里下载的是Cisco的module，如图9所示。接着，我们通过该module，开启了对于asa和ftd设备日志的收集。最后，配置Filebeat最终输出的数据库，这里是Elasticsearch。指定了地址http://elasticsearch:9200和输出数据的索引project-cisco-%{+yyyy.MM.dd}，以及与Elasticsearch连接的用户名以及密码。
在这里插入图片描述

图9：Cisco module 配置文件

接下来配置 Kibana组件。我们需要在Kibana组件的配置文件中配置Https访问功能，代码如图10所示：
在这里插入图片描述

图10：Kibana.yml文件

开启Https访问Kibana界面只需要在Kibana组件中加载TLS（SSL）的CA证书，自身的证书和私钥即可。自己的私钥和证书请求文件可以通过openssl生成，然后通过自己的CA机构进行签名生成Kibana数字证书。当然，我们也可以通过openssl工具自己产生新的CA证书。Openssl具体操作请参照: https://www.digicert.com/kb/ssl-support/openssl-quick-reference-guide.htm#:~:text=OpenSSL is an open-source,certificate%2C and identify certificate information.。得到了三个关键文件（ELK.project.com.cer，ELK.project.com.key 和 ca.cer）后，我们只需要在Kibana的配置文件中指定三个关键文件的目录即可。除此此外，我们还需要在Kibana的配置文件中还需要设置Elasticsearch的通信地址http://elasticsearch:9200。

完成上述配置后，我们继续需要配置docker compose文件。配置docker compose文件的目的是将Elastic Stack套件容器化。首先，我们需要配置前文中提到的docker-compose.yml文件。如图11所示：
在这里插入图片描述

图11：ELK docker-compose文件

上述docker-compose文件记录了Elasticsearch，Logstash （因为本次实验不涉及，已经被注释）以及Kibana 三大组件容器化过程中的配置。虽然看似配置很复杂，但是我们需要修改的内容不多，主要是volume卷挂载的配置。具体来说，在volumes：关键参数后，我们需要定义本地文件映射到容器中的具体映射关系。例如，在Elasticsearch组件中，我们需要将之前配置好的elasticseach.yml以及role-mapping.yml文件拷贝到了容器中，此外，卷挂载还解决了一些容器的时间同步，数据备份等需求。同理，在Kibana容器配置中，也映射了之前配置的kibana.yml以及Https证书相关的文件。最后，该配置文件中定义了桥接网络elk，我们可以通过该网络将Elasticsearch和Kibana进行了网络联通。

此外，由于在本次实验中启用了Filebeat，所以除了之前提到的docker-compose.yml以外，还涉及到Filebeat的docker-compose文件，如图12所示：
在这里插入图片描述

图12：Filebeat-compose文件

与ELK的docker compose文件相似，该文件中同样设置了对于Filebeat容器的时间以及module配置文件的映射。并且我们可以从中看到，Filebeat也能通过elk桥接网络与另外两个组件网络联通。

配置完成后，我们只需要使用docker-compose工具依次应用docker-compose.yml以及filebeat-compose.yml即可完成对于基于Filebeat的 Elastic Stack 搭建。具体操作如下，进入文件所在目录，输入命令docker-compose up -f docker-compose.yml，以及docker-compose up -f filebeat-compose.yml。最终，在游览器上输入https://IP地址:5601，Elastic Stack登陆界面如图13所示：
在这里插入图片描述