Обновление/Установка KUMA

• Обновление/Установка KUMA версии от 2.1.Х
• Установка KUMA с отказоустойчивым ядром - RAFT
• Установка KUMA с отказоустойчивым ядром - Kubernetes
• Установка KUMA на ОС с установленным антивирусом
• Подготовка Astra Linux 1.7.х (с картинками)

Обновление/Установка KUMA версии от 2.1.Х

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/2.1/ru-RU/217904.htm

Убедитесь, что все пункты из статьи подготовки в системе соблюдены

При установке / обновлении на версию 3.2.х если имя хоста НЕ должно начинаться с цифры

1. Создайте резервную копию ресурсов и сертификатов, см. советующий раздел в этой книге.

2. Распакуйте архив (операции выполняются на ядре системы KUMA): 

tar -xvf kuma-ansible-installer-(ВЕРСИЯ).tar.gz

3. Перейдите в распакованную папку: 

cd kuma-ansible-installer

4. Добавить файл лицензии в папку kuma-ansible-installer/roles/kuma/files и переименовать на license.key: 

cp ПУТЬ_ДО_КЛЮЧА*.key roles/kuma/files/license.key

5. ВАЖНО! Регистр написания хостнеймов в inventory должен совпадать с выводом значения на хостах команды 

hostname -f

6. ВАЖНО! Хостнейм при команде hostname -f должен содержать хотя бы одну точку, пример: kuma.local

7. Выполните команду копирования шаблона (либо подставьте ранее использованный файл single или distributed при обновлении, в случае первичной установки смотрите пример заполенения тут): 

В случае ручной правки файла старайтесь не добавлять лишних пробелов.

cp single.inventory.yml.template single.inventory.yml

sed -i "s/kuma.example.com/$(hostname -f)/g" single.inventory.yml

cp distributed.inventory.yml.template distributed.inventory.yml

8. На серверах хранилищ, где используется роль Keeper, включите использование ipv6 (желательно, но не обязательно).

<keeper_server>
    <enable_ipv6>false</enable_ipv6>
</keeper_server>

ВАЖНО! С сервера хранилища до ядра должен быть доступен 7220 порт.

TimeoutSec=57600
systemctl daemon-reload

/opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma 
db.users.updateMany({"accessMatrix":null},{$set: {"accessMatrix":{ "GET /resources" : false, "POST /resources/export" : false, "GET /services" : false, "POST /dictionaries/update" : false, "GET /assets" : false, "GET /dictionaries" : false, "POST /assets/import" : false, "POST /resources/upload" : false, "GET /users/whoami" : false, "GET /alerts" : false, "POST /events" : false, "GET /resources/download/:id" : false, "POST /alerts/close" : false, "GET /events/clusters" : false, "POST /resources/import" : false, "GET /activeLists" : false, "GET /tenants" : false, "POST /assets/delete" : false, "POST /resources/toc" : false, "POST /activeLists/import" : false}}}) 
systemctl restart kuma-core  

./install.sh ./inventory.yml -e "accept_eula=yes default_admin_password=yes"

/opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma
var tenantID = db.tenants.findOne({ main: true })._id;
db.settings.insert({_id: "f371fa1b-948e-45d2-a47c-86ddd67029ee", tenantID: tenantID, disabled: true, roleGroups: [], kind: 'adfs'}); 

9. Входим в ОС из-под суперпользователя (root), если это не было сделано ранее: 

sudo -i

10. Запустите установку (при установке все в одном используйте single.inventory.yml): 

./install.sh distributed.inventory.yml

11. При наличии ошибки в конце установки TASK [Start not orphaned KUMA storage services] считаем установку успешной. Эта ошибка связана с таймаутом запуска ClickHouse, время старта процесса занимает ~10 минут. Убедитесь, что служба clickhouse потребляет ресурсы командой top.

• • Лог хранилища ведется в: /opt/kaspersky/kuma/storage/<ID хранилища>/log/storage
    

12. Зайдите на веб интерфейс ядра KUMA по адресу ядра - https://<FQDN_CORE or IP_CORE>:7220 Учетные данные для входа по умолчанию: admin / mustB3Ch@ng3d!

В случае, если при установке произошел сбой (НЕ обновлении), перед последующей установкой рекомендуется выполнить ./uninstall.sh <ваш_инвентарь.yml>

Если деморесурсы не появились при первичной установке в активных сервисах рекомендуется ручаня установка сервисов - подробнее

Установка KUMA с отказоустойчивым ядром - RAFT

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора. Официальная документация по данному разделу приведена в Онлайн-справке на продукт.

Кластер RAFT поддерживается в KUMA с версии 4.0 и позволяет обеспечить доступность компонентов ядра KUMA,  в случае сбоя работы одного из компонентов. Допустимо развертывать только нечетное количество сервисов Ядра KUMA. 

Схема ядра в RAFT (хранилище представлено с двумя репликами, т.е. с копией данных)

Теория

В кластере Raft каждый из серверов в каждый момент времени находится в одном из трёх состояний:

• Leader (лидер) – обрабатывает все клиентские запросы, является source of truth всех данных в логе, поддерживает лог фоловеров.
• Follower (фоловер) – пассивный сервер, который только «слушает» новые записи в лог от лидера и редиректит все входящие запросы от клиентов на лидера. По сути, является hot-standby репликой лидера.
• Candidate (кандидат) – специальное состояние сервера, возможное только во время выбора нового лидера.

Во время нормальной работы в кластере только один сервер является лидером, все остальные – его фоловеры. Например, в случае 3 компонентов ядра из строя может выйти толкьо 1 компонент, для иного количества компонентов - пока работает формула (n+1)/2. Полезная ссылка для понимания механизма работы: https://thesecretlivesofdata.com/raft/

Сетевые задержки не должны превышать 150 мс.

Расширение ядра до кластера в Raft

Сценарии установки с установкой Ядра в кластере Raft смотреть можно тут

Данный сценарий реализуется, если KUMA находится в инсталяции, где одно ядро (standalone). Для этого необходимо подготовить дополнительные целевые машины для установки сервисов, а также на контрольной машинке настроить обмен SSH  ключами. После создать копию файла на контрольной машине (с которой предполагается развертывание) expand.inventory.yml.template из распакованного архива KUMA 

cp expand.inventory.yml.template expand.inventory.yml

Далее отредактировать файл expand.inventory.yml (разворачиваем дополнительные ядра 2 и 3):

В хостах указываем FQDN и проверяем их доступность с контрольной машины, а также на всех компонентах ядра должно быть единое время, настройте на всех машинах NTP.

Далее на контрольной машине с доступом root из папки с распакованным установщиком (скриншот выше) выполните следующую команду для начала установки:

./expand.sh expand.inventory.yml

В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml, появятся файлы для создания и установки дополнительных сервисов Ядра KUMA, для этого проверьте наличие директории /opt/kaspersky/kuma/kuma

В разделе Ресурсы → Активные сервисы нажмите Добавить и в раскрывающемся списке выберите Добавить сервис Ядро.

В открывшемся окне Добавить сервис Ядро укажите имя сервиса в поле Имя сервиса Ядро и нажмите Добавить. Добавленный сервис появится в списке Сервисы.

Установите флажок рядом с добавленным сервисом Ядра KUMA и на панели инструментов нажмите , в открывшемся меню нажмите Копировать идентификатор. Идентификатор сервиса Ядра KUMA понадобится для установки сервиса на сервере.

Далее на целевой машине необходимо установить службу специальным образом:

sudo /opt/kaspersky/kuma/kuma core --raft.join <FQDN хоста из секции kuma_core, где запущен первый сервис Ядра KUMA>:7210 --id <идентификатор сервиса Ядра KUMA, скопированный в веб-интерфейсе> --install

Повторите создание клиентской и серверной части сервиса Ядра KUMA для каждого хоста из группы kuma_core_peers.

На каждом хосте может быть установлен только один сервис Ядра KUMA.

После успешной установки в веб-интерфейсе KUMA, вы увидеть статус сервисов Вкл

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

Журналы Ядра KUMA хранятся в директории /opt/kaspersky/kuma/core/<идентификатор сервиса Ядра KUMA>/log/core.

Установка балансировщика - nginx

Установим балансировщик нагрузки nginx для удобства работы с кластером Raft, а именно обращение по единому hostname / IP-адресу.

Когда одна из нод кластера отказывает, балансировщик перенаправляет запросы на активные ноды 

Для установки балансировщика поднимем отдельный сервер и на него установим nginx, далее необходимо отредактировать файл /etc/nginx/nginx.conf и добавить конфиг в конец файла

stream {
    upstream raft_backend {
        server kuma-test.local:7220 max_fails=1 fail_timeout=5s;
        server kuma-core-2.local:7220 backup;
        server kuma-core-3.local:7220 backup;
    }

    server {
        listen 443;
        proxy_pass raft_backend;
        ssl_preread on;
    }
}

Далее перезапустить сервис systemctl restart nginx.service

Для проверки работоспособности отключаем сервис ядра на kuma-test  командой systemctl stop kuma-core-<идентификатор-ядра>.service. В браузере вводим https://<ip-балансировщика>, появится форма входа в интерфейс.

Далее нужно перейти в "Ресурсы" -> "Активные сервисы". Увидим, что сервис ядра отключен, но независимые компоненты имеют Статус: "Вкл"

Не забудьте запустить службу отключенного компонента, ядра systemctl start kuma-core-<идентификатор-ядра>.service

В данном случае в кластере всего три ноды, и больше одного выведенного из строя компонента ядра нельзя себе позволить, поскольку с менее чем 2 рабочими нодами теряется доступ к системе и перестает работать кластер

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

В нашем случае, если останется 1 живая нода - не сработает. Нода не образует кворум, а если захочет стать лидером, это никто не подтвердит.

Возможные ошибки кластера ядра:

Если вы столкнулись с ошибками после установки балансировщика, примеры:

request dropped as the cluster is not ready
failed to lookup: can't serve requests, not enough healthy nodes

Убедитесь, что у вас достаточное количество рабочих нод в кластере для его работы.

Альтернатива балансировщику - установка keepalived 

В основу данного способа заложена интеграция виртуального IP-адреса (VIP) с использованием функции keepalived для предоставления единой точки доступа. Такая конфигурация обеспечивает автоматическое переключение между узлами при отказе.  На каждом запускается скрипт для мониторинга состояния соответствующей службы ядра.  Все узлы обслуживают веб-интерфейс через собственные полные доменные имена (FQDN), но VIP обеспечивает унифицированный и стабильный доступ, обеспечивая доступность без вмешательства пользователя.

Детализация демонстрационных машин 

Мы также рекомендуем предоставлять отдельный сервера для каждого компонента.

После подготовки файла  distributed.inventory.yml, необходимо сконфигурировать VIP для всех нод

Установка Keepalived на все основные узлы: dnf install -y keepalived

Для каждого узла требуется собственный скрипт для мониторинга локальной службы KUMA Core. Сохраните скрипт как /etc/keepalived/check_kuma.sh.

Пример для Core1 (ksiem-core1):

#!/bin/bash
if systemctl is-active --quiet kuma-core-00000000-0000-0000-0000-000000000000; then  
exit 0
else  exit 1
fi

Настройте имя службы для каждого узла (каждый имеет уникальное имя). Вы можете найти основную службу KUMA, выполнив команду на каждом узле: systemctl list-units --type=service | grep kuma-core

Сделайте скрипт исполняемым: chmod +x /etc/keepalived/check_kuma.sh

Далее настройте keepalived. Создайте или отредактируйте файл /etc/keepalived/keepalived.conf на каждом узле. Ниже представлена ​​адаптированная конфигурация.

Core -1

vrrp_script chk_kuma {
    script "/etc/keepalived/check_kuma.sh"
    interval 2
    timeout 3
    fall 2
    rise 3
}
vrrp_instance VI_1 {
    state MASTER
    interface ens34              #необходимо поменять в соотетсвии со своей конфигурацией
    virtual_router_id 51
    priority 110
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secretpass
    }
    virtual_ipaddress {
        192.168.100.200
    }
    track_script {
        chk_kuma
    }
} 

Core -2

vrrp_script chk_kuma {
    script "/etc/keepalived/check_kuma.sh"
    interval 2
    timeout 3
    fall 2
    rise 3
}
vrrp_instance VI_1 {
    state BACKUP
    interface ens34             #поменяйте в соответcвии со своими параметрами
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secretpass
    }
    virtual_ipaddress {
        192.168.100.200
    }
    track_script {
        chk_kuma
    }
}

Core - 3

vrrp_script chk_kuma {
    script "/etc/keepalived/check_kuma.sh"
    interval 2
    timeout 3
    fall 2
    rise 3
}
vrrp_instance VI_1 {
    state BACKUP
    interface ens34             #поменяйте в соответcвии со своими сетевыми параметрами
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secretpass
    }
    virtual_ipaddress {
        192.168.100.200
    }
    track_script {
        chk_kuma
    }
}

Далее выполните команды 

systemctl enable keepalived
systemctl start keepalived

Зайдите в веб-интерфейс KUMA через VIP FKDN (ksiem.demo.lab) активируйте KUMA и убедитесь, что все ноды сервисов установлены и их статус "зеленый" 

Возможные проблемы

Проблема 1

Когда устанавливается сервис хранилища или другие ноды хранилища, необходимо указать все FQDN  ядер в команде, ниже представлен пример того, как установить хранилище в Raft -е ( 2 replica и 3 keeper)

Проблема 2. Как коллектор и коррелятор будут работать в этом режиме?

Когда вы создаете коллектор или коррелятор, все 3 ноды автоматически добавятся в скрипт, запустите этот скрипт на сервере (коллектора или коррелятора), в этом случае, если core1 упадет, то вы все равно будете иметь доступ к настройкам коррелятора или коллектора

Установка KUMA с отказоустойчивым ядром - Kubernetes

Отказоустойчивость KUMA обеспечивается путем внедрения ядра KUMA в кластер Kubernetes, развернутый установщиком KUMA. В качестве распределённого блочного хранилища для кластера используется Longhorn. Схема:

Для установки KUMA в отказоустойчивом исполнении используется установщик kuma-ansible-installer-ha-2.1. X.tar.gz. Конфигурация кластера Kubernetes задается в файле инвентаря k0s.inventory.yml. Требования к устройствам для установки KUMA в Kubernetes - https://support.kaspersky.com/help/KUMA/3.0.2/ru-RU/217889.htm 

Минимально кластер должен включать:

• один контроллер (выделенный или совмещенный с рабочим узлом);
• один рабочий узел (выделенный, или совмещенный с контроллером);
• 0 и более выделенных рабочих узлов.

Минимальная конфигурация, на которую можно произвести установку - один контроллер, совмещенный с рабочим узлом. Данная конфигурация не обеспечивает отказоустойчивости core и служит для демонстрации возможностей/проверки программной среды.

Для реализации отказоустойчивости необходим выделенный контроллер кластера  и минимум 2 рабочих узла. Если контроллер кластера содержит рабочую нагрузку и под (pod) с Core размещается на нем, то его отключение приведет к полной потере доступа к Core.

На всех компонентах ядра должно быть единое время, настройте на всех машинах NTP

На контроллерах кластера должен быть уникальный machine-id, это значит, что не рекомендуется клонирование машин с этой ролью, либо необходимо изменить ID на машинах до установки. Внимание! Допустимость данной операции должен определять администратор хоста с учётом возможного использования machine-id другими сервисами! rm /etc/machine-id /var/lib/dbus/machine-id && dbus-uuidgen --ensure=/etc/machine-id && dbus-uuidgen --ensure && reboot

1. В нашем случае мы будем использовать установку All-In-One хост kuma-1.local, один узел контроллера (хост kuma-2.local) и два рабочих узла (хост kuma-3.local и kuma-4.local), пример файла инвентаря: https://box.kaspersky.com/f/bf06497b5b004dc3b1e5/  Другие примеры инвентарей: https://box.kaspersky.com/d/b397490dc08048acb671/  

2. При установке с нуля kuma_core игнорируется, его заполнение нужно только для переноса ранее установленной коры без HA в кластер Kubernetes
   Т.е. kuma_core должен быть равен одному из kuma_worker, если у нас уже есть кума и мы тащим ее в кубер. 

3. В распределенной установке kuma в секции инвентаря kuma_core нужно указать хост, который есть в роли worker (один из двух)
4. ВАЖНО! Для успешной установки должны быть соблюдены следующие требования:
   • все машины кластера должны быть добавлены в /etc/hosts;
   • установлены пакеты в соответствии с: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/244399.htm;
   • На Astra Linux  на машине балансировщика нужно установить в дополнение пакету nginx еще один пакет libnginx-mod-stream
   • в /var/lib/ должно быть не менее 32GB свободного места;
     
5. Значение переменных в инвентаре ansible:
   • low_resources – использовать минимальные ресурсы для разворачивания? Отсутсвует по умолчанию. (Достаточно ресурсов: 2 CPU 4 RAM, НО при этом создается том хранения 4 Гб, без этого параметра том создается 512 Гб)
   • для части инвентаря kuma_k0s и переменных ansible_host важно указывать IP адреса
   • kuma_managed_lb: false - если используется собственный (балансировщик организации, не KUMA) балансировщик, при этом указать FQDN этого балансировщика (для корректного формирования сертификата коры)
   • no_firewall_actions: false - инсталлятор будет пытаться открыть необходимые порты на МЭ данного хоста
   • Остальные значения переменных: https://support.kaspersky.ru/help/KUMA/3.4/ru-RU/244406.htm 
6. Создайте резервную копию ресурсов и сертификатов, см. советующий раздел в этой инструкции.
7. Распакуйте архив (операции выполняются на ядре системы KUMA): tar -xvf kuma-ansible-installer-(ВЕРСИЯ).tar.gz
8. Перейдите в распакованную папку: cd kuma-ansible-installer
9. Добавить файл лицензии в папку kuma-ansible-installer/roles/kuma/files и переименовать на license.key: cp ПУТЬ_ДО_КЛЮЧА*.key roles/kuma/files/license.key
10. Выполните команду копирования шаблона (пример заполненного файла в п. 0): cp k0s.inventory.yml.template k0s.inventory.yml
11. ВАЖНО! Регистр написания хостнеймов в inventory должен совпадать с выводом значения на хостах команды hostname -f
12. ВАЖНО! Хостнейм при команде hostname -f должен содержать хотя бы одну точку, пример: kuma.local
13. Входим в ОС из-под суперпользователя (root), если это не было сделано ранее: sudo -i
14. Запустите установку: ./install.sh k0s.inventory.yml
15. Зайдите на веб интерфейс ядра KUMA по одному из адресов рабочих узлов или балансировщика, например, в нашем случае это - https://192.168.0.153:7220 Учетные данные для входа по умолчанию: admin / mustB3Ch@ng3d!
16. Для начального администрирования кластера воспользуйтесь командами этого раздела.

В случае, если при установке произошел сбой (НЕ обновлении), перед последующей установкой рекомендуется выполнить uninstall.sh и перезагрузить все узлы кластера. Если uninstall выполнить нельзя (идет миграция существующей установки в кластер), то перед повторной попыткой установки нужно вручную выполнить команду sudo k0s reset (если долгий reset, то rm -rf /var/lib/k0s/containerd, затем k0s reset -d) на всех узлах кластера и перезагрузить их

Перестроение между воркерами в кластере Kubernetes происходит с таймаутом ~ 5 мин

Отказоустойчивость балансировщиков, см. тут

Для работы с кластером можно использовать команды и инструменты отсюда

Видео установки в конфигурации AiO-1LB-1CP-2W тут

Установка KUMA на ОС с установленным антивирусом

В случае установки KUMA на ОС с установленным антивирусом необходимо в политике антивирусной защиты выставить исключение проверок средства защиты для папки:

/opt/kaspersky/kuma/*

Более гранулярный доступ описан в этой статье - https://support.kaspersky.ru/kuma/4.2/230384 

Подготовка Astra Linux 1.7.х (с картинками)

Пак автомной установки KUMA (офлайн пакеты для Astra) — ссылка на mail.ru тк объем большой

Начало установки. 

Выбор языка и режим «Графическая установка». 

На скриншотах ниже показан пошаговый процесс установки с комментариями.

Установщик Astra Linux позволяет ввести только короткое имя компьютера (short host name). Задать FQDN имя компьютера (long host name) возможно после установки ОС. Подробнее см. Примечание 1.

Разметка дисков выполняется на усмотрение администратора ОС. Учитывайте пожалуйста пункты из подготовки ОС.
Для целей демонстрационной установки выбран метод «Авто – использовать весь диск».

Минимальная установка для сервера без графического интерфейса.

Выбор уровня защищенности согласно документации для используемого приложения. Для целей демонстрационной установки выбран уровень “Орел”.

Примечание 1

Сразу после установки ОС в минимальной конфигурации нет сети. И имя компьютера установлено в short host name.

Для конфигурации сетевых параметров ОС можно применить один из способов:

Пакет NetworkManager:

• предоставляет утилиту nmtui для настройки параметров в псевдографическом интерфейсе консоли;
• содержит инструмент nmcli для гибкой настройки в командной строке.

Пакет ifupdown с настройками конфигурационного файла /etc/network/interfaces

• будет удобен, если используется простая конфигурация с получением сетевого адреса по DHCP.
  

https://wiki.astralinux.ru/pages/viewpage.action?pageId=3277370 
Во избежание конфликтов со службой networking служба NetworkManager  НЕ РАБОТАЕТ с сетевыми интерфейсами, перечисленными в файле /etc/network/interfaces или в файлах в каталоге /etc/networking/interfaces.d/. По умолчанию в файле /etc/network/interfaces присутствует только интерфейс локальной петли (loopback).

Использование NetworkManager

Сразу после установки ОС вы можете установить соответствующий пакет командой:

sudo apt install network-manager

По умолчанию используется репозиторий установочного диска Astra Linux, который является активным в конфигурационном файле /etc/apt/sources.list. Публичные репозитории закомментированы.

Чтобы приступить к настройке сетевых параметров в псевдографике выполните команду: nmtui

Здесь вы можете изменить имя узла на FQDN, настроить сетевой интерфейс, проверить параметры ipv4 и ipv6.

Использование конфигурационного файла interfaces. (сложнее)

Если не требуется специальная настройка и параметры сети будут получены по DHCP. Открыть на редактирование:

sudo nano /etc/network/interfaces

Добавить в файл комментарий, начинающийся с # (по желанию) и параметры 

# The eth0 network interface
auto eth0
iface eth0 inet dhcp

Перезапустите службу сети: sudo /etc/init.d/networking restart
Проверьте параметры сетевого интерфейса: sudo ifconfig

Задайте имя компьютера в FQDN:

hostname -f
hostnamectl
hostnamectl set-hostname app-server-01.example.com

Пропишите IP адрес и FQDN в файле /etc/hosts

nano /etc/hosts

Текстовый файл hosts:

127.0.0.1       localhost
192.168.1.1     app-server-01.example.com
# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

статья будет в скором времени дополнена ...