Elasticsearch. Выпуск сертификата в формате PKCS#12.

В предыдущей статье мы рассматривали настройку безопасности на примере одной машины. Для кластерного решения необходимо настроить дополнительные параметры безопасности и использовать сертификат для связи между нодами.

Операции создания центра сертификации (CA) и\или сертификатов (certificates) выполняются утилитой elasticsearch-certutil:

# cd /usr/share/elasticsearch
# bin /elasticsearch-certutil

Подробнее об утилите elasticsearch-certutil

Выпуск сертификаты в формате PKCS#12

Первым шагом создадим центр сертификации:

# cd /usr/share/elasticsearch
# bin /elasticsearch-certutil ca

Называем СА как Вам удобно, например elastic-stack-ca.p12, это имя нам потребуется на следующем шаге (утилита предложит наименование по умолчанию).
Если есть необходимость создать СА без пароля то указываем параметр -pass «», команда выглядит следующим образом:

# cd /usr/share/elasticsearch
# bin /elasticsearch-certutil ca -pass ""  

Вторым шагом выпускаем сертификат (тут так же можно оставить пароль пустым использую параметр -pass «»):

# cd /usr/share/elasticsearch
# bin /elasticsearch-certutil cert --ca elastic-stack-ca.p12      //ссылаемся на созданный ранее СА

Называем СА как Вам удобно, например elastic-cert.p12

Если вы защитили сертификат узла с помощью пароля, добавьте пароль в хранилище ключей Elasticsearch:

# cd /usr/share/elasticsearch
# bin/elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password
# bin/elasticsearch-keystore add xpack.security.transport.ssl.truststore.secure_password

Теперь созданные файлы копируем в каталог настроек Elasticsearch, в моем случае это /etc/elasticsearch :

-Des.path.conf=/etc/elasticsearch

Иначе мы получим ошибку безопасности JAVA, пример ошибки:
Caused by: java.security.AccessControlException: access denied («java.io.FilePermission» «/usr/share/elasticsearch/config/cert/elastic-cert.p12» «read»)

[2019-09-04T20:32:48,044][ERROR][o.e.b.Bootstrap          ] [vsFawpk] Exception
java.lang.IllegalStateException: failed to load plugin class [org.elasticsearch.xpack.core.XPackPlugin]
        at org.elasticsearch.plugins.PluginsService.loadPlugin(PluginsService.java:614) ~[elasticsearch-6.8.2.jar:6.8.2]
...
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) ~[?:?]
        at java.lang.reflect.Constructor.newInstance(Unknown Source) ~[?:1.8.0_202]
        at org.elasticsearch.plugins.PluginsService.loadPlugin(PluginsService.java:605) ~[elasticsearch-6.8.2.jar:6.8.2]
        ... 15 more
Caused by: org.elasticsearch.ElasticsearchException: failed to initialize a TrustManagerFactory
...
Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/usr/share/elasticsearch/config/cert/elastic-cert.p12" "read")
...

Копируем файлы в /etc/elasticsearch/config/cert/ и выдаем права (иначе шанс словить ошибку JAVA выше)

# mkdir -p /etc/elasticsearch/config/cert/
# cp /usr/share/elasticsearch/elastic-c* /etc/elasticsearch/config/cert/
# chmod 666 /etc/elasticsearch/config/cert/elastic-c*

Файлы нужно скопировать на каждый узел кластера, для копирования на удаленный сервер воспользуйтесь утилитой scp.

Финальный шаг, теперь в конфиге elasticsearch.yml для каждого узла кластера указываем использование настроек безопасности XPack и ссылаемся на созданные СА и сертификат:

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/config/cert/elastic-ca.p12
xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/config/cert/elastic-cert.p12

Для применения настроек перезапустите сервис.

Полезная информация и первоисточник:
https://www.elastic.co/guide/en/elasticsearch/reference/6.8/configuring-tls.html
https://www.elastic.co/guide/en/elasticsearch/reference/6.8/certutil.html

1+

Elasticsearch. Настройка авторизации с помощью XPack

Начиная с версии 6.8.0 и 7.1.0 в Elasticsearch функция авторизации стала доступна для Basic версии.
Рассмотрим простую конфигурацию без сертификатов для кластера из одной ноды с авторизацией.

Шаг 1. Установка Elasticsearch.
https://www.elastic.co/downloads/past-releases

Скачать версию 6.8.2
Скачать версию 7.3.1

Шаг 2. Настройка XPack

В конфиге elasticsearch.yml указываем использование настроек безопасности XPack:

xpack.security.enabled: true
#xpack.security.transport.ssl.enabled: true
#xpack.security.transport.ssl.verification_mode: certificate
#xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/config/cert/elastic-ca.p12
#xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/config/cert/elastic-cert.p12

Параметры xpack.security.transport.ssl.*: true необходимо указать для кластерной архитектуры Elasticsearch.
Подробнее о выпуске сертификатов в статье: Elasticsearch. Выпуск сертификата в формате PKCS#12.

Шаг 3. Создание сервисных учетных записей в Elasticsearch

Переходим в директорию /usr/share/elasticsearch и запускаем утилиту elasticsearch-setup-passwords в режиме interactive:

# cd /usr/share/elasticsearch
# bin/elasticsearch-setup-passwords interactive

Интерактивный диалог предложен задать пароль для основных сервисных пользователей Elastic-стека:
— elasic
— kibana
— APM
— beats
— logstash
— remote_monitoring
Подробнее про утилиту elasticsearch-setup-passwords.

После этого этапа Elasticsearch будет доступен только для авторизированных запросов, иначе мы получим 401 ошибку:

{"error":{"root_cause":[{"type":"security_exception","reason":"missing authentication credentials for REST request [/]","header":{"WWW-Authenticate":"Basic realm=\"security\" charset=\"UTF-8\""}}],"type":"security_exception","reason":"missing authentication credentials for REST request [/]","header":{"WWW-Authenticate":"Basic realm=\"security\" charset=\"UTF-8\""}},"status":401}

Шаг 4. Настройка Kibana и Filebeat для общения.

Как видно из Шага 3, что теперь неавторизованные запросы к Elasticsearch отбиваются с ошибкой. Для этого необходимо прописать в конфиг сервисов авторизационные данные (логин\пароль) которые мы указали в Шаге 3 на этапе работы с bin/elasticsearch-setup-passwords interactive.

Для Kibana необходимо в конфиге kibana.yml указать два параметра elasticsearch.username и elasticsearch.password:

elasticsearch.username: "kibana"
elasticsearch.password: "qazqaz1"   

В случае с Filebeat мы должны отредактировать конфиг filebeat.yml добавив в графу output.elasticsearch параметры авторизации username и password:

  username: "elastic"
  password: "qazqaz1"

Подробнее про настройку Filebeat.

После изменения конфига необходимо перезагрузить сервис.

Теперь при попытки зайти в Kibana, она спрашивает логин\пароль для входа. Первый вход совершаем от учетки elasic (пароль мы задавали в Шаге 3) и создаем себе персональную учетную запись.

Шаг 4.1. Скрываем пароль в конфиге Filebeat.

Если Kibana обычно находиться рядом с Elasticsearch, то Filebeat как агент зачастую находиться на удаленном сервере, и лежащий в открытом виде пароль не очень хорошая затея.
Но пароль можно скрыть с помощью секрета в хранилище ключей и указать в конфиге в качестве переменной.

Первым делом необходимо создать хранилище и добавить туда запись:

# filebeat keystore create
# filebeat keystore add ES_PWD

После, редактируем конфиг filebeat.yml изменим значение параметра password и перезапустим сервис:

username: "elastic"
password: "${ES_PWD}"

Теперь пароль от пользователя elastic скрыт от лишних глаз.
Подробнее о хранилище ключей.

Полезная информация и первоисточник:
https://www.elastic.co/blog/getting-started-with-elasticsearch-security
https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-passwords.html
https://www.elastic.co/guide/en/beats/filebeat/6.8/filebeat-configuration.html
https://www.elastic.co/guide/en/beats/filebeat/current/keystore.html

0

pg_cron установка и настройка

pg_cron это расширение для PostgreSQL реализующее cron внутри СУБД, т.е. задания запускаются самой СУБД, и синхронизируются на
Standby. В случае переезда на Standby задания начнут выполняться на нем. Это удобнее использования системного cron, если задания
касаются только PostgreSQL.
Документация и исходники https://github.com/citusdata/pg_cron

pg_cron можно как собрать из из исходников, так и установить из пакета:

sudo yum install pg_cron_11

Редактируем конфиг postgresql.conf:

shared_preload_libraries = 'pg_cron'
cron.database_name = 'postgres'

Читать далее

0

PgBouncer настройка пулера соединений PostgreSQL

PgBouncer (https://pgbouncer.github.io/) это пулер соединений для PostgreSQL. Если планируется что к базам будет много одновременных
коннектов, то необходимо настраивать пулер соединений, т.к. PostgreSQL на каждое соединение создает отдельный процесс и общая
производительность СУБД начинает деградировать с увеличением числа коннектов. Если планируется более 500-1000 соединений, то
настраивается пулер, например, pgbouncer.

Устанавливаем на сервер PostgreSQL pgbouncer и выдаем права на директории конфигов и логов:

sudo yum install pgbouncer
chown -R postgres:postgres /etc/pgbouncer
chmod 755 /var/log/pgbouncer

Читать далее

0

pgBackRest настройка бекапов PostgreSQL

Официальный User Guige.
Параметры конфигурации.

Устанавливаем на сервере PostgreSQL pgbackrest:

sudo yum install pgbackrest

Выдаем права владения postgres:postgres на файл конфига /etc/pgbackrest.conf:

chown postgres:postgres /etc/pgbackrest.conf

Далее, в зависимости от конфигурации, либо создаем локальную директорию для бекапов с владельцем postgres:postgres, либо
монтируем шару (например, /mnt/pgbackup как будет описано далее в инструкции) с тем же владельцем postgres:postgres.

Читать далее

0

Barman сжатие WAL

Barman это утилита для бекапирования кластера PostgreSQL.

В Barman доступно сжатие WAL-логов бекапов. (Сжатие FULL (base) бекапов, на текущий момент, средствами Barman недоступно.)
Для включения сжатия есть два варианта:
1. Включить сжатие глобально для всех бекапов, для этого нужно в конфиге /etc/barman.conf прописать в блоке [barman]:
[barman] …
compression = gzip

2. Включать сжатие только для нужных проектов (бекапов), для этого в конфиге конкретного бекапа нужно указать:
[backup_name] …
compression = gzip

Читать далее

0

Памятка по командам netstat

Список портов, которые «слушает» сервер:

netstat -an | grep -i listen

Список активных соединений TCP:

netstat -at

UDP:

netstat -au

Список активных соединений с отображением используемой службы, сервиса:

netstat -tp
0

OpenVPN за 5 минут одной командой

Скрипт подходит для Debian, Ubuntu и CentOS.
Позволяет выполнить как первоначальную настройку сервера, так и добавление openvpn клиентов.

wget https://git.io/vpn -O openvpn-install.sh && bash openvpn-install.sh

Репозиторий автора скрипта https://github.com/Nyr/openvpn-install

0

Алерты Grafana в Telegram через прокси

В моём случае Grafana работает на CentOs7.
На данный момент в Grafana (v6.1.4) не реализовано подключение прокси-сервера для отправки оповещений в telegram. При поиске в Google можно найти ряд статей (раз,два,три) в которых утверждается что она станет ходить через прокси, если его добавить переменные окружения с указанием прокси сервера:

export http_proxy="http://myproxy:3128"
export https_proxy="http://myproxy:3128"

но по какой-то причине этот способ у меня так и не заработал, графана игнорирует прокси и пытается отправить уведомление напрямую на api.telegram.org

Если способ выше вам так же не помог, предлагаю ознакомиться с «костылём» описанным ниже.
Суть кратко: будем отправлять все запросы в сторону https://api.telegram.org на свой сервер с Apache и на нём делать proxy_pass на реальный api.telegram.org.
Можно, конечно, просто на уровне IPTABLES редиректить все обращения на 443 порт на реальную API, но при таком раскладе мы займём 443 порт на нашей VPS, что не очень кошерно, сайтики с HTTPS уже не похостишь..
Читать далее

0

pg_stat_activity хранение истории запросов PostgreSQL

View pg_stat_activity позволяет посмотреть текущие запросы в PostgreSQL. Настроим автоматический сбор и хранение этой информации.

https://habr.com/ru/post/413411/
https://github.com/dbacvetkov/PASH-Viewer/wiki/How-to-create-pg_stat_activity-historical-table

Создаем таблицу pg_stat_activity_history для исторических данных:

--create table for historical data PG10+
create table pg_stat_activity_history as 
SELECT clock_timestamp() as sample_time, datname, pid, usesysid, usename, backend_type, application_name, client_hostname, client_addr, wait_event_type, wait_event, query, query_start, 1000 * EXTRACT(EPOCH FROM (clock_timestamp()-query_start)) as duration
from pg_stat_activity where 1=2;

--create table for historical data PG9.6
create table pg_stat_activity_history as 
SELECT clock_timestamp() as sample_time, datname, pid, usesysid, usename, application_name, client_hostname, client_addr, wait_event_type, wait_event, query, query_start, 1000 * EXTRACT(EPOCH FROM (clock_timestamp()-query_start)) as duration
from pg_stat_activity where 1=2;

create index pg_stat_activity_history_idx on pg_stat_activity_history(sample_time);

Читать далее

0