elk что это такое
Практическое применение ELK. Настраиваем logstash
Разворачивая очередную систему, столкнулись с необходимостью обрабатывать большое количество разнообразных логов. В качестве инструмента выбрали ELK. В данной статье пойдёт речь о нашем опыте настройки этого стека.
Не ставим цели описать все его возможности, но хотим сконцентрироваться именно на решении практических задач. Вызвано это тем, что при наличии достаточно большого количества документации и уже готовых образов, подводных камней достаточно много, по крайней мере у нас они обнаружились.
Мы разворачивали стек через docker-compose. Более того, у нас был хорошо написанный docker-compose.yml, который позволил нам практически без проблем поднять стек. И нам казалось, что победа уже близка, сейчас немного докрутим под свои нужды и всё.
К сожалению, попытка донастроить систему на получение и обработку логов от нашего приложения, с ходу не увенчалась успехом. Поэтому, мы решили, что стоит изучить каждый компонент отдельно, а потом уже вернуться к их связям.
Итак, начали с logstash.
Окружение, развёртывание, запуск Logstash в контейнере
Для развёртывания используем docker-compose, описанные здесь эксперименты проводились на MacOS и Ubuntu 18.0.4.
Образ logstash, который был прописан у нас в исходном docker-compose.yml, это docker.elastic.co/logstash/logstash:6.3.2
Его мы будем использовать для экспериментов.
Для запуска logstash мы написали отдельный docker-compose.yml. Можно конечно было из командной строки образ запускать, но мы ведь конкретную задачу решали, где у нас всё из docker-compose запускается.
Кратко про конфигурационные файлы
Внутри контейнера есть ещё один конфигурационный файл — logstash.yml. Мы его не трогаем, используем как есть.
Итак, структура наших каталогов:
Для получения входных данных пока считаем, что это tcp по порту 5046, а для вывода будем использовать stdout.
Вот такая простая конфигурация для первого запуска. Поскольку ведь начальная задача — запустить.
Итак, у нас есть вот такой docker-compose.yml
Что мы здесь видим?
Здесь описан один канал с идентификатором HABR и путь к его конфигурационному файлу.
И наконец файл «./config/pipelines/habr_pipeline.conf»
Не будем пока вдаваться в его описание, пробуем запустить:
Контейнер запустился. Можем проверить его работу:
И видим в консоли контейнера ответ:
Но при этом, видим также:
logstash_one_channel | [2019-04-29T11:28:59,790] [ERROR][logstash.licensechecker.licensereader] Unable to retrieve license information from license server <:message=>«Elasticsearch Unreachable: [http://elasticsearch:9200/] [Manticore::ResolutionFailure] elasticsearch», …
logstash_one_channel | [2019-04-29T11:28:59,894][INFO ][logstash.pipeline ] Pipeline started successfully <:pipeline_id=>«.monitoring-logstash», :thread=>»#
logstash_one_channel | [2019-04-29T11:28:59,988][INFO ][logstash.agent ] Pipelines running <:count=>2, :running_pipelines=>[:HABR, :».monitoring-logstash»], :non_running_pipelines=>[]>
logstash_one_channel | [2019-04-29T11:29:00,015] [ERROR][logstash.inputs.metrics ] X-Pack is installed on Logstash but not on Elasticsearch. Please install X-Pack on Elasticsearch to use the monitoring feature. Other features may be available.
logstash_one_channel | [2019-04-29T11:29:00,526][INFO ][logstash.agent ] Successfully started Logstash API endpoint <:port=>9600>
logstash_one_channel | [2019-04-29T11:29:04,478][INFO ][logstash.outputs.elasticsearch] Running health check to see if an Elasticsearch connection is working <:healthcheck_url=>http://elasticsearch:9200/, :path=>»/»>
l ogstash_one_channel | [2019-04-29T11:29:04,487] [WARN ][logstash.outputs.elasticsearch] Attempted to resurrect connection to dead ES instance, but got an error. <:url=>«elasticsearch:9200/», :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>«Elasticsearch Unreachable: [http://elasticsearch:9200/][Manticore::ResolutionFailure] elasticsearch»>
logstash_one_channel | [2019-04-29T11:29:04,704][INFO ][logstash.licensechecker.licensereader] Running health check to see if an Elasticsearch connection is working <:healthcheck_url=>http://elasticsearch:9200/, :path=>»/»>
logstash_one_channel | [2019-04-29T11:29:04,710] [WARN ][logstash.licensechecker.licensereader] Attempted to resurrect connection to dead ES instance, but got an error. <:url=>«elasticsearch:9200/», :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>«Elasticsearch Unreachable: [http://elasticsearch:9200/][Manticore::ResolutionFailure] elasticsearch»>
И наш лог всё время ползёт вверх.
Здесь я выделил зелёным цветом сообщение о том, что pipeline успешно запустилась, красным — сообщение об ошибке и жёлтым — сообщение о попытке связаться с elasticsearch:9200.
Происходит это из за того, что в logstash.conf, включенном в состав образа, стоит проверка на доступность elasticsearch. Ведь logstash предполагает, что работает в составе Elk стека, а мы его отделили.
Работать можно, но не удобно.
Решением является отключить эту проверку через переменную окружения XPACK_MONITORING_ENABLED.
Внесём изменение в docker-compose.yml и снова запускаем:
Вот теперь, всё нормально. Контейнер готов к экспериментам.
Можем снова набрать в соседней консоли:
Работа в рамках одного канала
Итак, мы запустились. Теперь собственно можно уделить время настройке непосредственно logstash. Не будем пока трогать файл pipelines.yml, посмотрим, что можно получить, работая с одним каналом.
Надо сказать, что общий принцип работы с файлом конфигурации канала хорошо описан в официальном руководстве, вот здесь
Если хочется почитать по-русски, то мы пользовались вот этой статьёй(но синтаксис запросов там старый, надо это учитывать).
Пойдем последовательно от секции Input. Работу по tcp мы уже видели. Что ещё здесь может быть интересного?
Тестовые сообщения, используя heartbeat
Есть такая интересная возможность генерировать автоматические тестовые сообщения.
Для этого в input секцию нужно включить плагин heartbean.
Включаем, начинаем раз в минуту получать
Хотим получать почаще, надо добавить параметр interval.
Вот так будем получать раз в 10 секунд сообщение.
Получение данных из файла
Ещё решили посмотреть режим file. Если нормально с файлом работает, то возможно, и агента никакого не потребуется, ну хотя бы для локального использования.
Итак, что мы хотим получить:
И изменим секцию input в habr_pipeline.conf
Для создания и записывания лог файлов будем пользоваться командой:
При этом, мы видим, что у нас автоматически добавилось поле path. Значит в дальнейшем, мы сможем по нему фильтровать записи.
А теперь в другой файл:
Отлично! Файл подхватился, path указался верно, всё хорошо.
Остановим logstash и запусти заново. Подождём. Тишина. Т.е. Повторно мы эти записи не получаем.
А теперь самый смелый эксперимент.
Кладём logstash и выполняем:
Снова запускаем logstash и видим:
Ура! Всё подхватилось.
Но, надо предупредить о следующем. Если контейнер с logstash удаляется (docker stop logstash_one_channel && docker rm logstash_one_channel), то ничего не подхватится. Внутри контейнера была сохранена позиция файла, до которой он был считан. Если запускать «с нуля», то он будет принимать только новые строки.
Считывание уже существующих файлов
Допустим мы первый раз запускаем logstash, но у нас уже есть логи и мы хотели бы их обработать.
Если мы запустим logstash с той секцией input, которую использовали выше, то мы ничего не получим. Только новые строки будут обрабатываться logstash.
Для того, чтобы подтянулись строки из существующих файлов, следует добавить в input секцию дополнительную строчку:
Причём, есть нюанс, это действует только на новые файлы, которые logstash ещё не видел. Для тех же файлов, что уже попадали в поле зрения logstash, он уже запомнил их размер и теперь будет брать только новые записи в них.
Остановимся на этом на изучении секции input. Там ещё множество вариантов, но нам, для дальнейших экспериментов пока хватит.
Маршрутизация и преобразование данных
Попробуем решить следующую задачу, допустим у нас идут сообщения из одного канала, часть из них информационные, а часть сообщение об ошибках. Отличаются тегом. Одни INFO, другие ERROR.
Нам нужно на выходе их разделить. Т.е. Информационные сообщения пишем в один канал, а сообщения об ошибках в другой.
Для этого, от секции input переходим к filter и output.
С помощью секции filter мы разберём входящее сообщение, получив из него hash(пары ключ-значение), с которым уже можно работать, т.е. разбирать по условиям. А в секции output, отберём сообщения и отправим каждое в свой канал.
Разбор сообщения с помощью grok
Для того, чтобы разбирать текстовые строки и получать из них набор полей, в секции filter есть специальный плагин — grok.
Не ставя себе целью дать здесь его детальное описание (за этим отсылаю к официальной документации), приведу свой простой пример.
Для этого, надо определиться с форматом входных строк. У меня они такие:
1 INFO message1
2 ERROR message2
Т.е. Идентификатор на первом месте, затем INFO/ERROR, затем какое-то слово без пробелов.
Не сложно, но для понимания принципа работы хватит.
Итак, в секции filter, в плагине grok мы должны определить паттерн для разбора наших строк.
Выглядеть он будет так:
По сути, это регулярное выражение. Используются уже готовые паттерны, такие как INT, LOGLEVEL, WORD. Их описание, а также другие паттерны, можно посмотреть вот здесь
Теперь, проходя через этот фильтр, наша строка превратится в hash из трёх полей: message_id, message_type, message_text.
Именно они будут выводиться в секции output.
Маршрутизация сообщений в секции output с помощью команды if
В секции output, как мы помним, мы собирались разделить сообщения на два потока. Одни — которые iNFO, будем выводить на консоль, а с ошибками, будем выводить в файл.
Как нам разделить эти сообщения? Условие задачи уже подсказывает решение — у нас ведь есть уже выделенное поле message_type, которое может принимать только два значения INFO и ERROR. Именно по нему и сделаем выбор с помощью оператора if.
Описание работы с полями и операторами, можно посмотреть вот в этой секции официального мануала.
Теперь, про собственно сам вывод.
Вывод в консоль, здесь всё понятно — stdout <>
А вот вывод в файл — вспоминаем, что мы это всё запускаем из контейнера и чтобы файл, в который мы пишем результат, был доступен снаружи, нам необходимо открыть эту директорию в docker-compose.yml.
Секция output нашего файла выглядит вот так:
В docker-compose.yml добавляем ещё один том, для вывода:
Запускаем, пробуем, видим разделение на два потока.
Elk что это такое
В этой статье рассмотрим ELK-инфраструктуру: разберем, зачем поисковый движок Elasticsearch использует сборщик логов Logstash и при чем здесь визуальный интерфейс Kibana. Также поговорим, в каких Big Data проектах используются эти системы и для чего.
Зачем вам Elasticsearch: полнотекстовый поиск по Big Data
Чтобы определить, почему деньги пропали с банковского счета или кто именно из сотрудников слил персональные данные клиентов в сеть и найти причины прочих инцидентов в корпоративном масштабе, нужна полная картина произошедшего. Составить ее поможет анализ системных логов – журналов, где зафиксированы все события, случившиеся в системе за конкретный промежуток времени [1]. Сегодня наиболее популярным инструментом для построения решений по мониторингу корпоративной инфраструктуры считается ELK – Elasticsearch, Logstash и Kibana. Изначально эти 3 продукта с открытым исходным кодом развивались отдельно друг от друга, но в 2015 году стали принадлежать одной компании Elastic. Сегодня Elasticsearch, Logsatsh и Kibana используются вместе для задач сбора, хранения и анализа данных [2].
Мощные возможности ELK-инфраструктуры позволяют не только анализировать системные логи в рамках задачи администрирования корпоративного ИТ-ландшафта. Также эта Big Data система отлично подходит для решения следующих бизнес-задач [3]:
Далее рассмотрим подробнее, из чего состоит ELK-система и как она устроена.
Что внутри ELK-системы: архитектура и принципы работы
Инфраструктура ELK включает следующие компоненты [2]:
В рамках единой ELK-платформы все вышеперечисленные компоненты взаимодействуют следующим образом [5]:
Завтра мы рассмотрим главные достоинства и недостатки ELK-инфраструктуры. А как эффективно использовать их для сбора и анализа больших данных в реальных проектах, вы узнаете на практических курсах по администрированию и эксплуатации Big Data систем в нашем лицензированном учебном центре повышения квалификации и обучения руководителей и ИТ-специалистов (разработчиков, архитекторов, инженеров и аналитиков) в Москве.
На что обратить внимание при выборе системы логирования, и почему мы остановились на ELK
На рынке представлено огромное количество систем логирования — как открытых, так и проприетарных. У каждой из них своя функциональность, свои достоинства и недостатки.
Сегодня мы решили поделиться опытом выбора системы логирования и рассказать, почему мы в 1cloud остановились на ELK.
Минутка теории
При переходе в продакшн, приложения превращаются в своеобразные «черные ящики». Их работу нужно постоянно мониторить, чтобы предотвращать и реагировать на потенциальные ЧП, отлавливать «узкие места».
Системы логирования — обязательный инструмент, без которого не обойтись в этом процессе. Проводя подробный анализ собираемых данных, можно идентифицировать «вторжения» в сеть, выявить неправильно настроенное оборудование и оперативно принять меры. Также логирование является обязательным требованием при прохождении разного рода сертификаций, например PCI DSS.
Для автоматизации процессов логирования есть специальные фреймворки: log4j, log4net, Retrace, Logback, Logstash и другие — их множество. Свои инструменты для логирования имеют отдельные средства разработки, например JDK — там есть java.util.logging. Разумеется, функциональность различных инструментов логирования отличается, и необходимый набор функций нужно выбирать исходя из требований бизнеса. Однако есть ряд общих моментов, которые стоит отметить при выборе системы анализа логов.
Простота использования и размеры сообщества
Простота — один из ключевых компонентов при выборе системы логирования. С лог-фреймворками работают все разработчики в команде, потому опыт использования этого инструмента должен быть положительным и не превращать анализ логов в кошмар. API фреймворка должен быть интуитивно понятным, чтобы все, кто раньше не работал с системой, могли быстро разобраться, как она устроена и настроена.
Если рассматривать опенсорсную систему логирования, то имеет смысл оценить сообщество, которое сформировалось вокруг неё. Для этого можно изучить, насколько часто её упоминают на профильных площадках (Stack Overflow), а также в профильных тредах, например на Reddit. Как вариант — посмотреть популярность проекта на GitHub (количество звезд) и посмотреть, как часто его вписывают в различные подборки инструментов в сети (наподобие таких). Очевидно, чем больше сообщество, тем выше вероятность, что вам помогут в случае возникновения непредвиденных трудностей.
Что касается выбора проприетарных систем логирования, то здесь в первую очередь стоит смотреть на скорость ответов и адекватность службы поддержки выбираемого решения, а также его цену.
Возможность сбора «разнокалиберных» логов
Не все платформы для логирования способны обрабатывать большое количество данных и предоставлять полную информацию об используемых системах.
Перед выбором решения стоит определиться, какие именно логи вы планируете собирать: HTTP-логи (помогут понять поведение пользователей на сайте), API-логи (дадут возможность оценить, какие сервисы чаще всего запрашиваются по API), логи об ошибках и просто записи изменений в системе (укажут на «узкие места», если таковые есть).
Масштабируемость
Инструмент логирования должен собирать логи с каждого системного компонента и предоставлять к ним доступ в одном месте. Если система не приспособлена для масштабирования, качество лог-анализа упадет.
Мы в 1cloud изначально использовали для логирования MS SQL. Однако с ростом числа клиентов и сервисов (например, совсем недавно мы разместили оборудование в минском ЦОД и добавили поддержку IPv6), у нас появились территориально разнесенные компоненты инфраструктуры, у которых не было доступа к БД. А одной из главных наших задач было сохранение возможности анализа логов из единого места.
Система логирования 1cloud
Как мы уже отметили, для хранения логов в 1cloud раньше использовался MS SQL, а для их записи — log4net. И это начало создавать для нас определенные трудности. Из-за территориально разнесенных компонентов, стало невозможно держать сетевую связанность с БД и обеспечивать единую точку для анализа.
При этом большой объем логов и невозможность построить индексы по всем необходимым нам для поиска полям привели к излишнему упрощению лог-анализа — нам приходилось отказываться от функциональности в угоду производительности.
Чтобы решить эту проблему и обеспечить масштабируемость, мы внедрили новую систему логирования. Всего мы изучили больше пятидесяти различных решений и выделили четыре, которые полностью удовлетворяли нашим требованиям:
Logstash
Решение имеет 9,2 тыс. звезд на GitHub. Logstash распространяется по лицензии Apache 2.0 и является частью стека ELK. Имеет большое количество плагинов (на GitHub их насчитывается порядка 250 штук). Работает под Windows и Linux и имеет высокую производительность, практически не зависящую от объемов данных.
Система дает быстро проводить обзор и анализ событий с рабочих станций, файрволов, маршрутизаторов и коммутаторов. Это связано с тем, что нет необходимости в «нормализации» событий.
Однако стоит понимать, что это «голый» движок, потому он не предоставляет готовых визуализаций. Из других недостатков отметим необходимость ставить Java на все серверы, так как Logstash написан на Ruby (JRuby).
У решения довольно обширное сообщество: имеется IRC-канал и отдельный форум. В сети есть примеры по конфигурации всей системы и API. Используют Logstash следующие организации: CERN Control Center, GitHub, SoundCloud.
Fluentd
6,6 тыс. звезд на GitHub. Распространяется по лицензии Apache 2.0 фондом CNCF (Cloud Native Computing Foundation) — он основан компанией Google и The Linux Foundation для продвижения технологий контейнеров.
Fluentd работает под Linux, Windows и Mac и написан на Ruby (CRuby). Fluentd имеет гибкую систему плагинов, которая расширяет его функциональные возможности.
Решение имеет унифицированный формат логирования: полученные данные Fluentd старается привести к формату JSON. Для обеспечения надежности работы не требуются сторонние решения, однако для этого приходится проводить дополнительную настройку. Также не рекомендуется устанавливать его на серверы, генерирующие логи.
Сообщество большое: имеется канал в Slack, а также тред в Google Groups. На официальном сайте проекта есть примеры конфигураций и API. Fluentd используют такие компании, как Microsoft, Amazon, change.org и Nintendo.
Graylog
4,3 тысячи звезд на GitHub. Распространяется по лицензии GNU GPL v3. Работает только под Linux. Централизованная экосистема плагинов и настраиваемая система буферизации. Для удобства позволяет по ключевому слову объединять поступающие сообщения в потоки и группировать эти потоки с разных хостов.
Система использует функции Elasticsearch, но несмотря на частые обновления Graylog и развитое сообщество (есть форум, IRC-канал, на официальном сайте проекта есть примеры конфигураций и API.), интеграция актуальных версий Elasticsearch в проект занимает длительное время. Например, в прошлом году возникла ситуация, когда Graylog 2.2.1 (на то время последний) работал только с Elasticsearch версии 2.4.4, которая считалась устаревшей.
В своей работе Graylog использует Европейское агентство по окружающей среде, компании Dial Once, Stockopedia и др.
LOGalyze
Работает под Linux и Windows. Cистема обладает высокой производительностью и умеет составлять подробные отчеты по ключевым словам. Есть серьезный недостаток — LOGalyze собирает логи в свою файловую БД, где затем их индексирует, занимая значительный объем дискового пространства.
Разработчики LOGalyze ведут свой блог, также обсуждение решения проходит в группах Google. Есть руководство по настройке системы и миграции данных, а также CLI.
Оценив эти четыре варианта, мы остановили свой выбор на Logstash и решили организовать стек ELK (ElasticSearch, Logstash, Kibana). Из них Elasticsearch — это поисковый движок, Logstash представляет собой механизм сбора и анализа логов, а Kibana «занимается» аналитикой и визуализацией данных.
Мы выбрали ELK, так как все три компонента разрабатывает один «производитель», потому они хорошо интегрируются друг с другом. При необходимости мы сможем использовать каждый из этих инструментов в отдельности для решения других задач.
Такой подход делает продукт гибким и универсальным. Все это позволит эффективнее обрабатывать уже существующие объемы данных и быстрее внедрять новые сервисы — их будет легче подключать.
Сейчас готова тестовая среда. Она «покрывает» все сервисы, логи которых мы будем анализировать. Мы заканчиваем последние отладочные процессы и планируем полноценный запуск решения уже в ближайшее время.
Кстати, несмотря на то, что мы подробно анализировали различные варианты и выбрали наилучший для наших нужд, в итоге не обошлось и без ложки дегтя. При тестировании решения мы столкнулись с ситуацией, когда Kibana запросом уронила Elasticsearch — что считается крайне редким и вырожденным случаем. Также при «сборке» системы возник ряд вопросов, связанных в основном с безопасностью. В базовом варианте Elasticsearch ничем не защищен — пришлось приспосабливать для этих целей стороннее ПО.
После запуска мы займемся настройкой систем мониторинга, чтобы максимально оперативно реагировать на сбои в работе лог-сервиса. Мы рассчитываем, что новый стек технологий позволит улучшить пользовательский опыт наших клиентов и в дальнейшем быстрее развивать наши сервисы.
Изучаем ELK. Часть III — Безопасность
Вступительное слово
В первой и второй частях данной серии статей была описана процедура установки и настройки кластера Elasticsearch, Kibana и Logstash, но не был освящен вопрос безопасности.
В этой статье я расскажу, как настроить шифрование трафика между узлами кластера Elasticsearch и его клиентам, шифрование трафика между Kibana и клиентами, покажу, как создавать роли и пользователей, а так же выдавать API ключи для доступа к кластеру Elasticsearch.
План действий
«Включаем» безопасность
Чтобы использовать функции безопасности в Elasticsearch, их необходимо активировать. Для этого на каждом узле в файле конфигурации указывается следующая настройка:
Настраиваем шифрование между узлами Elasticsearch
Следующим шагом необходимо настроить шифрование трафика между узлами Elasticsearch. Для этого выполняем несколько шагов:
Создаем CA (Certificate Authority) для кластера Elasticsearch:
Во время генерации корневого сертификата можно задать имя PKCS#12 файла, по умолчанию это elastic-stack-ca.p12 и пароль к нему.
Полученный корневой сертификат (для PEM формата еще и ключ) надо переместить на все узлы кластера для генерации сертификата узла.
Генерируем на каждом узле кластера сертификат и ключ:
Включаем TLS в файле конфигурации Elasticsearch:
Если сертификаты CA и/или узла в формате PEM, то необходимо изменить последние два параметра на следующие:
Cоздаем keystore и добавляем пароли от сертификатов(если они были заданы):
Для PKCS#12 формата:
Для PEM сертификата:
В логах Elasticsearch должны появится записи о создании кластера:
Если обратиться к API, то будет ошибка «missing authentication credentials for REST request». С момента включения функций безопасности для обращения к кластер необходимо пройти аутентификацию.
Настраиваем аутентификацию
Elasticsearch имеет несколько встроенных пользователей:
Пользователь
Описание
Используется для коммуникации между Kibana и Elasticsearch
Пользователь, которого использует Logstash сервер, когда сохраняет информацию в Elasticsearch
Пользователь, которого использует агент Beats, когда сохраняет информацию в Elasticsearch
Пользователь, которого использует APM сервер, когда сохраняет информацию в Elasticsearch
Пользователь Metricbeat, который используется при сборе и хранении информации мониторинга в Elasticsearch
Второй раз elasticsearch-setup-passwords запустить не получится, так как bootstrap password изменился. Чтобы изменить пароль пользователям можно воспользоваться API.
Попробуем сделать API запрос к любому узлу Elasticsearch с использованием учетной записи elastic и пароля к от неё:
Настраиваем шифрование клиентского трафика Elasticsearch
Для шифрования клиентского трафика необходимо выпустить сертификат, который будет использоваться для шифрования трафика между узлом Elasticsearch и клиентом. При этом для Kibana будет сформирован отдельный сертификат, чтобы настроить соединение с Elasticsearch. Для этого делаем следующее:
В процессе генерации необходимо определить:
1) Необходимо ли сгенерировать Certificate Signing Request (CSR). Потребуется, если сертификат будет выпускаться сторонним CA (Certificate Authority).
2) Использовать ли собственный CA (Certificate Authority). Если да, то указываем путь до ключа, которым будет подписаны будущие сертификаты.
3) Срок действия сертификата. По умолчанию 5 лет. Можно определить дни(D), месяцы (M), года (Y).
4) Как выпустить сертификат, на каждый узел или общий. Если все узлы имеют общий домен, то можно выпустить wildcard сертификат (например *.domain.local). Если общего домена нет и в будущем возможно добавление узлов, то необходимо генерировать на каждый узел, указав имя узла и его адрес. В будущем можно выпустить отдельный сертификат для нового узла.
На выходе получаем архив сертификатами, в моём случае со всеми сертификатам для каждого узла Elasticsearch, а так же сертификат для подключения Kibana к Elasticsearch:
В архиве также лежит инструкция по дальнейшим действиям с сертификатом (README.txt) и пример конфигурационного файла (sample-. yml).
Сертификат elasticsearch-ca.pem из директории kibana потребуется в следующем шаге.
Размещаем сертификаты на узлах и добавляем необходимые настройки в файле конфигурации:
Добавляем пароль от сгенерированного сертификата в keystore:
Проверяем, что все работает по https :
Подключаем Kibana к Elasticsearch
Если сейчас обратиться к Kibana, то ответом будет «Kibana server is not ready yet«.
В конфигурационном файле Kibana указываем ключ к сертификату elasticsearch-ca.pem (из предыдущего шага) и меняем протокол http на https :
В примере выше я использую адрес Coordinating only узла для балансировки нагрузки между Kibana и Elasticsearch, который был настроен в предыдущей части.
Создаем keystore для хранения пользователя и пароля:
Команда выполняются из директории /usr/share/kibana
Kibana keystore не имеет пароля. Для ограничения доступа используем стандартные средства Linux.
Добавляем пользователя kibana_system(встроенный пользователь Elasticsearch) и пароль учетной записи в Kibana keystore:
Можно использовать так же пользователя kibana, однако, он в системе считается устаревшим (deprecated).
перезапускаем Kibana и проверяем открыв нужный адрес в браузере:
Kibana
Для входа используем учетную запись elastic.
Как можно заменить, трафик между браузером и Kibana не шифруется.
Настраиваем шифрование трафика между Kibana и клиентами
Данная процедура максимально похожа на ту, которую выполняли для получения сертификатов для узлов Elasticsearch.
Получаем сертификат при помощи elsticsearch-certutil :
При необходимости можем использовать CA (Certificate Authority). В процессе генерации сертификата указываем пароль от CA, если используется, имя будущего сертификата и пароль к нему.
Указываем путь к сертификату в файле kibana.yml :
Так как я использовал ранее полученный CA, то указываю путь и к нему ( server.ssl.truststore.path ).
Не забывайте о правах доступа, пользователь kibana должен иметь права на чтения.
Включаем использование TLS:
Добавляем пароли от сертификатов в keystore:
Перезагружаем Kibana и проверяем:
Доступ к Kibana по https
Создаем пользователей и роли
Ранее мы активировали встроенные учетные записи и сгенерировали для них пароли, но использовать пользователя elastic (superuser) не лучшая практика, поэтому рассмотрим, как создавать пользователей и роли к ним.
Для примера создадим администратора Kibana. Открываем Menu > Management > Stack Management, выбираем Users и нажимаем Create user. Заполняем все поля и жмем Create User.
Создание пользователя в Kibana
Или же можно воспользоваться API. Делать запросы к кластеру можно через консоль Dev Tools инструмента Kibana. Для этого перейдите Menu > Management > Dev Tools. В открывшейся консоли можно писать запросы к Elasticsearch.
Создание пользователя kibana_admin через API
После создания пользователя, можно его использовать.
Далее создадим роль для работы с данными в ранее созданном индексом logstash-logs*. Открываем Menu > Management > Stack Management. Слева выбираем Roles и нажимаем Create role. Настраиваем привилегии, указав в качестве индекса logstash-logs*:
Index privileges
Read only права на индекс
Предоставляем пользователю доступ к Kibana, для этого ниже наживаем Add Kibana privilege и выбираем требуемые привилегии:
В поле Spaces указываю All spaces. Что такое Space (пространства) можно почитать на официальном сайте. В рамках данной серии статей Space будет описан в статье о Kibana dashboard.
Чтобы создать роль с привилегиями в Elasticsearch и Kibana через API, делаем запрос к Kibana:
Создаем пользователя logstash_reader и связываем его с созданной ролью (это мы уже научились делать) и заходим данным пользователем в Kibana.
Главная страница Kibana для пользователя logstash_reader
Как видно, у данного пользователя не так много прав. Он может просматривать индексы logstash-logs*, строить графики, создавать панели и делать GET запросы к этому индексам через Dev Tools.
Настраиваем пользовательские сессии Kibana
Закрываем неактивные сессии:
Устанавливаем максимальную продолжительность одной сессии:
Настраиваем интервал принудительной очистки данных о неактивных или просроченных сессиях из сессионного индекса:
Для всех параметров формат времени может быть следующим: ms | s | m | h | d | w | M | Y
Данные о сессии удаляются после того, как пользователь осуществляет закрытие сессии. Если не настроить закрытие неактивных сессий или не ограничить максимальную длительность сессии, то информация об этих сессиях будет накапливаться в сессионном индексе, и Kibana не сможет автоматически удалить данные.
Настраиваем Logstash
На данный момент Logstash не отправляет данные в кластер Elasticsearch, и чтобы это исправить, сделаем несколько настроек.
Создаем роль для подключения к кластеру:
В Kibana открываем Menu > Management > Stack Management. Слева выбираем Roles и нажимаем Create role. Указываем имя роли и настраиваем привелегии:
Cluster privileges
Все операции над шаблонами индексов
Read-only права на получение информации о кластере
Index privileges
Индексирование, обновление и удаление индексов
Мониторинг и управление индексом
Управление жизненным циклом индексов (IML)
Создаем пользователя для подключения к кластер:
Открываем Menu > Management > Stack Management, выбираем Users и нажимаем Create user. Заполняем требуемые данные, указав в качестве роли созданную выше роль.
Создание пользователя logstash_user
Создаем Logstash keystore, и добавляем туда пользователя и пароль от него:
Настраиваем аутентификацию в output плагине:
Настраиваем TLS в Logstash:
Перезагружаем Logstash и проверяем новые записи в индексе
Проверку можно сделать в Kibana через Discovery, как делали в прошлой статье, или через API:
Создание API ключей
Для работы с Elasticsearch можно не только использовать учетные записи пользователей, но и генерировать API ключ. Для этого необходимо сделать POST запрос:
В качестве параметров указывают:
Для примера заменим базовую аутентификацию в Logstash на API ключ.
Создаем API ключ в Kibana Dev Tool:
Получаем следующий результат:
Помещаем ключ в формате id:api_key в Keystore:
Указываем API ключ в конфигурационном файле конвейера:
Информацию по ключам можно получить в Kibana Menu > Management > API Keys или через API запрос:
Заключение
В рамках данной статьи были рассмотрены основные функции безопасности стека Elastic, позволяющие обезопасить работу нашего кластера, научились создавать пользователей и пользовательские роли, производить настройку пользовательских сессий, настройку шифрования трафика между узлами кластера и между кластером и клиентами, работать с API ключами и keystore.
В следующей статье будет рассмотрена процедура создание кластера ELK с помощью Docker.