Gitlab. Mirroring repositories.

При необходимости переноса проекта из стороннего репозиторияв в Ваш локальный, Gitlab предлагает инструмент Mirroring repositories.

Зеркалирование в Gitlab поддерживает два режима:
Push: зеркалирование проекта из локального Gilbab в удаленный репозиторий.
Pull: зеркалирование проекта из удаленного репозитория в локальный Gilbab.

Рассмотрим функциональность инструмента Mirroring repositories на примере зеркалирования проекта из удаленного Atlassian Bitbucket в локальный Gitlab.

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

Projects > Setting > Repository > Mirroring repositories

Git repository URL: адрес удаленного репозитория
Mirror direction: в нашем случае это Pull
Authentication method: в нашем случае это аутентификация по паролю, но можно и по SSH-ключу.
Password: сам пароль.
Mirror user: пользователь от которого осуществляется настройка.
Так же стоит активировать функцию Overwrite diverged branches, она позволит перезаписывать проект, если версии веток разошлись между репозиториями.

После настройки первая синхронизация займет некоторое время.

Готово, теперь репозиторий будет обновляться каждые ~30 минут. Так же можно форсировать синхронизацию кнопкой «Update now»

Как это работает согласно официальной документации:

Как только функция Mirroring repositories включена для хранилища, хранилище добавляется в очередь.

Раз в минуту задание Sidekiq cron планирует обновления зеркал репозитория на основе:
— Доступности Sidekiq.
— Количество зеркал репозитория, уже находящихся в очереди, которые должны быть обновлены. Срок выполнения зависит от того, когда зеркало хранилища последний раз обновлялось, и сколько раз оно повторялось.

Зеркала репозитория обновляются, когда Sidekiq становится доступным для их обработки. Если процесс обновления зеркала репозитория:
— Успешно, обновление будет снова поставлено в очередь, по крайней мере, через 30 минут.
— Сбой (например, ветвь отклонена от восходящего направления), попытка будет предпринята позже. Зеркала могут выходить из строя до 14 раз, прежде чем они не будут поставлены в очередь для обновления снова (об этом моменте сы поговорим чуть позже).

Возможные ошибки.

При синхронизации проектов я столкнулся с проблемой наличия недопустимых имен веток в удаленном репозитории.

Репозитории синхронизировались, данные внутри обновлялись, но я получал ошибку «Branch name is invalid».

Как быть, что делать?
Смотрим ветки в нашем локальном репозитории, смотрим ветки в удаленном репозитории в Bitbucket. Оказалось у нас не хватает одной ветки с именем «-readmemd-1572439278772», которая не прошла проверку на доступность имени и не синхронизировалась в наш Gilbab

 ~ git branch -a
...
remotes/origin/------------/-readmemd-1572439278772
...

В нашем случае мы попросили удалить эту ветку, т.к. она была не актуальна.

Первоисточник: https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html
Тикет на ошибку «Branch name is invalid: https://gitlab.com/gitlab-org/gitlab/issues/35804

0

Интеграция GitLab и Jenkins. Развертывание по событию.

Настройка непрерывной интеграции между GitLab и Jenkins. Необходимо запускать job в Jenkins всякий раз, когда в ветке master в GitLab происходят изменения.

Шаг 1. Настройка Webhooks в GitLab.

GitLab > Projects > Settings > Integrations

В нашем случае, настраиваем Webhooks на push и merge события в ветке master.

URL: указываем проект в Jenkins
Push events: указываем необходимую ветки, если пусто, то действия распространяются на все ветки.
Merge request events: активно
SSL verification: активно

Шаг 2. Настройка Build Triggers в проекте в Jenkins

Предварительно необходимо установить плагин GitLab Plugin:
Jenkins > Manage Jenkins > Plugin Manager > Available > install GitLab Plugin

Jenkins > Ваш Проект > Configure > Build Triggers

Необходимо активировать пункт Build when a change is pushed to GitLab. GitLab webhook URL: https://localhost/jenkins/project/TestJenkinsProjekt

Шаг 3. Тестирование интеграции.

Выбираем необходимый Trigger

После имитации триггера стартует job в Jenkins с припиской: Started by GitLab push by Username

Первоисточник: https://docs.gitlab.com/ee/user/project/integrations/webhooks.html

1+

Исключения для двухфакторной аутентификации OpenVpn

В статье Двухфакторная аутентификация OpenVpn клиентов (OpenVpn + Google Authenticator) на CentOs 7/8 подробно описано как настроить двухфакторную аутентификацию для клиентов open-vpn.

Ниже описано как сделать исключения.

Допустим, что не требуется использовать двухфакторную аутентификацию для клиента с именем client1 и для любого клиента, который подключается с публичного ip 111.111.111.111


1. Для удобства создадим группу пользователей, для которых будет отключена двухфакторная аутентификация и добавим пользователя client1 в неё:

groupadd no2fa
usermod -g no2fa client1

2. Создадим файл, в котором опишем правила исключения:

nano /etc/security/no2fa.conf
# Содержимое файла:
# No 2fa:
+ : (no2fa) : ALL # Входящие в группу no2fa с любым IP
+ : ALL : 111.111.111.111 # Любые пользователи с IP 111.111.111.111
# All other hosts need two step verification
- : ALL : ALL

3. В файл /etc/pam.d/openvpn добавляем первой строкой:

auth [success=done default=ignore] pam_access.so accessfile=/etc/security/no2fa.conf

Перезапускаем openvpn-server и правила исключений будут работать.

Использованы материалы — https://serverfault.com/questions/799657/ssh-google-authenticator-ignore-whitelist-ips

0

Двухфакторная аутентификация OpenVpn клиентов (OpenVpn + Google Authenticator) на CentOs 7/8

1. Устанавливаем необходимые компоненты для работы и настройки OpenVpn:

yum install epel-release
yum -y --enablerepo=epel install openvpn easy-rsa nano
cd /etc/openvpn/
mkdir ccd
mkdir clients

Для более удобной работы с easy-rsa копируем все его файлы в /etc/openvpn/easy-rsa/

cp -a /usr/share/easy-rsa/3.0.3 /etc/openvpn/easy-rsa

Важно! Если у вас CentOs 8 то в репозитории нет easy-rsa, устанавливается так:

yum -y install unzip zip wget
cd ~
wget https://github.com/OpenVPN/easy-rsa/archive/master.zip
unzip master.zip
cp -a easy-rsa-master/easyrsa3/ /etc/openvpn/easy-rsa/

Читать далее

0

Cisco 5585 Multicontext — OID для оценки утилизации CPU

SNMP OID для 5585 работающей в мультиконтекстном режиме с версией ASA 9.1

Для получения утилизации CPU за 1 минуту отдельным контекстом (собирается с каждого контекста):

1.3.6.1.4.1.9.9.109.1.1.1.1.4

Для получения утилизации CPU всей ASA за 1 минуту (собирается с админского контекста):

1.3.6.1.4.1.9.9.109.1.1.1.1.4.3

За 5 секунд и 5 минут OIDы находятся рядом с этими, при необходимости выбирается snmp-walkом

0

PostgreSQL компиляция библиотеки libzbxpgsql и пересборка RPM-пакета

Библиотека libzbxpgsql используется для мониторинга PostgreSQL в Zabbix. Последний релиз библиотеки был в 2017 году и свежий пока не вышел, в то же время, последняя версия libzbxpgsql не работает с zabbix agent версий 4+. В официальном репозитории https://github.com/cavaliercoder/libzbxpgsql есть фикс этой проблемы https://github.com/cavaliercoder/libzbxpgsql/pull/141, фикс проблемы с DEBUG логированием zabbix агентом https://github.com/cavaliercoder/libzbxpgsql/pull/142.
Для того чтобы можно было использовать исправления, необходима виртуалка с CentOS 7+ и возможностью поставить на нее пакеты для компиляции исходников (make, gcc и т.д.).
Так же ставим пакет rpm-build, он потребуется для пересборки rpm-пакета:

yum install rpm-build

Устанавливаем последнюю доступную версию пакета libzbxpgsql (из репозитория или можно перекинуть на машину свой пакет и поставить локально):

yum install libzbxpgsql

Читать далее

0

Ansible включение тайминга выполнения задач

В Ansible можно включить тайминг времени запуска и выполнения тасок, в результате ход выполнения плейбуков приобретет подобный вид:

TASK [restore_postgres : Select target DB size (MB)]
********************************************************************************************************************
Thursday 26 September 2019 10:40:20 +0300 (0:00:00.061) 0:12:12.391 ****
ok: [bufferdb]
TASK [restore_postgres : Set DBSize to variable]
************************************************************************************************************************
Thursday 26 September 2019 10:40:21 +0300 (0:00:00.558) 0:12:12.949 ****
ok: [bufferdb]
TASK [restore_postgres : debug]
*****************************************************************************************************************************************
Thursday 26 September 2019 10:40:21 +0300 (0:00:00.060) 0:12:13.010 ****
ok: [bufferdb] => {
"msg": "Database size in MB is: 33189.0"
}

Читать далее

0

Elasticsearch. Настройка ILM

Статья является вольной интерпретацией оригинальной статьи из документации Elastic.

В Elasticsearch благодаря функционалу управления жизненным циклом индекса (index lifecycle management, сокращенно ILM) стало доступным управлять состоянием индекса, замораживать, сжимать или вовсе удалять его.

В этой статье будет показан простой пример удаления индекса спустя указанный промежуток времени в Elasticsearch v. 7.3.2.

Настроить правила жизненного цикла индекса и применить их к индексу можно двумя способами:
1. По средством Dev Tools в интерфейсе Kibana или curl из консоли терминала, если Kibana не используется в кластере.
2. Либо настроить политику использую интерфейс Kibana во вкладке Management > Index Lifecycle Policies.

Сперва рассмотрим первый вариант и создадим политику с помощью запроса во вкладке Dev Tools.

Настройка через консоль Dev Tools.

Проверяем список уже имеющихся политик:

GET _ilm/policy

По умолчанию будет присутствовать стандартная политика watch-history-ilm-policy:

{
  "watch-history-ilm-policy" : {
    "version" : 1,
    "modified_date" : "2019-07-02T07:58:10.186Z",
    "policy" : {
      "phases" : {
        "delete" : {
          "min_age" : "7d",
          "actions" : {
            "delete" : { }
          }        }      }    }  }}

Создадим собственное правило:

PUT _ilm/policy/filebeat-7.3.2  
{
  "policy": {                       
    "phases": {
      "warm": {                      
        "actions": {
          "rollover": {             
            "max_size": "1GB",
            "max_age": "1h"
          }
        }
      },
      "delete": {
        "min_age": "1h",           
        "actions": {
          "delete": {}              
        }
      }
    }
  }
}

Давайте подробнее рассмотрим наше действие и разберем основные параметры запроса.
PUT _ilm/policy/filebeat-7.3.2 — создаем политику и именем filebeat-7.3.2.
«phases»: «warm» — Определяем фазу в которой окажется индекс. Подробнее про фазы ILM.
«actions»: «rollover» — Определяем действие, которое произойдет с индексом в зависимости от параметров.
«max_size»: «1GB» — Определяем первый параметр для перехода индекса в другую стадию — максимальный размер индекса.
«max_age»: «1h» — Определяем второй параметр — возраст индекса.
«delete»: «min_age»: «1h» — по достижению одного из вышеперечисленных параметров спустя указанное время (1 час) индекс удлалиться.
«actions»: «delete» — Определяем действие для удаления индекса.

Получаем положительный ответ «acknowledged» : true.
Вновь проверяем список политик:

GET _ilm/policy

Видим новое правило filebeat-7.3.2, которое мы создали:

{
  "filebeat-7.3.2" : {
    "version" : 1,   //версия правила, будет расти после каждого изменения. Немного подробнее ниже.
    "modified_date" : "2019-09-23T13:40:33.031Z", //дата изменения
    "policy" : {
      "phases" : {
        "hot" : {
          "min_age" : "0ms",
          "actions" : {
            "rollover" : {
              "max_size" : "1gb",
              "max_age" : "1h"
            }
          }
        },
        "delete" : {
          "min_age" : "1h",
          "actions" : {
            "delete" : { }          }        }      }    }  },
  "watch-history-ilm-policy" : {
    "version" : 1,
    "modified_date" : "2019-07-02T07:58:10.186Z",
    "policy" : {
      "phases" : {
        "delete" : {
          "min_age" : "7d",
          "actions" : {
            "delete" : { }          }        }      }    }  }}

После создания правила, его необходимо применить непосредственно к индексам. Можно применить правила как для одного конкретного индекса (что в целом не имеет смысла), так и для темплейта в целом.

Создание темплейта для индексов :
Внимание, если template с именем filebeat-7.3.2 уже существует, следующее действие его перезапишет

PUT _template/filebeat-7.3.2
{
  "index_patterns": ["filebeat-7.3.2-*"],                 
  "settings": {
    "index.lifecycle.name": "filebeat-7.3.2" 
  }
}

В настройка шаблона мы указали какие индексы подпадают под шаблон «index_patterns»: [«filebeat-7.3.2-*»], т.е. все индексы которые начинаются с filebeat-7.3.2-, какую политику использовать индексам «index.lifecycle.name»: «filebeat-7.3.2».

Важно помнить, что если вы используете filebeat 7 версии, то он создает темплейт в Elasticsearch уже с указанием используемой политики:
Посмотрим стандартный шаблон который создаем сам filebeat

GET _template/filebeat-7.3.2

Мы видим, что он по умолчанию использует политику с именем filebeat-7.3.2, даже если она еще не создана.

{
  "filebeat-7.3.2" : {
    "order" : 1,
    "index_patterns" : [
      "filebeat-7.3.2-*"
    ],
    "settings" : {
      "index" : {
        "lifecycle" : {
          "name" : "filebeat-7.3.2",
          "rollover_alias" : "filebeat-7.3.2"
...

В идеале создать отдельный теплейт для с паттерном индексов filebeat-7.3.2-* параллельно стандартному темплейту filebeat.

Вернемся непосредственно к ILM.
После создания политики и применения ее индексам можем проверить состояние жизненного цикла индекса:
— для всех индексов:

GET filebeat-7.3.2-*/_ilm/explain

Получаем информацию о текущих стадиях всех индексов

{
  "indices" : {
    "filebeat-7.3.2-2019.09.23-000004" : {
      "index" : "filebeat-7.3.2-2019.09.23-000004",
      "managed" : true,
      "policy" : "filebeat-7.3.2",
      "lifecycle_date_millis" : 1569248425250,
      "phase" : "warm",
      "phase_time_millis" : 1569248426531,
      "action" : "complete",
      "action_time_millis" : 1569248485680,
      "step" : "complete",
      "step_time_millis" : 1569248485680,
      "phase_execution" : {
        "policy" : "filebeat-7.3.2",
        "phase_definition" : {
          "min_age" : "0ms",
          "actions" : {
            "shrink" : {
              "number_of_shards" : 1
            }          }        },
        "version" : 2,
        "modified_date_in_millis" : 1569237244490
      }    },
    "filebeat-7.3.2-2019.09.23-000005" : {
      "index" : "filebeat-7.3.2-2019.09.23-000005",
      "managed" : true,
      "policy" : "filebeat-7.3.2",
      "lifecycle_date_millis" : 1569248424138,
      "phase" : "hot",
      "phase_time_millis" : 1569248425501,
      "action" : "rollover",
      "action_time_millis" : 1569248485824,
      "step" : "check-rollover-ready",
      "step_time_millis" : 1569248485824,
      "phase_execution" : {
        "policy" : "filebeat-7.3.2",
        "phase_definition" : {
          "min_age" : "0ms",
          "actions" : {
            "rollover" : {
              "max_size" : "50mb",
              "max_age" : "1h"
            }
          }
        },
        "version" : 2,
        "modified_date_in_millis" : 1569237244490
      }    }  }}

— для конкретного индекса (вместо * указываем полное имя индекса):

GET filebeat-7.3.2-*/_ilm/explain

GET filebeat-7.3.2-2019.09.23-000004/_ilm/explain

Получаем информацию о текущей стадии на которой находится индекс:

{
  "indices" : {
    "filebeat-7.3.2-2019.09.23-000004" : {
      "index" : "filebeat-7.3.2-2019.09.23-000004",
      "managed" : true,
      "policy" : "filebeat-7.3.2",
      "lifecycle_date_millis" : 1569248425250,
      "phase" : "warm",
      "phase_time_millis" : 1569248426531,
      "action" : "complete",
      "action_time_millis" : 1569248485680,
      "step" : "complete",
      "step_time_millis" : 1569248485680,
      "phase_execution" : {
        "policy" : "filebeat-7.3.2",
        "phase_definition" : {
          "min_age" : "0ms",
          "actions" : {
            "shrink" : {
              "number_of_shards" : 1
            }
          }
        },
        "version" : 2,
        "modified_date_in_millis" : 1569237244490
      }    }  }}

Стоит обратить внимание, на параметры:
— «phase» : «hot»\»warm» — текущая стадия индекса
— «action» : «rollover»\»complete» — ожидаемое действие
— «step» : «check-rollover-ready»\»complete» — текущий шаг
— «version» : 2 — используемая версия правила.

Остановимся подробнее на параметре version. Важно помнить, что при изменении политики меняется и ее версия. Однако индексы автоматически не меняют используемую версию политики. Говоря простым языком, после изменения настрое политики, индексы не применят эти изменения и останутся на старой версии.

Создание правила через интерфейс Kibana

Настроить политику можно использую интерфейс Kibana, переходим во вкладку Management > Index Lifecycle Policies и нажимаем кнопку «Create policy«.

Настраиваем необходимые параметры, в нашем случае необходимо включить функцию Delete phase, заполняем остальные поля по примеру:

После заполнения нужных полей можно нажать кнопку «Show JSON«, чтобы увидеть как наш конфиг будет выглядеть в json. Его же можно использовать во вкладке Dev Tools.

Далее создаем template во вкладке Dev Tools, об этом описано выше, не буду повторяться. Да, к сожалению, через интерфейс Kibana нельзя управлять настройками темплейтов.

После настройки политики и шаблонов переходим во вкладку Management > Index Management выбираем нужный нам индекс, в графе Index lifecycle management будут подробности состояния кластера:

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

Отдельно хочу обратить на имена индексов. Мы используем Rollover Action в нашей политике, которая требует, чтобы имя нашего индекса заканчивалось цифрой. В нашем случае мы использовали 000001. Это важно, чтобы Rollover мог увеличивать это число при присвоении имени новому индексу, созданному при пролонгации.
Небольшой пример в картинках, как это работает:
Скормил filebeat несколько файлов с логами превышающих объем в 50 МБ, Elasticsearch создал два индекса.

Спустя несколько часов первые индексы были удалены, а новым были присвоены порядковые номера 000003 и 000004.

Полезная информация и первоисточник:
https://www.elastic.co/guide/en/elasticsearch/reference/current/index-lifecycle-management.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-index-lifecycle-management.html

1+

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