Переходим на Elastic Stack 5.0: X-Pack Security убирает Elasticsearch из DMZ

В октябре Elastic выкатили 5.0 GA. Мы ждали этого релиза с июля, когда тестировали бету и остались довольны Filebeat. GA - значит пора переходить на продакшн. Что получилось - рассказываем.

Главный сюрприз GA-версии не в самом Elasticsearch и не в Kibana с переработанным интерфейсом. Главный сюрприз - X-Pack и то, как его появление вынудило нас пересмотреть схему доступа к кластеру.

Что такое X-Pack и почему это меняет расклад

X-Pack - это коммерческое расширение, которое объединяет несколько плагинов: Security (бывший Shield), Monitoring (бывший Marvel), Alerting (бывший Watcher) и Graph. В GA-версии X-Pack устанавливается как единый пакет, и на 30 дней включается триальная лицензия со всем набором. После истечения триала часть функций (мониторинг самого кластера) остаётся в базовой бесплатной лицензии, остальное - платно.

Нас интересовала прежде всего Security-часть. До X-Pack аутентификация в Elasticsearch отсутствовала как класс. Стандартная защита - поставить nginx с basic auth перед 9200-м портом и надеяться, что Kibana ни у кого в DMZ не болтается. Так и жили.

С X-Pack Security появляется встроенная аутентификация: пользователи, роли, LDAP-интеграция. Elasticsearch перестаёт быть сервисом, доступным любому, кто дотянулся до порта.

Как мы переходили

Стенд: три ноды Elasticsearch 2.4, Logstash 2.4, Kibana 4.6. Переходим на 5.0 везде одновременно - синхронизация версий в Elastic Stack на этот раз настоящая.

Само обновление прошло без особых приключений. Индексы пересоздавать не пришлось - Elasticsearch 5.0 читает индексы, созданные в 2.x. Logstash-конфиги тоже в основном совместимы, кроме нескольких deprecated-директив, которые теперь выдают предупреждения.

Проблемы начались с X-Pack.

Первое - аутентификация ломает всё, что работало без неё. После установки X-Pack и включения Security все компоненты, которые раньше ходили в Elasticsearch без паролей, перестали работать. Logstash, Kibana, Filebeat, наши собственные скрипты индексирования - всем внезапно потребовались учётные данные. Полтора часа на то, чтобы найти и обновить все точки интеграции.

Второе - сертификаты между нодами кластера. X-Pack требует TLS для внутрикластерной коммуникации. Это правильно, но генерация сертификатов с помощью elasticsearch-certgen оказалась отдельным квестом: утилита интерактивная, документация в GA местами отстаёт от реального поведения. Потратили время на то, чтобы понять правильный порядок операций.

Третье - встроенные пользователи. X-Pack Security создаёт нескольких системных пользователей: elastic (суперпользователь), kibana (для соединения Kibana с ES), logstash_system (для мониторинга Logstash). У всех дефолтный пароль changeme, который настоятельно рекомендуют сменить немедленно. Логично, но требует аккуратного прохождения по всем конфигам.

Схема доступа после перехода

До X-Pack у нас была такая схема: nginx с basic auth перед Kibana, Elasticsearch слушает только на localhost и внутренней сети. Для Logstash и Filebeat - прямой доступ по внутренней сети без аутентификации. Elasticsearch в DMZ не было, но доступ внутри сети был открытый.

После перехода:

• elastic - только для административных задач и смены паролей, не для ежедневной работы
• kibana - только для коннекта Kibana к ES, минимальные права
• logstash - отдельный пользователь с правами на запись в индексы логов
• monitoring_user - для метрик X-Pack Monitoring, только чтение служебных индексов

Разделение получилось аккуратным. Если Logstash-узел скомпрометирован, атакующий получает права писать в индексы логов, но не читать чужие данные и не управлять кластером.

# logstash.yml - пример для нового пользователя
xpack.monitoring.elasticsearch.username: logstash_system
xpack.monitoring.elasticsearch.password: "..."

# logstash pipeline output
output {
  elasticsearch {
    hosts => ["https://es-node1:9200"]
    user => "logstash"
    password => "..."
    ssl => true
    cacert => "/etc/logstash/certs/ca.crt"
  }
}

X-Pack Monitoring - это хорошо

Отдельно стоит сказать про Monitoring. Раньше для наблюдения за состоянием кластера Elasticsearch использовали Marvel - тот же X-Pack Monitoring, только назывался иначе и был отдельным плагином. Теперь это просто часть X-Pack в базовой лицензии.

В Kibana появился раздел Monitoring с метриками кластера: состояние нод, шарды, JVM heap, индексирование. Для managed-сопровождения это удобно: вместо Grafana + отдельный ES datasource получаем встроенный мониторинг прямо в привычном интерфейсе. Не то чтобы мы перестанем смотреть на Grafana с ES datasource - там другой уровень кастомизации - но для быстрой проверки здоровья кластера Monitoring из коробки удобен.

Что с Alerting

Alerting (Watcher) требует Gold-лицензии. Триал позволяет попробовать, но в продакшне без покупки - нет. Для наших клиентов это пока не актуально: алертинг по метрикам у нас через Prometheus Alertmanager, по логам - через Graylog там, где он стоит, или через самодельные скрипты. Watcher оставляем на потом.

Где сейчас

Переход завершён. Кластер работает на 5.0 GA вторую неделю, проблем нет. Файлбит на агентах - тоже 5.0, Kibana 5.0 с новым интерфейсом - привыкли быстро, там стало заметно быстрее.

Главный результат перехода - не новые функции Elasticsearch, а то, что Elasticsearch наконец перестал быть сервисом с открытым доступом внутри сети. Встроенная аутентификация это не панацея, но это правильный слой безопасности на правильном уровне. Nginx с basic auth перед Kibana как единственная защита - это была история «мы надеемся, что никто не знает про порт 9200», а не реальная безопасность.

X-Pack Security стоит денег, и это надо взвешивать. Но если в инфраструктуре есть чувствительные данные в индексах - цена вопроса не такая уж большая по сравнению с альтернативой.