Руководство администратора

В этой главе представлена информация об установке и настройке SIEM-системы KUMA.

Установка и удаление KUMA

Развернуть всё | Свернуть всё

Для выполнения установки вам понадобится дистрибутив:

• kuma-ansible-installer-<номер сборки>.tar.gz содержит все необходимые файлы для установки KUMA без поддержки отказоустойчивых конфигураций.
• kuma-ansible-installer-ha-<номер сборки>.tar.gz содержит все необходимые файлы для установки KUMA в отказоустойчивой конфигурации.

Для установки вам понадобится файл установщика install.sh и файл инвентаря с описанием инфраструктуры. Файл инвентаря вы сможете создать на основе шаблона. Каждый дистрибутив содержит файл установщика install.sh и следующие шаблоны файла инвентаря:

• single.inventory.yml.template
• distributed.inventory.yml.template
• expand.inventory.yml.template
• k0s.inventory.yml.template

KUMA размещает свои файлы в папке /opt, поэтому мы рекомендуем сделать /opt отдельным разделом и выделить под него все дисковое пространство, за исключением 16 ГБ для операционной системы.

Установка KUMA выполняется одинаково на всех хостах при помощи установщика и подготовленного вами файла инвентаря, в котором описана конфигурация. Мы рекомендуем заранее продумать схему установки.

Доступны следующие варианты установки:

• Установка на одном сервере

  Схема установки на одном сервере

  

  Установка на одном сервере

  Пример файла инвентаря для схемы установки на одном сервере

  all:

  vars:

  deploy_to_k8s: false

  need_transfer: false

  generate_etc_hosts: false

  deploy_example_services: true

  no_firewall_actions: false

  kuma:

  vars:

  ansible_connection: ssh

  ansible_user: root

  children:

  kuma_core:

  hosts:

  kuma1.example.com:

  mongo_log_archives_number: 14

  mongo_log_frequency_rotation: daily

  mongo_log_file_size: 1G

  kuma_collector:

  hosts:

  kuma1.example.com

  kuma_correlator:

  hosts:

  kuma1.example.com

  kuma_storage:

  hosts:

  kuma1.example.com:

  shard: 1

  replica: 1

  keeper: 1

  Вы можете установить все компоненты KUMA на одном сервере: в файле инвентаря single.inventory.yml для всех компонентов следует указывать один сервер. Установка "все в одном" может обеспечить обработку небольшого потока событий - до 10000 EPS. Если вы планируете использовать много макетов панели мониторинга и обрабатывать большой объем поисковых запросов, одного сервера может не хватить. Мы рекомендуем выбрать распределенную установку.

• Распределенная установка

  Схема распределенной установки

  

  Схема распределенной установки

  Пример файла инвентаря для схемы распределенной установки

  all:

  vars:

  deploy_to_k8s: false

  need_transfer: false

  generate_etc_hosts: false

  deploy_example_services: false

  no_firewall_actions: false

  kuma:

  vars:

  ansible_connection: ssh

  ansible_user: root

  children:

  kuma_core:

  hosts:

  kuma-core-1.example.com:

  ip: 0.0.0.0

  mongo_log_archives_number: 14

  mongo_log_frequency_rotation: daily

  mongo_log_file_size: 1G

  kuma_collector:

  hosts:

  kuma-collector-1.example.com:

  ip: 0.0.0.0

  kuma_correlator:

  hosts:

  kuma-correlator-1.example.com:

  ip: 0.0.0.0

  kuma_storage:

  hosts:

  kuma-storage-cluster1-server1.example.com:

  ip: 0.0.0.0

  shard: 1

  replica: 1

  keeper: 0

  kuma-storage-cluster1-server2.example.com:

  ip: 0.0.0.0

  shard: 1

  replica: 2

  keeper: 0

  kuma-storage-cluster1-server3.example.com:

  ip: 0.0.0.0

  shard: 2

  replica: 1

  keeper: 0

  kuma-storage-cluster1-server4.example.com:

  ip: 0.0.0.0

  shard: 2

  replica: 2

  keeper: 0

  kuma-storage-cluster1-server5.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 1

  kuma-storage-cluster1-server6.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 2

  kuma-storage-cluster1-server7.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 3

  Вы можете установить сервисы KUMA на разных серверах: конфигурацию для распределенной установки вы можете описать в файле инвентаря distributed.inventory.yml.

• Распределенная установка в отказоустойчивой конфигурации

  Схема распределенной установки в отказоустойчивой конфигурации

  

  Распределенная установка в отказоустойчивой конфигурации

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

  all:

  vars:

  deploy_to_k8s: true

  need_transfer: true

  generate_etc_hosts: false

  airgap: true

  deploy_example_services: false

  no_firewall_actions: false

  kuma:

  vars:

  ansible_connection: ssh

  ansible_user: root

  children:

  kuma_core:

  hosts:

  kuma-core-1.example.com:

  mongo_log_archives_number: 14

  mongo_log_frequency_rotation: daily

  mongo_log_file_size: 1G

  kuma_collector:

  hosts:

  kuma-collector-1.example.com:

  ip: 0.0.0.0

  kuma-collector-2.example.com:

  ip: 0.0.0.0

  kuma_correlator:

  hosts:

  kuma-correlator-1.example.com:

  ip: 0.0.0.0

  kuma-correlator-2.example.com:

  ip: 0.0.0.0

  kuma_storage:

  hosts:

  kuma-storage-cluster1-server1.example.com:

  ip: 0.0.0.0

  shard: 1

  replica: 1

  keeper: 0

  kuma-storage-cluster1-server2.example.com:

  ip: 0.0.0.0

  shard: 1

  replica: 2

  keeper: 0

  kuma-storage-cluster1-server3.example.com:

  ip: 0.0.0.0

  shard: 2

  replica: 1

  keeper: 0

  kuma-storage-cluster1-server4.example.com:

  ip: 0.0.0.0

  shard: 2

  replica: 2

  keeper: 0

  kuma-storage-cluster1-server5.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 1

  kuma-storage-cluster1-server6.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 2

  kuma-storage-cluster1-server7.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 3

  kuma_k0s:

  vars:

  ansible_connection: ssh

  ansible_user: root

  children:

  kuma_lb:

  hosts:

  kuma_lb.example.com:

  kuma_managed_lb: true

  kuma_control_plane_master:

  hosts:

  kuma_cpm.example.com:

  ansible_host: 10.0.1.10

  kuma_control_plane_master_worker:

  kuma_control_plane:

  hosts:

  kuma_cp1.example.com:

  ansible_host: 10.0.1.11

  kuma_cp2.example.com:

  ansible_host: 10.0.1.12

  kuma_control_plane_worker:

  kuma_worker:

  hosts:

  kuma-core-1.example.com:

  ansible_host: 10.0.1.13

  extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

  kuma_worker2.example.com:

  ansible_host: 10.0.1.14

  extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

  Вы можете установить Ядро KUMA в кластере Kubernetes для обеспечения отказоустойчивости. Используйте файл инвентаря k0s.inventory.yml для описания конфигурации.

Требования к установке программы

Общие требования к установке программы

Перед развертыванием программы убедитесь, что выполнены следующие условия:

• Серверы, предназначенные для установки компонентов, соответствуют аппаратным и программным требованиям.
• Порты, которые KUMA займет при установке, доступны.
• Адресация компонентов KUMA осуществляется по полному доменному имени FQDN хоста. Перед установкой программы убедитесь, что в поле Static hostname возвращается правильное имя FQDN хоста. Для этого выполните следующую команду:

  hostnamectl status

• Имя сервера, на котором запускается установщик, отличается от localhost или localhost.<домен>.
• Настроена синхронизация времени на всех серверах с сервисами KUMA по протоколу Network Time Protocol (NTP).

Требования к установке на операционных системах Oracle Linux, Astra Linux и Ubuntu 22.04 LTS

Обновление с операционной системы Oracle Linux 8.x до Oracle Linux 9.x

Чтобы выполнить обновление с Oracle Linux 8.x до Oracle Linux 9.x:

1. Отключите сервисы KUMA на хостах, где сервисы установлены, с помощью следующих команд:
   • sudo systemctl disable kuma-collector-<идентификатор сервиса>.service
   • sudo systemctl disable kuma-correlator-<идентификатор сервиса>.service
   • sudo systemctl disable kuma-storage-<идентификатор сервиса>.service
   • sudo systemctl disable kuma-grafana.service
   • sudo systemctl disable kuma-mongodb.service
   • sudo systemctl disable kuma-victoria-metrics.service
   • sudo systemctl disable kuma-vmalert.service
   • sudo systemctl disable kuma-core.service
2. Выполните обновление ОС на каждом хосте.
3. После обновления установите пакет compat-openssl11 на хосте, где будет разворачиваться Ядро KUMA вне кластера, с помощью следующей команды:

   yum install compat-openssl11

4. Включите сервисы на хостах, где сервисы установлены, с помощью следующих команд:
   • sudo systemctl enable kuma-core.service
   • sudo systemctl enable kuma-storage-<идентификатор сервиса>.service
   • sudo systemctl enable kuma-collector-<идентификатор сервиса>.service
   • sudo systemctl enable kuma-correlator-<идентификатор сервиса>.service
   • sudo systemctl enable kuma-grafana.service
   • sudo systemctl enable kuma-mongodb.service
   • sudo systemctl enable kuma-victoria-metrics.service
   • sudo systemctl enable kuma-vmalert.service
5. Перезагрузите хосты.

В результате обновление выполнено.

Порты, используемые KUMA при установке

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

Перед установкой Ядра на устройстве убедитесь, что следующие порты свободны:

• 9090: используется Victoria Metrics.
• 8880: используется VMalert.
• 27017: используется MongoDB.

В таблице ниже показаны значения сетевых портов по умолчанию. Порты открываются установщиком автоматически при установке KUMA

Сетевые порты, используемые для взаимодействия компонентов KUMA

Порты, используемые предустановленными ресурсами из состава OOTB

Порты открываются установщиком автоматически при установке KUMA.

Порты, используемые предустановленными ресурсами из состава OOTB:

• 7230/tcp
• 7231/tcp
• 7232/tcp
• 7233/tcp
• 7234/tcp
• 7235/tcp
• 5140/tcp
• 5140/udp
• 5141/tcp
• 5144/udp

Трафик Ядра KUMA в отказоустойчивой конфигурации

В таблице "Трафик Ядра KUMA в отказоустойчивой конфигурации" указаны инициатор соединения (источник) и назначение. Номер порта на инициаторе может быть динамическим. Обратный трафик в рамках установленного соединения не должен блокироваться.

Трафик Ядра KUMA в отказоустойчивой конфигурации

Синхронизация времени на серверах

Чтобы настроить синхронизацию времени на серверах:

1. Установите chrony с помощью следующей команды:

   sudo apt install chrony

2. Настройте синхронизацию системного времени с NTP-сервером:
   1. Убедитесь, что виртуальная машина имеет доступ в интернет.

      Если доступ есть, вы можете перейти к шагу b.

      Если доступ отсутствует, отредактируйте файл /etc/chrony.conf, заменив значение 2.pool.ntp.org на имя или IP-адрес внутреннего NTP-сервера вашей организации.

   2. Запустите сервис синхронизации системного времени, выполнив следующую команду:

      sudo systemctl enable --now chronyd

   3. Через несколько секунд выполните следующую команду:

      sudo timedatectl | grep 'System clock synchronized'

      Если системное время синхронизировано верно, вывод будет содержать строку System clock synchronized: yes.

Синхронизация настроена.

О файле инвентаря

Установка, обновление и удаление компонентов KUMA производится из папки с распакованным установщиком kuma-ansible-installer с помощью инструмента Ansible и созданного вами файла инвентаря. Вы можете указать значения параметров конфигурации KUMA в файле инвентаря, а установщик использует эти значения при развертывании, обновлении и удалении программы. Файл инвентаря имеет формат YAML.

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

• single.inventory.yml.template – используется для установки KUMA на одном сервере. Содержит минимальный набор параметров, оптимизированный для установки на одном устройстве, без использования кластера Kubernetes.
• distributed.inventory.yml.template – используется для первоначальной распределенной установки KUMA без использования кластера Kubernetes, расширения установки "все в одном" до распределенной и для обновления KUMA.
• expand.inventory.yml.template – используется в ряде сценариев изменения конфигурации: для добавления серверов коллекторов и серверов корреляторов, для расширения существующего кластера хранения и добавления нового кластера хранения. Если вы используете этот файл инвентаря для изменения конфигурации, установщик не останавливает сервисы во всей инфраструктуре. Установщик может останавливать только те сервисы, которые размещены на хостах, перечисленных в файле инвентаря expand.inventory.yml, если вы повторно используете файл инвентаря.
• k0s.inventory.yml.template – используется для установки или переноса KUMA в кластер Kubernetes.

Мы рекомендуем сохранить файл инвентаря, который вы использовали для установки программы. С его помощью вы можете дополнить систему компонентами или удалить KUMA.

Параметры конфигурации KUMA в файле инвентаря

Файл инвентаря может включать следующие блоки:

• all
• kuma
• kuma_k0s

Для каждого хоста должен быть указан FQDN в формате <имя хоста>.<домен> или IP-адрес в формате ipv4 или ipv6.

Блок all

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

Пример переопределения переменных в файле инвентаря

В следующей таблице приведен список возможных переменных в разделе vars и их описание.

Список возможных переменных в разделе vars

Блок kuma

В этом блоке перечисляются параметры компонентов KUMA, развернутых вне кластера Kubernetes.

В блоке доступны следующие разделы:

• vars – в этом разделе можно указать переменные, которые распространяются на все хосты, указанные в блоке kuma.
• children – в этом разделе можно перечислить группы параметров компонентов:
  • kuma_core – параметры Ядра KUMA. Может содержать только один хост.
  • kuma_collector – параметры коллекторов KUMA. Может содержать несколько хостов.
  • kuma_correlator – параметры корреляторов KUMA. Может содержать несколько хостов.
  • kuma_storage – параметры узлов хранилища KUMA. Может содержать несколько хостов.

Блок kuma_k0s

В этом блоке задаются параметры кластера Kubernetes, использование которого обеспечивает отказоустойчивость KUMA. Этот блок есть только в файле инвентаря на основе шаблона k0s.inventory.yml.template.

Для каждого хоста в этом блоке должен быть указан его уникальный FQDN и IP-адрес в параметре ansible_host, кроме хоста в разделе kuma_lb – для него должен быть указан FQDN. Хосты в группах не должны повторяться.

Для демонстрационной установки допустимо совместить контроллер с рабочим узлом. Такая конфигурация не обеспечивает отказоустойчивости Ядра и служит для демонстрации возможностей или проверки программной среды.

Минимальная конфигурация для обеспечения отказоустойчивости - 3 выделенных контроллера, 2 рабочих узла и 1 балансировщик нагрузки. Для промышленной эксплуатации рекомендуется использовать выделенные рабочие узлы и контроллеры. Если контроллер кластера находится под рабочей нагрузкой и под (англ. pod) с Ядром KUMA размещается на контроллере, отключение контроллера приведет к полной потере доступа к Ядру.

В блоке доступны следующие разделы:

• vars – в этом разделе можно указать переменные, которые распространяются на все хосты, указанные в блоке kuma.
• сhildren – в этом разделе задаются параметры кластера Kubernetes, использование которого обеспечивает отказоустойчивость KUMA.

В таблице ниже приведен список возможных переменных в разделе vars и их описание.

Список возможных переменных в разделе vars

Установка на одном сервере

Чтобы установить компоненты KUMA на одном сервере, выполните следующие шаги:

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке KUMA.
2. Подготовьте файл инвентаря single.inventory.yml.

   Используйте шаблон файла инвентаря single.yml.template, который входит в поставку, чтобы создать файл инвентаря single.inventory.yml и описать в нем сетевую структуру компонентов программы. С помощью single.inventory.yml установщик развернет KUMA.

3. Установите программу.

   Установите программу и выполните вход в веб-интерфейс, используя учетные данные по умолчанию.

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

Подготовка файла инвентаря single.inventory.yml

Установка, обновление и удаление компонентов KUMA производится из папки с распакованным установщиком с помощью инструмента Ansible и созданного пользователем файла инвентаря в формате YML с перечнем хостов компонентов KUMA и других параметров. Если вы хотите установить все компоненты KUMA на одном сервере, следует указать в файле инвентаря один и тот же хост для всех компонентов.

Чтобы создать файл инвентаря для установки на одном сервере:

1. Скопируйте архив с установщиком kuma-ansible-installer-<номер версии>.tar.gz на сервер и распакуйте его с помощью следующей команды (потребуется около 2 ГБ дискового пространства):

   sudo tar -xpf kuma-ansible-installer-<номер версии>.tar.gz

2. Перейдите в директорию установщика KUMA, выполнив следующую команду:

   cd kuma-ansible-installer

3. Скопируйте шаблон single.inventory.yml.template и создайте файл инвентаря с именем single.inventory.yml:

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

4. Отредактируйте параметры файла инвентаря single.inventory.yml.

   Если вы хотите, чтобы при установке были созданы предустановленные сервисы, присвойте параметру deploy_example_services значение true.

   deploy_example_services: true

   Предустановленные сервисы появятся только при первичной установке KUMA. При обновлении системы с помощью того же файла инвентаря предустановленные сервисы повторно созданы не будут.

5. Замените в файле инвентаря все строки kuma.example.com на имя хоста, на который следует установить компоненты KUMA.

Файл инвентаря создан. С его помощью можно установить KUMA на одном сервере.

Мы рекомендуем сохранить файл инвентаря, который вы использовали для установки программы. С его помощью вы можете дополнить систему компонентами или удалить KUMA.

Пример файла инвентаря для установки на одном сервере

Установка программы на одном сервере

Вы можете установить все компоненты KUMA на одном сервере с помощью инструмента Ansible и файла инвентаря single.inventory.yml.

Чтобы установить KUMA на одном сервере:

1. Скачайте на сервер дистрибутив KUMA kuma-ansible-installer-<номер сборки>.tar.gz и распакуйте его. Архив распаковывается в папку kuma-ansibleinstaller.
2. Войдите в папку с распакованным установщиком.
3. Поместите в папку <папка установщика>/roles/kuma/files/ файл с лицензионным ключом.

   Файл ключа должен иметь название license.key.

   sudo cp <файл ключа>.key <папка установщика>/roles/kuma/files/license.key

4. Запустите установку компонентов с использованием подготовленного файла инвентаря single.inventory.yml с помощью следующей команды:

   sudo ./install.sh single.inventory.yml

5. Примите условия Лицензионного соглашения.

   Если вы не примете условия Лицензионного соглашения, программа не будет установлена.

В результате все компоненты KUMA установлены. По окончании установки войдите в веб-интерфейс KUMA и в строке браузера введите адрес веб-интерфейса KUMA, а затем на странице входа введите учетные данные.

Адрес веб-интерфейса KUMA – https://<FQDN хоста, на котором установлена KUMA>:7220.

Учетные данные для входа по умолчанию:
- логин – admin
- пароль – mustB3Ch@ng3d!

После первого входа измените пароль учетной записи admin

Мы рекомендуем сохранить файл инвентаря, который вы используете для установки программы. С помощью этого файла инвентаря можно будет дополнить систему компонентами или удалить KUMA.

Установку можно расширить до распределенной.

Распределенная установка

Распределенная установка KUMA происходит в несколько этапов:

1. Проверка соблюдения аппаратных и программных требований, а также требований к установке KUMA.
2. Подготовка контрольной машины.

   Контрольная машина используется в процессе установки программы: на ней распаковывается и запускаются файлы установщика.

3. Подготовка целевых машин.

   На целевые машины устанавливаются компоненты программы.

4. Подготовка файла инвентаря distributed.inventory.yml.

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

5. Установка программы.

   Установите программу и выполните вход в веб-интерфейс.

6. Создание сервисов.

   Создайте клиентскую часть сервисов в веб-интерфейсе KUMA и установите серверную часть сервисов на целевых машинах.

   Сервисы KUMA следует устанавливать только после завершения установки KUMA. Мы рекомендуем устанавливать сервисы в такой последовательности: хранилище, коллекторы, корреляторы и агенты.

   При развертывании нескольких сервисов KUMA на одном хосте в процессе установки требуется указать уникальные порты для каждого сервиса с помощью параметров --api.port <порт>.

При необходимости вы можете изменить сертификат веб-консоли KUMA на сертификат своей компании.

Подготовка контрольной машины

Чтобы подготовить контрольную машину для установки KUMA:

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке программы.
2. Сгенерируйте SSH-ключ для аутентификации на SSH-серверах целевых машин, выполнив следующую команду:

   sudo ssh-keygen -f /root/.ssh/id_rsa -N "" -C kuma-ansible-installer

   Если на контрольной машине заблокирован доступ root по SSH, сгенерируйте SSH-ключ для аутентификации на SSH-серверах целевых машин с помощью пользователя из группы sudo:

   Если у пользователя нет прав sudo, добавьте пользователя в группу sudo:

   usermod -aG sudo user

   ssh-keygen -f /home/<имя пользователя из группы sudo>/.ssh/id_rsa -N "" -C kuma-ansible-installer

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

3. Убедитесь, что контрольная машина имеет сетевой доступ ко всем целевым машинам по имени хоста и скопируйте SSH-ключ на каждую целевую машину, выполнив следующую команду:

   sudo ssh-copy-id -i /root/.ssh/id_rsa root@<имя хоста контрольной машины>

   Если на контрольной машине заблокирован доступ root по SSH и вы хотите использовать ключ SSH из домашней директории пользователя из группы sudo, убедитесь, что контрольная машина имеет сетевой доступ ко всем целевым машинам по имени хоста и скопируйте SSH-ключ на каждую целевую машину, выполнив следующую команду:

   ssh-copy-id -i /home/<имя пользователя из группы sudo>/.ssh/id_rsa <имя пользователя из группы sudo>@<имя хоста контрольной машины>

4. Скопируйте архив с установщиком kuma-ansible-installer-<version>.tar.gz на контрольную машину и распакуйте его с помощью следующей команды (потребуется около 2 ГБ дискового пространства):

   sudo tar -xpf kuma-ansible-installer-<номер версии>.tar.gz

Контрольная машина готова для установки KUMA.

Подготовка целевой машины

Чтобы подготовить целевую машину для установки компонентов KUMA:

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке.
2. Установите имя хоста. Мы рекомендуем указывать FQDN. Например: kuma1.example.com.

   Не следует изменять имя хоста KUMA после установки: это приведет к невозможности проверки подлинности сертификатов и нарушит сетевое взаимодействие между компонентами программы.

3. Зарегистрируйте целевую машину в DNS-зоне вашей организации для преобразования имен хостов в IP-адреса.

   Если в вашей организации не используется DNS-сервер, вы можете использовать для преобразования имен файл /etc/hosts. Содержимое файлов можно автоматически создать для каждой целевой машины при установке KUMA.

4. Чтобы получить имя хоста, которое потребуется указать при установке KUMA, выполните следующую команду и запишите результат:

   hostname -f

   Целевая машина должна быть доступна по этому имени для контрольной машины.

Целевая машина готова для установки компонентов KUMA.

Подготовка файла инвентаря distributed.inventory.yml

Чтобы создать файл инвентаря distributed.inventory.yml:

1. Перейдите в директорию установщика KUMA, выполнив следующую команду:

   cd kuma-ansible-installer

2. Скопируйте шаблон distributed.inventory.yml.template и создайте файл инвентаря с именем distributed.inventory.yml:

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

3. Отредактируйте параметры файла инвентаря distributed.inventory.yml.

Мы рекомендуем сохранить файл инвентаря, который вы использовали для установки программы. С его помощью вы можете дополнить систему компонентами или удалить KUMA.

Пример файла инвентаря для Распределенной схемы установки

Установка программы в распределенной конфигурации

Установка KUMA производится помощью инструмента Ansible и YML-файла инвентаря. Установка производится с контрольной машины, при этом все компоненты KUMA устанавливаются на целевых машинах.

Чтобы установить KUMA:

1. На контрольной машине войдите в папку с распакованным установщиком.

   cd kuma-ansible-installer

2. Поместите в папку <папка установщика>/roles/kuma/files/ файл с лицензионным ключом.

   Файл ключа должен иметь название license.key.

3. Запустите установщик, находясь в папке с распакованным установщиком:

   sudo ./install.sh distributed.inventory.yml

4. Примите условия Лицензионного соглашения.

   Если вы не примете условия Лицензионного соглашения, программа не будет установлена.

Компоненты KUMA будут установлены. На экране будет отображен URL веб-интерфейса KUMA и указано имя пользователя и пароль, которые необходимо использовать для доступа к веб-интерфейсу.

По умолчанию адрес веб-интерфейса KUMA – https://<FQDN или IP-адрес компонента core>:7220.

Учетные данные для входа по умолчанию (после первого входа требуется изменить пароль учетной записи admin):
- логин – admin
- пароль – mustB3Ch@ng3d!

Мы рекомендуем сохранить файл инвентаря, который вы использовали для установки программы. С его помощью вы можете дополнить систему компонентами или удалить KUMA.

Изменение самоподписанного сертификата веб-консоли

Перед изменением сертификата KUMA сделайте резервную копию действующего сертификата и ключа с именами external.cert.old и external.key.old.

После установки Ядра KUMA установщик создает следующие сертификаты в папке /opt/kaspersky/kuma/core/certificates:

• Самоподписанный корневой сертификат ca.cert с ключом ca.key.

  Подписывает все другие сертификаты, которые используются для внутренней связи между компонентами KUMA.

• Сертификат internal.cert, подписанный корневым сертификатом, и ключ internal.key сервера Ядра.

  Используется для внутренней связи между компонентами KUMA.

• Сертификат веб-консоли KUMA external.cert и ключ external.key.

  Используется в веб-консоли KUMA и для запросов REST API.

  Вы можете использовать сертификат и ключ своей компании вместо самоподписанного сертификата веб-консоли. Например, если вы хотите заменить сертификат веб-консоли с самоподписанного CA Core на сертификат, выпущенный корпоративным CA, необходимо предоставить external.cert и незашифрованный external.key в формате PEM.

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

Чтобы заменить сертификат веб-консоли KUMA на сертификат external:

1. Переключитесь на работу под пользователем с правами root:

   sudo -i

2. Перейдите в директорию с сертификатами:

   cd /opt/kaspersky/kuma/core/certificates

3. Сделайте резервную копию действующего сертификата и ключа:

   mv external.cert external.cert.old && mv external.key external.key.old

4. В OpenSSL конвертируйте файл PFX в сертификат и зашифрованный ключ в формате PEM:

   openssl pkcs12 -in kumaWebIssuedByCorporateCA.pfx -nokeys -out external.cert

   openssl pkcs12 -in kumaWebIssuedByCorporateCA.pfx -nocerts -nodes -out external.key

   При выполнении команды потребуется указать пароль от ключа PFX (Enter Import Password).

   В результате получен сертификат external.cert и ключ external.key в формате PEM.

5. Поместите полученные файлы сертификата external.cert и ключа external.key в директорию /opt/kaspersky/kuma/core/certificates.
6. Смените владельца файлов ключа:

   chown kuma:kuma external.cert external.key

7. Перезапустите KUMA:

   systemctl restart kuma-core

8. Обновите страницу или перезапустите браузер, с помощью которого вы работаете в веб-интерфейсе KUMA.

Сертификат и ключ вашей компании заменены.

Распределенная установка в отказоустойчивой конфигурации

Вы можете обеспечить отказоустойчивость KUMA путем развертывания Ядра KUMA в кластере Kubernetes, а также использования внешнего балансировщика TCP-трафика.

Для установки KUMA в отказоустойчивом исполнении используется установщик kuma-ansible-installer-ha-<номер сборки>.tar.gz и подготовленный вами файл инвентаря k0s.inventory.yml, в котором вы определите конфигурацию кластера. При новой установке в отказоустойчивой конфигурации всегда импортируются ресурсы OOTB. Вы можете выполнить установку с развертыванием демонстрационных сервисов. Для этого нужно в файле инвентаря указать параметр deploy_example_services: true.

Поместить Ядро KUMA в кластер Kubernetes можно следующими способами:

• Установить KUMA в кластере Kubernetes с нуля.
• Перенести Ядро существующей установки KUMA в кластер Kubernetes.

Минимальная конфигурация

В Kubernetes существует 2 роли узлов:

• контроллеры (control-plane) – узлы с этой ролью управляют кластером, хранят метаданные и распределяют рабочую нагрузку.
• рабочие (worker) – узлы с этой ролью несут полезную рабочую нагрузку, то есть размещают процессы KUMA.

Для выполнения установки KUMA в отказоустойчивой конфигурации вам понадобится:

• 3 выделенных контроллера;
• 2 рабочих узла;
• 1 TCP балансировщик.

Не следует использовать балансировщик в качестве контрольной машины для запуска установщика KUMA.

Для эффективной работы Ядра KUMA в Kubernetes необходимо выделить 3 обособленных узла с единственной ролью контроллера. Это позволит обеспечить отказоустойчивость самого кластера Kubernetes и гарантировать, что рабочая нагрузка - процессы KUMA и другие процессы - не повлияет на задачи, связанные с управлением кластером Kubernetes. В случае использования средств виртуализации следует убедиться, что узлы размещены на разных физических серверах и эти физические серверы не выполняют роль рабочих узлов.

В случае демонстрационной установки KUMA допустимо совмещать роли контроллера и рабочего узла. Однако при расширении установки до распределенной необходимо переустановить кластер Kubernetes целиком, выделив 3 отдельных узла с ролью контроллера и как минимум 2 узла с ролью рабочего узла. Обновление KUMA до следующих версий недоступно при наличии узлов, совмещающих роли контроллера и рабочего узла.

Дополнительные требования при развертывании Ядра в Kubernetes

Если вы планируете защитить сетевую инфраструктуру KUMA с помощью программы Kaspersky Endpoint Security for Linux, необходимо сначала установить KUMA в кластере Kubernetes и только потом разворачивать Kaspersky Endpoint Security for Linux.

При установке KUMA в отказоустойчивом варианте, должны выполняться следующие требования:

• Общие требования к установке программы.
• На хостах, которые планируются под узлы кластера Kubernetes, не используются IP-адреса из следующих блоков Kubernetes
  • serviceCIDR: 10.96.0.0/12
  • podCIDR: 10.244.0.0/16

  Также для адресов этих блоков исключен трафик на прокси-серверы.

• Установлен и настроен балансировщик нагрузки nginx (подробнее о настройке nginx). Для установки можно воспользоваться, например,следующей командой:

  sudo yum install nginx

  Если вы хотите, чтобы nginx был настроен автоматически в процессе установки KUMA, установите nginx и откройте к нему доступ по SSH так же, как для хостов кластера Kubernetes.

  Пример автоматически созданной конфигурации nginx

  Установщик создает файл конфигурации /etc/nginx/kuma_nginx_lb.conf, пример содержимого которого приведен ниже. Разделы upstream формируются динамически и содержат IP-адреса контроллеров кластера Kubernetes (в примере – 10.0.0.2-4 в разделах upstream kubeAPI_backend, upstream konnectivity_backend, controllerJoinAPI_backend) и IP-адреса рабочих узлов (в примере 10.0.1.2-3), для которых в файле инвентаря в переменной extra_args содержится значение "kaspersky.com/kuma-ingress=true".

  В конец файла /etc/nginx/nginx.conf дописывается строка "include /etc/nginx/kuma_nginx_lb.conf;", позволяющая применить сформированный файл конфигурации. При большом количестве активных сервисов и пользователей может понадобиться увеличить лимит открытых файлов в параметрах nginx.conf.

  Пример файла конфигурации:

  # Ansible managed

  #

  # LB KUMA cluster

  #

  stream {

      server {

          listen          6443;

          proxy_pass      kubeAPI_backend;

      }

      server {

          listen          8132;

          proxy_pass      konnectivity_backend;

      }

      server {

          listen          9443;

          proxy_pass      controllerJoinAPI_backend;

      }

      server {

          listen          7209;

          proxy_pass      kuma-core-hierarchy_backend;

          proxy_timeout   86400s;

      }

      server {

          listen          7210;

          proxy_pass      kuma-core-services_backend;

          proxy_timeout   86400s;

      }

      server {

          listen          7220;

          proxy_pass      kuma-core-ui_backend;

          proxy_timeout   86400s;

      }

      server {

          listen          7222;

          proxy_pass      kuma-core-cybertrace_backend;

          proxy_timeout   86400s;

      }

      server {

          listen          7223;

          proxy_pass      kuma-core-rest_backend;

          proxy_timeout   86400s;

      }

      upstream kubeAPI_backend {

          server 10.0.0.2:6443;

          server 10.0.0.3:6443;

          server 10.0.0.4:6443;

      }

      upstream konnectivity_backend {

          server 10.0.0.2:8132;

          server 10.0.0.3:8132;

          server 10.0.0.4:8132;

      }

      upstream controllerJoinAPI_backend {

          server 10.0.0.2:9443;

          server 10.0.0.3:9443;

          server 10.0.0.4:9443;

      }

      upstream kuma-core-hierarchy_backend {

          server 10.0.1.2:7209;

          server 10.0.1.3:7209;

      }

      upstream kuma-core-services_backend {

          server 10.0.1.2:7210;

          server 10.0.1.3:7210;

      }

      upstream kuma-core-ui_backend {

          server 10.0.1.2:7220;

          server 10.0.1.3:7220;

      }

      upstream kuma-core-cybertrace_backend {

          server 10.0.1.2:7222;

          server 10.0.1.3:7222;

      }

      upstream kuma-core-rest_backend {

          server 10.0.1.2:7223;

          server 10.0.1.3:7223;

  }

   worker_rlimit_nofile 1000000;

  events {

  worker_connections 20000;

  }

  # worker_rlimit_nofile – ограничение на максимальное число открытых файлов (RLIMIT_NOFILE) для рабочих процессов. Используется для увеличения ограничения без перезапуска главного процесса.

  # worker_connections – максимальное число соединений, которые одновременно может открыть рабочий процесс.

• На сервере балансировщика добавлен ключ доступа с устройства, с которого осуществляется установка KUMA.
• На сервере балансировщика в операционной системе НЕ включен модуль SELinux.
• На хостах установлены пакеты tar, systemctl, setfacl.

При установке KUMA автоматически проверяется соответствие хостов указанным ниже аппаратным требованиям. Если эти условия не выполняются, установка прерывается.

Проверку этих условий при установке для демонстрации можно отключить, указав в файле инвентаря переменную low_resources: true.

• Количество ядер CPU (потоков) – 12 или больше.
• ОЗУ – 22528 МБ или больше.
• Объем свободного пространства на диске в разделе /opt/ – 1000 ГБ или больше.
• Если производится первичная установка, то в /var/lib/ должно быть не менее 32GB свободного места. Если установка кластера на данный узел ранее уже проводилась, то размер требуемого свободного пространства уменьшается на размер директории /var/lib/k0s.

Дополнительные требования при установке на операционной системе Astra Linux Special Edition

• Установка KUMA в отказоустойчивом варианте поддерживается на операционной системе Astra Linux Special Edition РУСБ.10015-01 (2022-1011SE17MD, оперативное обновление 1.7.2.UU.1). Требуется версия ядра 5.15.0.33 или выше.
• На машинах, предназначенных для развертывания кластера Kubernetes, установлены следующие пакеты:
  • open-iscsi
  • wireguard
  • wireguard-tools

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

  sudo apt install open-iscsi wireguard wireguard-tools

Дополнительные требования при установке на операционной системе Oracle Linux

На машинах, предназначенных для развертывания кластера Kubernetes, установлены следующие пакеты:

• iscsi-initiator-utils
• wireguard-tools

Перед установкой пакетов необходимо добавить репозиторий EPEL в качестве источника:

• sudo yum install oracle-epel-release-el8 - для Oracle Linux 8.
• sudo yum install oracle-epel-release-el9 - для Oracle Linux 9.

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

sudo yum install iscsi-initiator-utils wireguard-tools

Установка KUMA в кластере Kubernetes с нуля

Распределенная установка KUMA происходит в несколько этапов:

1. Проверка соблюдения аппаратных и программных требований, а также требований к установке KUMA.
2. Подготовка контрольной машины.

   Контрольная машина используется в процессе установки программы: на ней распаковывается и запускаются файлы установщика.

3. Подготовка целевых машин.

   На целевые машины устанавливаются компоненты программы.

4. Подготовка файла инвентаря k0s.inventory.yml.

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

5. Установка программы.

   Установите программу и войдите в веб-интерфейс.

6. Создание сервисов.

   Создайте клиентскую часть сервисов в веб-интерфейсе KUMA и установите серверную часть сервисов на целевых машинах.

   Сервисы KUMA следует устанавливать только после завершения установки KUMA. Мы рекомендуем устанавливать сервисы в такой последовательности: хранилище, коллекторы, корреляторы и агенты.

   При развертывании нескольких сервисов KUMA на одном хосте в процессе установки требуется указать уникальные порты для каждого сервиса с помощью параметров --api.port <порт>.

При необходимости вы можете изменить сертификат веб-консоли KUMA на сертификат своей компании.

Подготовка контрольной машины

Чтобы подготовить контрольную машину для установки KUMA:

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке программы.
2. Сгенерируйте SSH-ключ для аутентификации на SSH-серверах целевых машин, выполнив следующую команду:

   sudo ssh-keygen -f /root/.ssh/id_rsa -N "" -C kuma-ansible-installer

   Если на контрольной машине заблокирован доступ root по SSH, сгенерируйте SSH-ключ для аутентификации на SSH-серверах целевых машин с помощью пользователя из группы sudo:

   Если у пользователя нет прав sudo, добавьте пользователя в группу sudo:

   usermod -aG sudo user

   ssh-keygen -f /home/<имя пользователя из группы sudo>/.ssh/id_rsa -N "" -C kuma-ansible-installer

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

3. Убедитесь, что контрольная машина имеет сетевой доступ ко всем целевым машинам по имени хоста и скопируйте SSH-ключ на каждую целевую машину, выполнив следующую команду:

   sudo ssh-copy-id -i /root/.ssh/id_rsa root@<имя хоста контрольной машины>

   Если на контрольной машине заблокирован доступ root по SSH и вы хотите использовать ключ SSH из домашней директории пользователя из группы sudo, убедитесь, что контрольная машина имеет сетевой доступ ко всем целевым машинам по имени хоста и скопируйте SSH-ключ на каждую целевую машину, выполнив следующую команду:

   ssh-copy-id -i /home/<имя пользователя из группы sudo>/.ssh/id_rsa <имя пользователя из группы sudo>@<имя хоста контрольной машины>

4. Скопируйте архив с установщиком kuma-ansible-installer-ha-<номер версии>.tar.gz на контрольную машину и распакуйте его с помощью следующей команды:

   sudo tar -xpf kuma-ansible-installer-ha-<номер версии>.tar.gz

Контрольная машина готова для установки KUMA.

Подготовка целевой машины

Чтобы подготовить целевую машину для установки компонентов KUMA:

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке.
2. Установите имя хоста. Мы рекомендуем указывать FQDN. Например: kuma1.example.com.

   Не следует изменять имя хоста KUMA после установки: это приведет к невозможности проверки подлинности сертификатов и нарушит сетевое взаимодействие между компонентами программы.

3. Зарегистрируйте целевую машину в DNS-зоне вашей организации для преобразования имен хостов в IP-адреса.

   Вариант с использованием файла /etc/hosts не применим для развертывания Ядра в Kubernetes.

4. Чтобы получить имя хоста, которое потребуется указать при установке KUMA, выполните следующую команду и запишите результат:

   hostname -f

   Целевая машина должна быть доступна по этому имени для контрольной машины.

Целевая машина готова для установки компонентов KUMA.

Подготовка файла инвентаря k0s.inventory.yml

Чтобы создать файл инвентаря k0s.inventory.yml:

1. Перейдите в директорию установщика KUMA, выполнив следующую команду:

   cd kuma-ansible-installer-ha

2. Скопируйте шаблон k0s.inventory.yml.template и создайте файл инвентаря с именем k0s.inventory.yml:

   cp k0s.inventory.yml.template k0s.inventory.yml

3. Отредактируйте параметры файла инвентаря k0s.inventory.yml.

   Пример файла инвентаря для демонстрационной установки с Ядром в Kubernetes

   all:

   vars:

   ansible_connection: ssh

   ansible_user: root

   deploy_to_k8s: true

   need_transfer: false

   generate_etc_hosts: false

   airgap: true

   deploy_example_services: true

   kuma:

   children:

   kuma_core:

   hosts:

   kuma.example.com:

   mongo_log_archives_number: 14

   mongo_log_frequency_rotation: daily

   mongo_log_file_size: 1G

   kuma_collector:

   hosts:

   kuma.example.com:

   kuma_correlator:

   hosts:

   kuma.example.com:

   kuma_storage:

   hosts:

   kuma.example.com:

   shard: 1

   replica: 1

   keeper: 1

   kuma_k0s:

   children:

   kuma_control_plane_master_worker:

   hosts:

   kuma-cpw.example.com:

   ansible_host: 10.0.2.11

   extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

   Для демонстрационной установки следует указать deploy_example_services: true - KUMA развернет демонстрационные сервисы на указанных хостах и назначит роль шарда, реплики и кипера указанному хосту, настраивать эти роли для демонстрационной установки в веб-интерфейсе KUMA не нужно.

   Пример файла инвентаря для распределенной установки в отказоустойчивой конфигурации с 3 контроллерами, 2 рабочими узлами и 1 балансировщиком

   all:

   vars:

   ansible_connection: ssh

   ansible_user: root

   deploy_to_k8s: true

   need_transfer: false

   generate_etc_hosts: false

   airgap: true

   deploy_example_services: false

   kuma:

   children:

   kuma_core:

   hosts:

   kuma-core.example.com:

   mongo_log_archives_number: 14

   mongo_log_frequency_rotation: daily

   mongo_log_file_size: 1G

   kuma_collector:

   hosts:

   kuma-collector.example.com:

   kuma_correlator:

   hosts:

   kuma-correlator.example.com:

   kuma_storage:

   hosts:

   kuma-storage-cluster1.server1.example.com

   kuma-storage-cluster1.server2.example.com

   kuma-storage-cluster1.server3.example.com

   kuma-storage-cluster1.server4.example.com

   kuma-storage-cluster1.server5.example.com

   kuma-storage-cluster1.server6.example.com

   kuma-storage-cluster1.server7.example.com

   kuma_k0s:

   children:

   kuma_lb:

   hosts:

   kuma-lb.example.com:

   kuma_managed_lb: true

   kuma_control_plane_master:

   hosts:

   kuma_cpm.example.com:

   ansible_host: 10.0.1.10

   kuma_control_plane_master_worker:

   kuma_control_plane:

   hosts:

   kuma_cp2.example.com:

   ansible_host: 10.0.1.11

   kuma_cp3.example.com:

   ansible_host: 10.0.1.12

   kuma_control_plane_worker:

   kuma_worker:

   hosts:

   kuma-w1.example.com:

   ansible_host: 10.0.2.11

   extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

   kuma-w2.example.com:

   ansible_host: 10.0.2.12

   extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

   Для такой конфигурации следует указать параметры need_transfer: false, airgap: true, deploy_example_services: false, в разделе kuma_storage перечислить серверы для кластера хранения. Роли шарда, реплики и кипера вы сможете назначить указанным в инвентаре серверам в веб-интерфейсе KUMA после завершения установки.

   Пример файла инвентаря для переноса Ядра в кластер Kubernetes из распределенной установки для обеспечения отказоустойчивости

   all:

   vars:

   ansible_connection: ssh

   ansible_user: root

   deploy_to_k8s: true

   need_transfer: true

   generate_etc_hosts: false

   airgap: true

   deploy_example_services: false

   kuma:

   children:

   kuma_core:

   hosts:

   kuma-core.example.com:

   mongo_log_archives_number: 14

   mongo_log_frequency_rotation: daily

   mongo_log_file_size: 1G

   kuma_collector:

   hosts:

   kuma-collector.example.com:

   kuma_correlator:

   hosts:

   kuma-correlator.example.com:

   kuma_storage:

   hosts:

   kuma-storage-cluster1.server1.example.com

   kuma-storage-cluster1.server2.example.com

   kuma-storage-cluster1.server3.example.com

   kuma-storage-cluster1.server4.example.com

   kuma-storage-cluster1.server5.example.com

   kuma-storage-cluster1.server6.example.com

   kuma-storage-cluster1.server7.example.com

   kuma_k0s:

   children:

   kuma_lb:

   hosts:

   kuma-lb.example.com:

   kuma_managed_lb: true

   kuma_control_plane_master:

   hosts:

   kuma_cpm.example.com:

   ansible_host: 10.0.1.10

   kuma_control_plane_master_worker:

   kuma_control_plane:

   hosts:

   kuma_cp2.example.com:

   ansible_host: 10.0.1.11

   kuma_cp3.example.com:

   ansible_host: 10.0.1.12

   kuma_control_plane_worker:

   kuma_worker:

   hosts:

   kuma-w1.example.com:

   ansible_host: 10.0.2.11

   extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

   kuma-w2.example.com:

   ansible_host: 10.0.2.12

   extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

   В файле инвентаря k0s.inventory.yml в разделах kuma_core, kuma_ collector, kuma_correlator, kuma_storage укажите те же хосты, которые использовались в файле distributed.inventory.yml при обновлении KUMA с версии 2.1.3 до версии 3.0.3 или при новой установке программы. В файле инвентаря k0s.inventory.yml необходимо указать параметры deploy_to_k8s: true, need_transfer:true, airgap: true, deploy_example_services: false.

Мы рекомендуем сохранить файл инвентаря, который вы использовали для установки программы. С его помощью вы можете дополнить систему компонентами или удалить KUMA.

Установка программы в отказоустойчивой конфигурации

Установка KUMA производится помощью инструмента Ansible и файла инвентаря k0s.inventory.yml. Установка производится с контрольной машины, при этом все компоненты KUMA устанавливаются на целевых машинах.

Чтобы установить KUMA:

1. На контрольной машине войдите в папку с распакованным установщиком.

   cd kuma-ansible-installer-ha

2. Поместите в папку <папка установщика>/roles/kuma/files/ файл с лицензионным ключом.

   Файл ключа должен иметь название license.key.

3. Запустите установщик, находясь в папке с распакованным установщиком:

   sudo ./install.sh k0s.inventory.yml

4. Примите условия Лицензионного соглашения.

   Если вы не примете условия Лицензионного соглашения, программа не будет установлена.

Компоненты KUMA будут установлены. На экране будет отображен URL веб-интерфейса KUMA и указано имя пользователя и пароль, которые необходимо использовать для доступа к веб-интерфейсу.

По умолчанию адрес веб-интерфейса KUMA – https://<FQDN или IP-адрес компонента core>:7220.

Учетные данные для входа по умолчанию (после первого входа требуется изменить пароль учетной записи admin):
- логин – admin
- пароль – mustB3Ch@ng3d!

Мы рекомендуем сохранить файл инвентаря, который вы использовали для установки программы. С его помощью вы можете дополнить систему компонентами или удалить KUMA.

Перенос Ядра KUMA в новый кластер Kubernetes

Чтобы перенести Ядро KUMA в новый кластер Kubernetes, выполните следующие шаги:

1. Подготовьте файл инвентаря k0s.inventory.yml.

   В файле инвентаря k0s.inventory.yml в разделах kuma_core, kuma_ collector, kuma_correlator, kuma_storage укажите те же хосты, которые использовались при обновлении KUMA с версии 2.1.3 до версии 3.0.3 или при новой установке программы. В файле инвентаря необходимо присвоить параметрам deploy_to_k8s, need_transfer и airgap значение true. Параметру deploy_example_services необходимо присвоить значение false.

   Пример файла инвентаря с 3 выделенными контроллерами, 2 рабочими узлами и 1 балансировщиком.

2. Выполните шаги распределенной установки с использованием подготовленного файла инвентаря k0s.inventory.yml.

Процесс переноса Ядра KUMA в новый кластер Kubernetes

При запуске установщика с файлом инвентаря производится поиск установленного Ядра KUMA на всех хостах, на которых планируется размещать рабочие узлы кластера. Найденное Ядро будет перенесено с хоста внутрь создаваемого кластера Kubernetes.

Если на рабочих узлах компонент не обнаружен, то производится чистая установка Ядра KUMA в кластер без переноса в него ресурсов. Существующие компоненты требуется пересоздать с новым Ядром вручную в веб-интерфейсе KUMA.

Для коллекторов, корреляторов и хранилищ из файла инвентаря будут заново выпущены сертификаты для связи с Ядром внутри кластера. URL Ядра для компонентов при этом не изменится.

На хосте с Ядром установщик выполняет следующие действия:

• Удаляет с хоста systemd-сервисы: kuma-core, kuma-mongodb, kuma-victoria-metrics, kuma-vmalert, kuma-grafana.
• Удаляет internal сертификат Ядра.
• Удаляет файлы сертификатов всех прочих компонентов и удаляет записи о них из MongoDB.
• Удаляет директории:
  • /opt/kaspersky/kuma/core/bin
  • /opt/kaspersky/kuma/core/certificates
  • /opt/kaspersky/kuma/core/log
  • /opt/kaspersky/kuma/core/logs
  • /opt/kaspersky/kuma/grafana/bin
  • /opt/kaspersky/kuma/mongodb/bin
  • /opt/kaspersky/kuma/mongodb/log
  • /opt/kaspersky/kuma/victoria-metrics/bin
• Переносит данные Ядра и ее зависимостей на сетевой диск внутри кластера Kubernetes.
• На хосте с Ядром переносит директории:
  • /opt/kaspersky/kuma/core → /opt/kaspersky/kuma/core.moved
  • /opt/kaspersky/kuma/grafana → /opt/kaspersky/kuma/grafana.moved
  • /opt/kaspersky/kuma/mongodb → /opt/kaspersky/kuma/mongodb.moved
  • /opt/kaspersky/kuma/victoria-metrics → /opt/kaspersky/kuma/victoria-metrics.moved

После проверки корректности переноса Ядра в кластер данные директории можно удалить.

В случае возникновения проблем с переносом нужно проанализировать в журнале записи задачи переноса core-transfer в пространстве имен kuma на кластере (задача доступна в течение 1 часа после переноса).

При необходимости повторного переноса необходимо привести названия директорий /opt/kaspersky/kuma/*.moved к их исходному виду.

Если на хосте с Ядром использовался файл /etc/hosts со строками, не относящимися к адресам 127.X.X.X, при переносе Ядра в кластер Kubernetes содержимое файла /etc/hosts с хоста с Ядром заносится в ConfigMap coredns. Если переноса Ядра не происходит, в ConfigMap заносится содержимое /etc/hosts с хоста, на котором разворачивается главный контроллер.

Доступность Ядра KUMA при различных сценариях

Доступность Ядра KUMA при различных сценариях:

• Выход из строя или отключение от сети рабочего узла, на котором развернут сервис Ядра KUMA.

  Доступ к веб-интерфейсу KUMA пропадает. Через 6 минут Kubernetes инициирует перенос контейнера с Ядром на работающий узел кластера. После завершения развертывания, которое занимает менее одной минуты, веб-интерфейс KUMA снова доступен по URL, в которых используются FQDN балансировщика. Чтобы определить, на каком из хостов работает Ядро, в терминале одного из контроллеров выполните команду:

  k0s kubectl get pod -n kuma -o wide

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

• Выход из строя или отключение от сети рабочего узла с репликой диска Ядра KUMA, на котором в этот момент не развернут сервис Ядра.

  Доступ к веб-интерфейсу KUMA не пропадает по URL, в которых используется FQDN балансировщика. Сетевое хранилище создает реплику работающего дискового тома Ядра на других работающих узлах. При доступе к KUMA через URL с FQDN работающих узлов перерыва также не возникает.

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

  Рабочие узлы работают в обычном режиме. Перерыва в доступе к KUMA не возникает. Выход из строя контроллеров кластера, при котором кворум не обеспечивается оставшимися в работе контроллерами, ведет к потере управления кластером.

  Соответствие количества используемых машин для обеспечения отказоустойчивости

  Количество контроллеров при установке кластера	Минимальное количество контроллеров, необходимое для работы кластера (кворум)	Возможное количество неработающих контроллеров
  1	1	0
  2	2	0
  3	2	1
  4	3	1
  5	3	2
  6	4	2
  7	4	3
  8	5	3
  9	5	4

• Одновременный выход из строя всех контроллеров кластера Kubernetes.

  Кластером невозможно управлять, из-за чего его работоспособность будет нарушена.

• Одновременная потеря доступности всех рабочих узлов кластера с репликами тома Ядра и подом Ядра.

  Доступ к веб-интерфейсу KUMA пропадает. Если утеряны все реплики, будет потеряна информация.

Управление Kubernetes и доступ к KUMA

При установке KUMA в отказоустойчивом варианте, в директории установщика создается файл artifacts/k0s-kubeconfig.yml, содержащий реквизиты, необходимые для подключения к созданному кластеру Kubernetes. Такой же файл создается на основном контроллере в домашней директории пользователя, заданного в файле инвентаря как ansible_user.

Для обеспечения возможности мониторинга и управления кластером Kubernetes файл k0s-kubeconfig.yml необходимо сохранить в месте, доступном для администраторов кластера. Доступ к файлу следует ограничить.

Управление кластером Kubernetes

Для мониторинга и управления кластером можно использовать программу k0s, устанавливаемую на все узлы кластера при развертывании KUMA. Например, для просмотра нагрузки на рабочие узлы можно использовать команду:

k0s kubectl top nodes

Доступ к Ядру KUMA

Доступ к Ядру KUMA осуществляется по URL https://<FQDN рабочего узла>:<порт рабочего узла>. Доступные порты: 7209, 7210, 7220, 7222, 7223. По умолчанию для подключения к веб-интерфейсу Ядра KUMA используется порт 7220. Доступ может осуществляться через любой рабочий узел, в параметре extra_args которого содержится значение kaspersky.com/kuma-ingress=true.

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

В случае использования внешнего балансировщика нагрузки в конфигурации кластера Kubernetes с обеспечением отказоустойчивости доступ к портам Ядра KUMA осуществляется через FQDN балансировщика.

Часовой пояс в кластере Kubernetes

Внутри кластера Kubernetes всегда используется часовой пояс UTC+0, поэтому при обращении с данными, созданными Ядром KUMA, развернутом в отказоустойчивом варианте, следует учитывать эту разницу во времени:

• В событиях аудита в поле DeviceTimeZone будет указан часовой пояс UTC+0.
• В сформированных отчетах пользователь будет видеть разницу между временем формирования отчета и временем браузера.
• В панели мониторинга пользователь будет видеть разницу между временем в виджете (отображается время браузера пользователя) и временем в выгрузке данных виджета в CSV-файле (отображается время внутри кластера Kubernetes).

Работа с сертификатами веб-консоли KUMA в отказоустойчивой конфигурации

Изменение самоподписанного сертификата веб-консоли

Чтобы заменить самоподписанный сертификат веб-консоли KUMA на корпоративный сертификат:

1. Подключитесь к главному контроллеру кластера по ssh:

   ssh <имя пользователя>@<FQDN главного контроллера>

2. Перейдите в домашний каталог пользователя или создайте новый каталог для дальнейших операций и перейдите в него.
3. Скопируйте действующие сертификат и ключ в качестве резервной копии в текущий каталог на контроллере кластера следующими командами:

   export POD=$(k0s kubectl get pods --namespace kuma -l "app=core" -o jsonpath="{.items[0].metadata.name}")

   sudo k0s kubectl cp --no-preserve -c core kuma/$POD:/opt/kaspersky/kuma/core/certificates/external.cert ./external.cert.old

   sudo k0s kubectl cp --no-preserve -c core kuma/$POD:/opt/kaspersky/kuma/core/certificates/external.key ./external.key.old

4. Подготовьте пользовательские сертификат и ключ для замены.

   В OpenSSL конвертируйте файл PFX в сертификат и зашифрованный ключ в формате PEM:

   sudo openssl pkcs12 -in kumaWebIssuedByCorporateCA.pfx -nokeys -out external.cert

   sudo openssl pkcs12 -in kumaWebIssuedByCorporateCA.pfx -nocerts -nodes -out external.key

   При выполнении команды потребуется указать пароль от ключа PFX (Enter Import Password).

   В результате получен сертификат external.cert и ключ external.key в формате PEM.

5. Поместите полученные файлы сертификата external.cert и ключа external.key в текущий каталог на контроллере кластера и, затем, скопируйте их в файловую систему пода ядра KUMA следующими командами:

   export POD=$(k0s kubectl get pods --namespace kuma -l "app=core" -o jsonpath="{.items[0].metadata.name}")

   sudo k0s kubectl cp --no-preserve ./external.cert kuma/$POD:/opt/kaspersky/kuma/core/certificates/external.cert -c core

   sudo k0s kubectl cp --no-preserve ./external.key kuma/$POD:/opt/kaspersky/kuma/core/certificates/external.key -c core

6. Перезапустите ядро KUMA следующей командой:

   sudo k0s kubectl rollout restart deployment/core-deployment -n kuma

7. Обновите страницу или перезапустите браузер, с помощью которого вы работаете в веб-интерфейсе KUMA.

Замена самоподписанного сертификата веб-консоли на корпоративный сертификат выполнена.

Отмена внесенных изменений

Чтобы отменить внесенные изменения и вернуться к использованию прежнего сертификата и ключа:

1. Перейдите в домашний каталог пользователя на главном контроллере и выполните следующие команды:

   sudo export POD=$(k0s kubectl get pods --namespace kuma -l "app=core" -o jsonpath="{.items[0].metadata.name}")

   sudo k0s kubectl cp --no-preserve ./external.cert.old kuma/$POD:/opt/kaspersky/kuma/core/certificates/external.cert -c core

   sudo k0s kubectl cp --no-preserve ./external.key.old kuma/$POD:/opt/kaspersky/kuma/core/certificates/external.key -c core

2. Перезапустите Ядро KUMA с помощью следующей команды:

   sudo k0s kubectl rollout restart deployment/core-deployment -n kuma

3. Обновите страницу или перезапустите браузер, с помощью которого вы работаете в веб-интерфейсе KUMA.

Изменения отменены, используется прежний сертификат и ключ веб-консоли.

Резервное копирование KUMA

KUMA позволяет выполнять резервное копирование базы данных Ядра KUMA и сертификатов. Функция резервного копирования предназначена для восстановления KUMA – для переноса или копирования ресурсов следует использовать функции экспорта и импорта ресурсов.

Резервное копирование можно осуществить следующими способами:

• с помощью REST API;
• с помощью исполняемого файла /opt/kaspersky/kuma/kuma.

  Метод резервного копирования KUMA с помощью исполняемого файла kuma будет недоступен в версиях KUMA выше 2.1.

Особенности резервного копирования KUMA

• Восстановление данных из резервной копии поддерживается только при сохранении версии KUMA.
• Резервное копирование коллекторов не требуется, за исключением коллекторов с SQL-подключением. При восстановлении таких коллекторов следует вернуть к исходному начальное значение идентификатора.
• Если после восстановления KUMA не включается, рекомендуется обнулить базу данных kuma в MongoDB.

  Как обнулить базу данных в MongoDB

  Если после восстановления данных не включается Ядро KUMA, необходимо повторить восстановление, обнулив при этом базу данных kuma в MongoDB.

  Чтобы восстановить данные KUMA с обнулением базы данных MongoDB:

  1. Войдите в ОС сервера, на котором установлено Ядро KUMA.
  2. Остановите Ядро KUMA, выполнив следующую команду:

     sudo systemctl stop kuma-core

  3. Войдите в MongoDB, выполнив следующие команды:
     1. cd /opt/kaspersky/kuma/mongodb/bin/
     2. ./mongo
  4. Обнулите базу данных MongoDB, выполнив следующие команды:
     1. use kuma
     2. db.dropDatabase()
  5. Выйдите из базы данных MongoDB, нажав Ctrl+C.
  6. Восстановите данные из резервной копии, выполнив следующую команду:

     sudo /opt/kaspersky/kuma/kuma tools restore --src <путь к директории с резервной копией> --certificates

     Флаг --certificates не является обязательным и используется для восстановления сертификатов.

  7. Запустите KUMA, выполнив следую команду:

     sudo systemctl start kuma-core

  8. Пересоздайте сервисы, используя восстановленные наборы ресурсов для сервисов.

  Данные восстановлены из резервной копии.

Резервное копирование KUMA с помощью файла kuma

Чтобы выполнить резервное копирование:

1. Войдите в ОС сервера, на котором установлено Ядро KUMA.
2. Выполните следующую команду исполняемого файла kuma:

   sudo /opt/kaspersky/kuma/kuma tools backup --dst <путь к директории для резервной копии> --certificates

Резервная копия создана.

Чтобы восстановить данные из резервной копии:

1. Войдите в ОС сервера, на котором установлено Ядро KUMA.
2. Остановите Ядро KUMA, выполнив следующую команду:

   sudo systemctl stop kuma-core

3. Выполните следующую команду:

   sudo /opt/kaspersky/kuma/kuma tools restore --src <путь к директории с резервной копией> --certificates

4. Запустите KUMA, выполнив следующую команду:

   sudo systemctl start kuma-core

5. В веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы выберите все сервисы и нажмите на кнопку Сбросить сертификат.
6. Установите сервисы заново с теми же портами и идентификаторами.

Данные восстановлены из резервной копии.

Изменение конфигурации KUMA

Доступны следующие изменения конфигурации KUMA.

• Расширение установки "все в одном" до распределенной.

  Чтобы расширить установку "все в одном" до распределенной:

  1. Создайте резервную копию KUMA.
  2. Удалите с сервера предустановленные сервисы коррелятора, коллектора и хранилища.
     1. В веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы выберите сервис и нажмите Копировать идентификатор. На сервере, где были установлены сервисы, выполните команду удаления сервиса:

        sudo /opt/kaspersky/kuma/kuma <collector/correlator/storage> --id <идентификатор сервиса, скопированный из веб-интерфейса KUMA> --uninstall

        Повторите команду удаления для каждого сервиса.

     2. Затем удалите сервисы в веб-интерфейсе KUMA.

     В результате на сервере первоначальной установки останется только Ядро KUMA.

  3. Подготовьте файл инвентаря distributed.inventory.yml и укажите в нем сервер первоначальной установки "все в одном" в группе kuma_core.

     Таким образом Ядро KUMA останется на прежнем сервере, а остальные компоненты вы развернете на других серверах. Укажите серверы для установки компонентов KUMA в файле инвентаря.

     Пример файла инвентаря для расширения установки "все в одном" до распределенной

     all:

     vars:

     deploy_to_k8s: false

     need_transfer: false

     generate_etc_hosts: false

     deploy_example_services: false

     no_firewall_actions: false

     kuma:

     vars:

     ansible_connection: ssh

     ansible_user: root

     children:

     kuma_core:

     hosts:

     kuma-core-1.example.com:

     ip: 0.0.0.0

     mongo_log_archives_number: 14

     mongo_log_frequency_rotation: daily

     mongo_log_file_size: 1G

     kuma_collector:

     hosts:

     kuma-collector-1.example.com:

     ip: 0.0.0.0

     kuma_correlator:

     hosts:

     kuma-correlator-1.example.com:

     ip: 0.0.0.0

     kuma_storage:

     hosts:

     kuma-storage-cluster1-server1.example.com:

     ip: 0.0.0.0

     shard: 1

     replica: 1

     keeper: 0

     kuma-storage-cluster1-server2.example.com:

     ip: 0.0.0.0

     shard: 1

     replica: 2

     keeper: 0

     kuma-storage-cluster1-server3.example.com:

     ip: 0.0.0.0

     shard: 2

     replica: 1

     keeper: 0

     kuma-storage-cluster1-server4.example.com:

     ip: 0.0.0.0

     shard: 2

     replica: 2

     keeper: 0

     kuma-storage-cluster1-server5.example.com:

     ip: 0.0.0.0

     shard: 0

     replica: 0

     keeper: 1

     kuma-storage-cluster1-server6.example.com:

     ip: 0.0.0.0

     shard: 0

     replica: 0

     keeper: 2

     kuma-storage-cluster1-server7.example.com:

     ip: 0.0.0.0

     shard: 0

     replica: 0

     keeper: 3

  4. Создайте и установите сервисы хранилища, коллектора, коррелятора и агента на других машинах.
     1. После того, как вы заполните в файле инвентаря distributed.inventory.yml значения параметров для всех разделов, запустите установщик на контрольной машине.

        sudo ./install.sh distributed.inventory.yml

        В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря distributed.inventory.yml, появятся файлы, необходимые для установки компонентов KUMA: хранилища, коллекторов, корреляторов.

     2. Создайте сервисы хранилища, коллекторов и корреляторов.

  Расширение установки завершено.

• Добавление серверов для коллекторов в распределенную установку.

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

  Чтобы добавить серверы в распределенную установку:

  1. Убедитесь, что на целевых машинах соблюдены аппаратные и программные требования, а также требования к установке.
  2. На контрольной машине перейдите в директорию с распакованным установщиком KUMA, выполнив следующую команду:

     cd kuma-ansible-installer

  3. Скопируйте шаблон expand.inventory.yml.template и создайте файл инвентаря с именем expand.inventory.yml:

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

  4. Отредактируйте параметры файла инвентаря expand.inventory.yml и укажите в нем серверы, которые вы хотите добавить, в разделе kuma_collector.

     Пример файла инвентаря expand.inventory.yml для добавления серверов для коллекторов

     kuma:

     vars:

     ansible_connection: ssh

     ansible_user: root

     children:

     kuma_collector:

     kuma-additional-collector1.example.com

     kuma-additional-collector2.example.com

     kuma_correlator:

     kuma_storage:

     hosts:

  5. На контрольной машине с доступом root из папки с распакованным установщиком выполните следующую команду:

     ./expand.sh expand.inventory.yml

     В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml, появятся файлы для создания и установки коллектора.

  6. Создайте и установите коллекторы. Поскольку коллекторы KUMA состоят из двух частей, клиентской и серверной, вы будете создавать коллекторы в два этапа.
     1. Создание клиентской части коллектора, которая включает в себя набор ресурсов и сервис коллектора.

        Чтобы создать набор ресурсов для коллектора, в веб-интерфейсе KUMA в разделе Ресурсы → Коллекторы нажмите Добавить коллектор и настройте параметры. Подробнее см. Создание коллектора.

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

     2. Создание серверной части коллектора.
     1. На целевой машине выполните скопированную на предыдущем шаге команду. Команда будет выглядеть подобным образом, но все параметры будут автоматически заполнены.

        sudo /opt/kaspersky/kuma/kuma <storage> --core https://<FQDN сервера Ядра KUMA>:<порт, используемый Ядром KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса, скопированный из веб-интерфейса KUMA> --install

        Сервис коллектора установлен на целевой машине. Вы можете проверить статус сервиса в веб-интерфейсе в разделе Ресурсы → Активные сервисы.

     2. Повторите выполнение команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml.
  7. Укажите добавленные серверы в файле инвентаря distributed.inventory.yml, чтобы в нем были актуальные сведения на случай обновления KUMA.

  Добавление серверов завершено.

• Добавление серверов для корреляторов в распределенную установку.

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

  Чтобы добавить серверы в распределенную установку:

  1. Убедитесь, что на целевых машинах соблюдены аппаратные и программные требования, а также требования к установке.
  2. На контрольной машине перейдите в директорию с распакованным установщиком KUMA, выполнив следующую команду:

     cd kuma-ansible-installer

  3. Скопируйте шаблон expand.inventory.yml.template и создайте файл инвентаря с именем expand.inventory.yml:

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

  4. Отредактируйте параметры файла инвентаря expand.inventory.yml и укажите в нем серверы, которые вы хотите добавить, в разделе kuma_correlator.

     Пример файла инвентаря expand.inventory.yml для добавления серверов для корреляторов

     kuma:

     vars:

     ansible_connection: ssh

     ansible_user: root

     children:

     kuma_collector:

     kuma_correlator:

     kuma-additional-correlator1.example.com

     kuma-additional-correlator2.example.com

     kuma_storage:

     hosts:

  5. На контрольной машине с доступом root из папки с распакованным установщиком выполните следующую команду:

     ./expand.sh expand.inventory.yml

     В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml, появятся файлы для создания и установки коррелятора.

  6. Создайте и установите корреляторы. Поскольку корреляторы KUMA состоят из двух частей, клиентской и серверной, вы будете создавать корреляторы в два этапа.
     1. Создание клиентской части коррелятора, которая включает в себя набор ресурсов и сервис коллектора.

        Чтобы создать набор ресурсов для коррелятора, в веб-интерфейсе KUMA в разделе Ресурсы → Корреляторы нажмите Добавить коррелятор и настройте параметры. Подробнее см. Создание коррелятора.

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

     2. Создание серверной части коррелятора.
     1. На целевой машине выполните скопированную на предыдущем шаге команду. Команда будет выглядеть подобным образом, но все значения всех параметров будут автоматически присвоены.

        sudo /opt/kaspersky/kuma/kuma <storage> --core https://<FQDN сервера Ядра KUMA>:<порт, используемый Ядром KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса, скопированный из веб-интерфейса KUMA> --install

        Сервис коррелятора установлен на целевой машине. Вы можете проверить статус сервиса в веб-интерфейсе в разделе Ресурсы → Активные сервисы.

     2. Повторите выполнение команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml.
  7. Укажите добавленные серверы в файле инвентаря distributed.inventory.yml, чтобы в нем были актуальные сведения на случай обновления KUMA.

  Добавление серверов завершено.

• Добавление серверов в существующий кластер хранения.

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

  Чтобы добавить серверы в существующий кластер хранения:

  1. Убедитесь, что на целевых машинах соблюдены аппаратные и программные требования, а также требования к установке.
  2. На контрольной машине перейдите в директорию с распакованным установщиком KUMA, выполнив следующую команду:

     cd kuma-ansible-installer

  3. Скопируйте шаблон expand.inventory.yml.template и создайте файл инвентаря с именем expand.inventory.yml:

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

  4. Отредактируйте параметры файла инвентаря expand.inventory.yml и укажите в нем серверы, которые вы хотите добавить, в разделе storage. В следующем примере в разделе storage указаны серверы для установки двух шардов, каждый из которых будет содержать по две реплики. В файле инвентаря expand.inventory.yml следует указать только FQDN, роли шардов и реплик вы будете назначать позднее в веб-интерфейсе KUMA, последовательно выполняя шаги инструкции. Вы можете адаптировать этот пример под свои потребности.

     Пример файла инвентаря expand.inventory.yml для добавления серверов в существующий кластер хранения

     kuma:

     vars:

     ansible_connection: ssh

     ansible_user: root

     children:

     kuma_collector:

     kuma_correlator:

     kuma_storage:

     hosts:

     kuma-storage-cluster1-server8.example.com

     kuma-storage-cluster1-server9.example.com

     kuma-storage-cluster1-server10.example.com

     kuma-storage-cluster1-server11.example.com

  5. На контрольной машине с доступом root из папки с распакованным установщиком выполните следующую команду:

     ./expand.sh expand.inventory.yml

     В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml, появятся файлы для создания и установки хранилища.

  6. Поскольку вы добавляете серверы в существующий кластер хранения, создавать отдельное хранилище не требуется. Измените параметры хранилища существующего кластера:
     1. В разделе Ресурсы → Хранилища выберите существующее хранилище и откройте его для редактирования.
     2. В разделе Узлы кластера ClickHouse нажмите Добавить узлы и в появившихся полях для нового узла укажите роли. В следующем примере показано, как указать идентификаторы, чтобы добавить в существующий кластер два шарда, каждый из которых содержит две реплики. Вы можете адаптировать пример под свои потребности.

        Пример:

        Узлы кластера ClickHouse

        <существующие узлы>

        Полное доменное имя: kuma-storage-cluster1server8.example.com

        Идентификатор шарда: 1

        Идентификатор реплики: 1

        Идентификатор кипера: 0

        Полное доменное имя: kuma-storage-cluster1server9.example.com

        Идентификатор шарда: 1

        Идентификатор реплики: 2

        Идентификатор кипера: 0

        Полное доменное имя: kuma-storage-cluster1server9.example.com

        Идентификатор шарда: 2

        Идентификатор реплики: 1

        Идентификатор кипера: 0

        Полное доменное имя: kuma-storage-cluster1server10.example.com

        Идентификатор шарда: 2

        Идентификатор реплики: 2

        Идентификатор кипера: 0

     3. Сохраните параметры хранилища.

        Теперь можно создать сервисы хранилища для каждого узла кластера ClickHouse.

  7. Чтобы создать сервис хранилища, в веб веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы нажмите Добавить сервис.

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

     В результате количество созданных сервисов должно равняться количеству добавляемых узлов в кластере ClickHouse, то есть четыре узла - четыре сервиса. Созданные сервисы хранилища отображаются в веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы.

  8. Теперь сервисы хранилища необходимо установить на каждом сервере, используя идентификатор сервиса.
     1. В веб-интерфейсе KUMA Ресурсы → Активные сервисы выберите нужный сервис хранилища и нажмите Копировать идентификатор.

        Идентификатор сервиса будет скопирован в буфер обмена, он понадобится для выполнения команды установки сервиса.

     2. Сформируйте и выполните на целевой машине следующую команду:

        sudo /opt/kaspersky/kuma/kuma <storage> --core https://<FQDN сервера Ядра KUMA>:<порт, используемый Ядром KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса, скопированный из веб-интерфейса KUMA> --install

        Сервис хранилища установлен на целевой машине. Вы можете проверить статус сервиса в веб-интерфейсе в разделе Ресурсы → Активные сервисы.

     3. Последовательно выполните команду установки сервиса хранилища на каждой целевой машине, указанной в разделе storage в файле инвентаря expand.inventory.yml. На каждой машине в команде установки следует указывать уникальный идентификатор сервиса в рамках кластера.
  9. Чтобы применить изменения в работающем кластере, в веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы установите флажок рядом со всеми сервисами хранилища в кластере, который вы расширяете, и нажмите Обновить параметры. Изменения будут применены без остановки сервисов.
  10. Укажите добавленные серверы в файле инвентаря distributed.inventory.yml, чтобы в нем были актуальные сведения на случай обновления KUMA.

  Добавление серверов в кластер хранения завершено.

• Добавление дополнительного кластера хранения.

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

  Чтобы добавить дополнительный кластер хранения:

  1. Убедитесь, что на целевых машинах соблюдены аппаратные и программные требования, а также требования к установке.
  2. На контрольной машине перейдите в директорию с распакованным установщиком KUMA, выполнив следующую команду:

     cd kuma-ansible-installer

  3. Скопируйте шаблон expand.inventory.yml.template и создайте файл инвентаря с именем expand.inventory.yml:

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

  4. Отредактируйте параметры файла инвентаря expand.inventory.yml и укажите в нем серверы, которые вы хотите добавить, в разделе storage. В следующем примере в разделе storage указаны серверы для установки трех выделенных киперов и двух шардов, каждый из которых будет содержать по две реплики. В файле инвентаря expand.inventory.yml следует указать только FQDN, роли киперов, шардов и реплик вы будете назначать позднее в веб-интерфейсе KUMA, последовательно выполняя шаги инструкции. Вы можете адаптировать этот пример под свои потребности.

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

     kuma:

     vars:

     ansible_connection: ssh

     ansible_user: root

     children:

     kuma_collector:

     kuma_correlator:

     kuma_storage:

     hosts:

     kuma-storage-cluster2-server1.example.com

     kuma-storage-cluster2-server2.example.com

     kuma-storage-cluster2-server3.example.com

     kuma-storage-cluster2-server4.example.com

     kuma-storage-cluster2-server5.example.com

     kuma-storage-cluster2-server6.example.com

     kuma-storage-cluster2-server7.example.com

  5. На контрольной машине с доступом root из папки с распакованным установщиком выполните следующую команду:

     ./expand.sh expand.inventory.yml

     В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml, появятся файлы для создания и установки хранилища.

  6. Создайте и установите хранилище. Для каждого кластера хранения следует создавать отдельное хранилище, то есть три кластера хранения - три хранилища. Поскольку хранилище состоит из двух частей, клиентской и серверной, вы будете создавать хранилище в два этапа.
     1. Создание клиентской части хранилища, которая включает в себя набор ресурсов и сервис хранилища.
        1. Чтобы создать набор ресурсов для хранилища, в веб-интерфейсе KUMA в разделе Ресурсы → Хранилища нажмите Добавить хранилище и настройте параметры. В разделе Узлы кластера ClickHouse укажите роли для каждого добавляемого сервера: кипер, шард, реплика. Подробнее см. Создание набора ресурсов для хранилища.

           Созданный набор ресурсов для хранилища отображается в разделе Ресурсы → Хранилища. Теперь можно создать сервисы хранилища для каждого узла кластера ClickHouse.

        2. Чтобы создать сервис хранилища, в веб веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы нажмите Добавить сервис.

           В открывшемся окне Выберите сервис выберите созданный на шаге a. набор ресурсов для хранилища и нажмите Создать сервис. Повторите для каждого узла хранилища ClickHouse.

           В результате количество созданных сервисов должно равняться количеству узлов в кластере ClickHouse, то есть пятьдесят узлов - пятьдесят сервисов. Созданные сервисы хранилища отображаются в веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы. Теперь сервисы хранилища необходимо установить на каждом узле кластера ClickHouse, используя идентификатор сервиса.

     2. Создание серверной части хранилища.
     1. На целевой машине создайте серверную часть хранилища: в веб-интерфейсе KUMA Ресурсы → Активные сервисы выберите нужный сервис хранилища и нажмите Копировать идентификатор.

        Идентификатор сервиса будет скопирован в буфер обмена, он понадобится для выполнения команды установки сервиса.

     2. Сформируйте и выполните на целевой машине следующую команду:

        sudo /opt/kaspersky/kuma/kuma <storage> --core https://<FQDN сервера Ядра KUMA>:<порт, используемый Ядром KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса, скопированный из веб-интерфейса KUMA> --install

        Сервис хранилища установлен на целевой машине. Вы можете проверить статус сервиса в веб-интерфейсе в разделе Ресурсы → Активные сервисы.

     3. Последовательно выполните команду установки сервиса хранилища на каждой целевой машине, указанной в разделе storage в файле инвентаря expand.inventory.yml. На каждой машине в команде установки следует указывать уникальный идентификатор сервиса в рамках кластера.
     4. Выделенные киперы запускаются автоматически сразу после установки и отображаются в разделе Ресурсы → Активные сервисы в зеленом статусе. Сервисы на остальных узлах хранилища могут не запускаться до тех пор, пока не будут установлены сервисы для всех узлов данного кластера. До этого момента сервисы могут отображаться в красном статусе. Это нормальное поведение для создания нового кластера хранения или добавления узлов в существующий кластер хранения. Как только будет выполнена команда установки сервисов на всех узлах кластера, все сервисы переходят в зеленый статус.
  7. Укажите добавленные серверы в файле инвентаря distributed.inventory.yml, чтобы в нем были актуальные сведения на случай обновления KUMA.

  Добавление дополнительного кластера хранения завершено.

• Удаление серверов из распределенной установки.

  Чтобы удалить сервер из распределенной установки:

  1. Удалите все сервисы с сервера, который вы планируете удалить из распределенной установки.
     1. Удалите серверную часть сервиса. Скопируйте в веб-интерфейсе KUMA идентификатор сервиса и запустите на целевой машине следующую команду:

        sudo /opt/kaspersky/kuma/kuma <collector/correlator/storage> --core https://<FQDN сервера Ядра KUMA>:<порт, используемый ядром KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса, скопированный из веб-интерфейса KUMA> --uninstall

     2. Удалите клиентскую часть сервиса в веб-интерфейсе KUMA в разделе Активные сервисы – Удалить.

        Сервис удален.

  2. Повторите шаг 1 для каждого сервера, который вы хотите удалить из инфраструктуры.
  3. Удалите серверы из соответствующих разделов файла инвентаря distributed.inventory.yml, чтобы в файле инвентаря были актуальные сведения на случай обновления KUMA.

  Серверы удалены из распределенной установки.

• Удаление кластера хранения из распределенной установки.

  Чтобы удалить один или несколько кластеров хранения из распределенной установки:

  1. Удалите сервис хранилища на каждом сервере кластера, подлежащем удалению из распределенной установки.
     1. Удалите серверную часть сервиса хранилища. Скопируйте в веб-интерфейсе KUMA идентификатор сервиса и запустите на целевой машине следующую команду:

        sudo /opt/kaspersky/kuma/kuma <storage> --id <идентификатор сервиса> --uninstall

        Повторите для каждого сервера.

     2. Удалите клиентскую часть сервиса в веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы → Удалить.

        Сервис удален.

  2. Удалите серверы из раздела storage в файле инвентаря distributed.inventory.yml, чтобы в файле инвентаря были актуальные сведения на случай обновления KUMA или изменения конфигурации.

  Кластер удален из распределенной установки.

• Перенос Ядра KUMA в новый кластер Kubernetes.

  Чтобы перенести Ядро KUMA в новый кластер Kubernetes, выполните следующие шаги:

  1. Подготовьте файл инвентаря k0s.inventory.yml.

     В файле инвентаря k0s.inventory.yml в разделах kuma_core, kuma_ collector, kuma_correlator, kuma_storage укажите те же хосты, которые использовались при обновлении KUMA с версии 2.1.3 до версии 3.0.3 или при новой установке программы. В файле инвентаря необходимо присвоить параметрам deploy_to_k8s, need_transfer и airgap значение true. Параметру deploy_example_services необходимо присвоить значение false.

     Пример файла инвентаря с 3 выделенными контроллерами, 2 рабочими узлами и 1 балансировщиком.

  2. Выполните шаги распределенной установки с использованием подготовленного файла инвентаря k0s.inventory.yml.

  Процесс переноса Ядра KUMA в новый кластер Kubernetes

  При запуске установщика с файлом инвентаря производится поиск установленного Ядра KUMA на всех хостах, на которых планируется размещать рабочие узлы кластера. Найденное Ядро будет перенесено с хоста внутрь создаваемого кластера Kubernetes.

  Если на рабочих узлах компонент не обнаружен, то производится чистая установка Ядра KUMA в кластер без переноса в него ресурсов. Существующие компоненты требуется пересоздать с новым Ядром вручную в веб-интерфейсе KUMA.

  Для коллекторов, корреляторов и хранилищ из файла инвентаря будут заново выпущены сертификаты для связи с Ядром внутри кластера. URL Ядра для компонентов при этом не изменится.

  На хосте с Ядром установщик выполняет следующие действия:

  • Удаляет с хоста systemd-сервисы: kuma-core, kuma-mongodb, kuma-victoria-metrics, kuma-vmalert, kuma-grafana.
  • Удаляет internal сертификат Ядра.
  • Удаляет файлы сертификатов всех прочих компонентов и удаляет записи о них из MongoDB.
  • Удаляет директории:
    • /opt/kaspersky/kuma/core/bin
    • /opt/kaspersky/kuma/core/certificates
    • /opt/kaspersky/kuma/core/log
    • /opt/kaspersky/kuma/core/logs
    • /opt/kaspersky/kuma/grafana/bin
    • /opt/kaspersky/kuma/mongodb/bin
    • /opt/kaspersky/kuma/mongodb/log
    • /opt/kaspersky/kuma/victoria-metrics/bin
  • Переносит данные Ядра и ее зависимостей на сетевой диск внутри кластера Kubernetes.
  • На хосте с Ядром переносит директории:
    • /opt/kaspersky/kuma/core → /opt/kaspersky/kuma/core.moved
    • /opt/kaspersky/kuma/grafana → /opt/kaspersky/kuma/grafana.moved
    • /opt/kaspersky/kuma/mongodb → /opt/kaspersky/kuma/mongodb.moved
    • /opt/kaspersky/kuma/victoria-metrics → /opt/kaspersky/kuma/victoria-metrics.moved

  После проверки корректности переноса Ядра в кластер данные директории можно удалить.

  В случае возникновения проблем с переносом нужно проанализировать в журнале записи задачи переноса core-transfer в пространстве имен kuma на кластере (задача доступна в течение 1 часа после переноса).

  При необходимости повторного переноса необходимо привести названия директорий /opt/kaspersky/kuma/*.moved к их исходному виду.

  Если на хосте с Ядром использовался файл /etc/hosts со строками, не относящимися к адресам 127.X.X.X, при переносе Ядра в кластер Kubernetes содержимое файла /etc/hosts с хоста с Ядром заносится в ConfigMap coredns. Если переноса Ядра не происходит, в ConfigMap заносится содержимое /etc/hosts с хоста, на котором разворачивается главный контроллер.

Обновление предыдущих версий KUMA

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

Схема обновления версий:

2.0.х → 2.1.3 → 3.0.3

2.1.х → 2.1.3 → 3.0.3

2.1.3 → 3.0.3

3.0.x → 3.0.3

Обновление с версии 2.0.x до 2.1.3

Обновление с версии 2.1.x до 2.1.3

Обновление с версии 2.1.3 до 3.0.3

Обновление с версии 3.0.x до 3.0.3

Если вы хотите обновить KUMA в распределенной установке до последней версии KUMA в отказоустойчивой конфигурации, выполните обновление в распределенной установке до последней версии, а затем выполните перенос Ядра KUMA в кластер Kubernetes. Для дальнейшего обновления используйте файл инвентаря k0s.inventory.yml с параметром need_transfer: false, поскольку перенос Ядра KUMA в кластер Kubernetes уже выполнен и больше не требуется.

Устранение ошибок при обновлении

При обновлении KUMA вы можете столкнуться со следующими ошибками:

• Ошибка по таймауту

  При обновлении c версии 2.0.x на системах, которые содержат большие данные и при этом работают на предельных ресурсах, после того, как вы введете пароль администратора, система может вернуть сообщение об ошибке Wrong admin password. Если вы указываете верный пароль, KUMA может все равно возвращать ошибку, потому что из-за предельных ресурсов и ошибки по таймауту KUMA не удалось запустить сервис Ядра. Если вы введете пароль администратора трижды, не дожидаясь завершения установки, обновление может завершиться фатальной ошибкой.

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

  1. Откройте отдельный второй терминал и запустите следующую команду, чтобы убедиться, что вывод команды содержит строку с сообщением об ошибке таймауту:

     journalctl -u kuma-core | grep 'start operation timed out' 

     Сообщение об ошибке по таймауту:

     kuma-core.service: start operation timed out. Terminating.

  2. После того, как вы нашли сообщение об ошибке по таймауту, в файле сервиса /usr/lib/systemd/system/kuma-core.service измените значение параметра TimeoutSec с 300 на 0, чтобы снять ограничения по времени ожидания и временно исключить возможность повторного появления ошибки.
  3. После изменения файла сервиса последовательно выполните следующие команды:

     systemctl daemon-reload

     service kuma-core restart

  4. После выполнения команд и успешного запуска сервиса во втором терминале еще раз введите пароль администратора в исходном первом терминале, где установщик запрашивает пароль.

     KUMA продолжит установку. В условиях предельных ресурсов установка может занять до часа.

  5. После успешного завершения установки верните параметр TimeoutSec к значению 300 в файле /usr/lib/systemd/system/kuma-core.service.
  6. После изменения файла сервиса выполните следующие команды во втором терминале:

     systemctl daemon-reload

     service kuma-core restart

  После выполнения команд обновление будет успешно выполнено.

• Неверный пароль администратора

  Пароль к пользователю admin нужен для автоматического заполнения параметров хранилища при обновлении. Если при выполнении задачи TASK [Prompt for admin password] вы указали неверный пароль к пользователю admin девять раз, установщик все равно выполнит обновление и веб-интерфейс будет доступен, но настройки хранилища не мигрируют и хранилища будут в красном статусе.

  Чтобы устранить ошибку и сделать хранилища вновь доступными для работы, обновите настройки хранилища:

  1. Перейдите в настройки хранилища, вручную заполните поля кластера ClickHouse и нажмите Сохранить.
  2. Перезапустите сервис хранилища.

  Сервис хранилища будет запущен с заданными параметрами и будет в зеленом статусе.

• Ошибка DB::Exception

  После обновления KUMA хранилище может быть в красном статусе, а в его журналах могут отображаться ошибки о подозрительных строках.

  Пример ошибки:

  DB::Exception::Exception(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, int, bool) @ 0xda0553a in /opt/kaspersky/kuma/clickhouse/bin/clickhouse

  Чтобы перезапустить ClickHouse, выполните следующую команду на сервере хранилища KUMA:

  touch /opt/kaspersky/kuma/clickhouse/data/flags/force_restore_data && systemctl restart kuma-storage-<идентификатор хранилища, в котором обнаружена ошибка>

• Истечение срока действия сертификатов кластера k0s

  Симптомы

  Невозможно подключение контроллеров или рабочих узлов, перенос подов с одного рабочего узла на другой.

  В журналах сервисов k0scontroller и k0sworker появляются множественные записи со следующей подстрокой:

  x509: certificate has expired or is not yet valid

  Причина

  Срок действия служебных сертификатов кластера при создании - 1 год. Используемый в отказоустойчивой установке KUMA кластер k0s обеспечивает автоматическую ротацию всех необходимых ему служебных сертификатов, но ротация производится только при запуске сервиса k0scontroller. Если службы k0scontroller на контроллерах кластера работают без перезапуска больше 1 года, то служебные сертификаты становятся недействительными.

  Способ исправления

  Чтобы исправить ошибку, поочередно перезапустите сервисы k0scontroller с правами root на каждом контроллере кластера - сертификаты будут перевыпущены:

  systemctl restart k0scontroller

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

  find /var/lib/k0s/pki/ -type f -name "*.crt" -print|egrep -v 'ca.crt$'|xargs -L 1 -t -i bash -c 'openssl x509 -noout -text -in {}|grep After'

  find /var/lib/k0s/pki/etcd -type f -name "*.crt" -print|egrep -v 'ca.crt$'|xargs -L 1 -t -i bash -c 'openssl x509 -noout -text -in {}|grep After'

  Команды выведут названия файлов сертификатов и сроки их действия.

Устраните ошибки, чтобы успешно завершить обновление.

Удаление KUMA

При удалении KUMA используется инструмент Ansible и созданный пользователем файл инвентаря.

Чтобы удалить KUMA:

1. На контрольной машине войдите в директорию установщика:

   cd kuma-ansible-installer

2. Выполните следующую команду:

   sudo ./uninstall.sh <файл инвентаря>

KUMA и все данные программы удалены с серверов.

Базы данных, которые использовались KUMA (например, база данных хранилища ClickHouse), и содержащуюся в них информацию следует удалить отдельно.

Особенности удаления KUMA, установленной в отказоустойчивом варианте

Состав удаляемых компонентов зависит от значения параметра deploy_to_k8s в файле инвентаря, используемого для удаления KUMA:

• true – удаляется созданный при установке KUMA кластер Kubernetes.
• false – из кластера Kubernetes удаляются все компоненты KUMA, кроме Ядра. Сам кластер не удаляется.

Помимо установленных вне кластера компонентов KUMA на узлах кластера удаляются следующие директории и файлы:

• /usr/bin/k0s
• /etc/k0s/
• /var/lib/k0s/
• /usr/libexec/k0s/
• ~/k0s/ (для пользователя ansible_user)
• /opt/longhorn/
• /opt/cni/
• /opt/containerd

При удалении кластера возможен вывод на экран сообщений об ошибках, при котором работа установщика не прерывается.

• Для задач Delete KUMA transfer job и Delete KUMA pod такие сообщения можно игнорировать.
• Для задач Reset k0s (при сообщении об ошибке, содержащем текст "To ensure a full reset, a node reboot is recommended.") и Delete k0s Directories and files (при сообщении об ошибке, содержащем текст "Ошибка ввода/вывода: '/var/lib/k0s/kubelet/plugins/kubernetes.io/csi/driver.longhorn.io/") рекомендуется перезагрузить хост, к которому относится ошибка и выполнить повторное удаление KUMA с тем же файлом инвентаря.

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

Работа с тенантами

Доступ к тенантам регулируется в настройках пользователей. Главный администратор имеет доступ к данным всех тенантов. Только пользователь с этой ролью может создавать и удалять тенанты.

Тенанты отображаются в таблице раздела веб-интерфейса KUMA Параметры → Тенанты. Нажимая на столбцы, таблицу можно отсортировать.

Доступные столбцы:

• Название – название тенанта. Таблицу можно фильтровать по этому столбцу.
• Ограничение EPS – размер квоты EPS (частота обработки событий в секунду), выделенной тенанту из общей квоты EPS, которая определяется лицензией.
• Описание – описание тенанта.
• Выключено – отметка о том, является ли тенант неактивным.

  По умолчанию неактивные тенанты в таблице не отображаются. Вы можете их просмотреть, установив флажок Показать выключенных.

• Создан – дата создания тенанта.

Чтобы создать тенант:

1. В разделе веб-интерфейса KUMA Параметры → Тенанты нажмите Добавить.

   Откроется окно Добавить тенант.

2. В поле Название укажите название тенанта. Название должно содержать от 1 до 128 символов в кодировке Unicode.
3. В поле Ограничение EPS укажите квоту EPS для тенанта. Сумма EPS всех тенантов не может превышать EPS лицензии.
4. При необходимости добавьте Описание тенанта. Описание должно содержать не более 256 символов в кодировке Unicode.
5. Нажмите Сохранить.

Тенант добавлен. Нажмите F5, чтобы обновить страницу. После обновления страницы созданный тенант отображается в веб-интерфейсе.

Чтобы удалить тенант:

1. В разделе веб-интерфейса KUMA Параметры → Тенанты выберите нужный тенант, установив рядом флажок и на панели инструментов выберите Удалить.
2. В появившемся окне Удалить тенант будет указана информация о тенанте и будет предложено ввести код и подтвердить намерение удалить тенант. Если хотите продолжить удаление тенанта, введите код.
3. Нажмите OK.

Тенант удален.

При удалении тенанта принадлежащие ему сервисы автоматически останавливаются, за исключением агентов, прием и обработка событий прекращается, EPS тенанта более не учитывается в общем количестве EPS лицензии. Вы можете самостоятельно остановить сервисы агентов Windows в разделе Пуск → Сервисы и остановить сервисы агентов Linux в терминале, где был запущен агент, с помощью комбинации клавиш Ctrl + C.

Выбор тенанта

Если вы имеете доступ к нескольким тенантам, в KUMA можно выбрать, данные каких тенантов будут отображаться в веб-интерфейсе KUMA.

Чтобы выбрать тенант для отображения данных:

1. В веб-интерфейсе KUMA нажмите Выбрано тенантов.

   Откроется область выбора тенантов.

2. Установите флажки напротив тенантов, данные которых вы хотите видеть в разделах веб-интерфейса KUMA.
3. Требуется выбрать как минимум один тенант. Тенанты можно искать с помощью поля Поиск.
4. Закройте область выбора тенантов, нажав Выбрано тенантов.

В разделах веб-интерфейса KUMA отображаются только данные и аналитика, относящаяся к выбранным тенантам.

От выбранных для отображения данных тенантов зависит, какие тенанты можно будет указать при создании ресурсов, сервисов, макетов, шаблонов отчетов, виджетов, инцидентов, активов и других параметров KUMA, где можно выбрать тенант.

Правила принадлежности к тенантам

Правила наследования тенанта

Важно отслеживать, какому тенанту принадлежат создаваемые в KUMA объекты: от этого зависит, кто к ним будет иметь доступ и взаимодействие с какими объектами можно настроить. Правила определения тенанта:

• Тенант объекта (например, сервиса или ресурса) определяется пользователем при его создании.

  После создания объекта выбранный для него тенант невозможно изменить. Ресурсы, однако, можно экспортировать, а затем импортировать в другой тенант.

• Тенант алерта и корреляционного события наследуется от создавшего их коррелятора.

  Название тенанта указывается в поле события TenantId.

• Если события разных тенантов, обрабатываемых одним коррелятором, не смешиваются, создаваемые коррелятором корреляционные события наследуют тенант события.
• Тенант инцидента наследуется от алерта.

Примеры мультитенантных взаимодействий

Мультитенантность в KUMA дает возможность централизованно расследовать алерты и инциденты, возникающие в разных тенантах. Ниже приведены сценарии, по которым можно проследить, к каким тенантам принадлежат создаваемые объекты.

При корреляции событий от разных тенантов в общем потоке не следует группировать события по тенанту: то есть не нужно в правилах корреляции в поле Группирующие поля указывать поле события TenantId. Группировка событий по тенанту необходима, только если нужно не смешивать события от разных тенантов.

Сервисы, которые должны быть размещены на мощностях главного тенанта, разворачиваются только пользователями с ролью главный администратор.

• Корреляция событий в рамках одного тенанта, коррелятор выделен для этого тенанта и развернут на его стороне

  Условие:

  Коллектор и коррелятор принадлежат тенанту 2 (tenantID=2)

  Сценарий:

  1. Коллектор тенанта 2 получает и отправляет события в коррелятор тенанта 2.
  2. При срабатывании корреляционных правил в корреляторе создаются корреляционные события с идентификатором тенанта tenantID=2.
  3. Коррелятор отправляет корреляционные события в раздел хранилища для тенанта 2.
  4. Создается алерт, привязанный к тенанту с идентификатором tenantID=2.
  5. К алерту привязываются события, из-за которых он был создан.

  Инцидент создается пользователем вручную. Тенант инцидента определяется тенантом пользователя. Алерт привязывается к инциденту вручную или автоматически.

• Корреляция событий в рамках одного тенанта, коррелятор выделен для этого тенанта и развернут на стороне главного тенанта

  Условие:

  • Коллектор развернут на тенанте 2 и принадлежат ему (tenantID=2).
  • Коррелятор развернут на стороне главного тенанта.

    Принадлежность коррелятора определяется главным администратором в зависимости того, кто будет расследовать инциденты тенанта 2: сотрудники главного тенанта или тенанта 2. Принадлежность алерта и инцидента зависит от принадлежности коррелятора.

  Сценарий 1. Коррелятор принадлежит тенанту 2 (tenantID=2):

  1. Коллектор тенанта 2 получает и отправляет события в коррелятор.
  2. При срабатывании корреляционных правил в корреляторе создаются корреляционные события с идентификатором тенанта tenantID=2.
  3. Коррелятор отправляет корреляционные события в раздел хранилища тенанта 2.
  4. Создается алерт, привязанный к тенанту с идентификатором tenantID=2.
  5. К алерту привязываются события, из-за которых он был создан.

  Результат 1:

  • Созданный алерт и привязанные к нему события доступны сотрудникам тенанта 2.

  Сценарий 2. Коррелятор принадлежит главному тенанту (tenantID=1):

  1. Коллектор тенанта 2 получает и отправляет события в коррелятор.
  2. При срабатывании корреляционных правил в корреляторе создаются корреляционные события с идентификатором тенанта tenantID=1.
  3. Коррелятор отправляет корреляционные события в раздел хранилища главного тенанта.
  4. Создается алерт, привязанный к тенанту с идентификатором tenantID=1.
  5. К алерту привязываются события, из-за которых он был создан.

  Результат 2:

  • Алерт и привязанные к нему события недоступны сотрудникам тенанта 2.
  • Алерт и привязанные к нему события доступны сотрудникам главного тенанта.
• Централизованная корреляция событий, поступающих от разных тенантов

  Условие:

  • Развернуто два коллектора: на тенанте 2 и тенанте 3. Оба коллектора отправляют события в один коррелятор.
  • Коррелятор принадлежит главному тенанту. Правило корреляции ожидает события от обоих тенантов.

  Сценарий:

  1. Коллектор тенанта 2 получает и отправляет события в коррелятор главного тенанта.
  2. Коллектор тенанта 3 получает и отправляет события в коррелятор главного тенанта.
  3. При срабатывании корреляционного правила в корреляторе создаются корреляционные события с идентификатором тенанта tenantID=1.
  4. Коррелятор отправляет корреляционные события в раздел хранилища главного тенанта.
  5. Создается алерт, привязанный к главному тенанту с идентификатором tenantID=1.
  6. К алерту привязываются события, из-за которых он был создан.

  Результат:

  • Алерт и привязанные к нему события недоступны сотрудникам тенанта 2.
  • Алерт и привязанные к нему события недоступны сотрудникам тенанта 3.
  • Алерт и привязанные к нему события доступны сотрудникам главного тенанта.
• Тенант коррелирует свои события, но в главном тенанте дополнительно осуществляется централизованная корреляция событий

  Условие:

  • Развернуто два коллектора: на главном тенанте и тенанте 2.
  • Развернуто два коррелятора:
    • Коррелятор 1 принадлежит главному тенанту и принимает события с коллектора главного тенанта и коррелятора 2.
    • Коррелятор 2 принадлежит тенанту 2 и принимает события с коллектора тенанта 2.

  Сценарий:

  1. Коллектор тенанта 2 получает и отправляет события в коррелятор 2.
  2. При срабатывании корреляционного правила в корреляторе тенанта 2 создаются корреляционные события с идентификатором тенанта tenantID=2.
     • Коррелятор 2 отправляет корреляционные события в раздел хранилища тенанта 2.
     • Создается алерт 1, привязанный к тенанту с идентификатором tenantID=2.
     • К алерту привязываются события, из-за которых он был создан.
     • Корреляционные события от коррелятора тенанта 2 отправляются в коррелятор 1.
  3. Коллектор главного тенанта получает и отправляет события в коррелятор 1.
  4. В корреляторе 1 обрабатываются события обоих тенантов. При срабатывании корреляционного правила создаются корреляционные события с идентификатором тенанта tenantID=1.
     • Коррелятор 1 отправляет корреляционные события в раздел хранилища главного тенанта.
     • Создается алерт 2, привязанный к тенанту с идентификатором tenantID=1.
     • К алерту привязываются события, из-за которых он был создан.

  Результат:

  • Алерт 2 и привязанные к нему события недоступны сотрудникам тенанта 2.
  • Алерт 2 и привязанные к нему события доступны сотрудникам главного тенанта.
• Один коррелятор для двух тенантов

  Если вы не хотите, чтобы при корреляции события от разных тенантов смешивались, в правилах корреляции в поле Группирующие поля следует указывать поле события TenantId. В таком случае алерт наследует тенант от коррелятора.

  Условие:

  • Развернуто два коллектора: на тенанте 2 и тенанте 3.
  • Развернут один коррелятор, принадлежащий главному тенанту (tenantID=1). Он принимает события от обоих тенантов, но обрабатывает их независимо друг от друга.

  Сценарий:

  1. Коллектор тенанта 2 получает и отправляет события в коррелятор.
  2. Коллектор тенанта 3 получает и отправляет события в коррелятор.
  3. При срабатывании корреляционного правила в корреляторе создаются корреляционные события с идентификатором тенанта tenantID=1.
     • Коррелятор отправляет корреляционные события в раздел хранилища главного тенанта.
     • Создается алерт, привязанный к главному тенанту с идентификатором tenantID=1.
     • К алерту привязываются события, из-за которых он был создан.

  Результат:

  • Алерты, созданные на основе событий от тенанта 2 и 3, недоступны сотрудникам тенантов 2 и 3.
  • Алерты и привязанные к ним события доступны сотрудникам главного тенанта.

Управление пользователями

Доступ к KUMA может иметь несколько пользователей. Пользователям присваиваются роли пользователей, влияющие на задачи, которые пользователи могут выполнять. У разных тенантов у одного и того же пользователя могут быть разные роли. При этом вы не можете самостоятельно добавлять себе роли, даже если вашей учетной записи присвоена роль Главного администратора — список ролей будет отображаться без возможности изменения.

Вы можете создавать или изменять учетные записи пользователя в разделе веб-интерфейса KUMA Параметры → Пользователи. Пользователи также создаются в программе автоматически, если включена интеграция KUMA с Active directory и пользователь входит в веб-интерфейс KUMA с помощью своей доменной учетной записи в первый раз.

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

Таблица учетных записей отображается в окне Пользователи веб-интерфейса KUMA. Пользователей можно искать с помощью поля Поиск. Вы можете отсортировать таблицу по столбцу Данные о пользователе, нажав заголовок и выбрав По возрастанию или По убыванию.

Учетные записи можно создавать, изменять или выключать. При изменении учетных записей (как своей, так и чужих) для них можно сгенерировать API-токен.

По умолчанию выключенные учетные записи не отображаются в таблице пользователей, но их можно просмотреть, нажав на столбец Данные о пользователе и установив флажок Выключенные пользователи.

Чтобы выключить пользователя,

в разделе веб-интерфейса KUMA Параметры → Пользователи установите флажок напротив нужного пользователя и нажмите Выключить пользователя.

Роли пользователей

Пользователи KUMA могут иметь следующие роли:

• Главный администратор – эта роль предназначена для пользователей, отвечающих за функционирование основных систем KUMA. Например, они устанавливают системные компоненты, выполняют обслуживание, работают с сервисами, создают резервные копии и добавляют пользователей в систему. Эти пользователи имеют полный доступ к KUMA.
• Администратор тенанта – эта роль предназначена для пользователей, отвечающих за функционирование систем KUMA, принадлежащих определенным тенантам.
• Аналитик второго уровня – эта роль предназначена для пользователей, ответственных за настройку системы KUMA для получения и обработки событий определенного тенанта. Они также создают и настраивают правила корреляции.
• Аналитик первого уровня – эта роль предназначена для пользователей, ответственных за настройку системы KUMA для получения и обработки событий определенного тенанта. Они также создают и настраивают правила корреляции. Пользователи с этой ролью обладают меньшими правами, чем аналитик второго уровня.
• Младший аналитик – эта роль предназначена для пользователей, которые сталкиваются с непосредственными угрозами безопасности определенного тенанта. Пользователь с этой ролью посредством REST API видит ресурсы на общем тенанте.
• Доступ к общим ресурсам – эта роль предназначена для работы с общим тенантом. Пользователи с этой ролью обладают правом на чтение общих ресурсов. Редактировать ресурсы в общем тенанте может только пользователь с ролью Главный администратор.
• Работа с НКЦКИ – эта роль доступна для выбора, если в составе лицензии есть модуль НКЦКИ. Пользователи с этой ролью получают уведомления по умолчанию.
• Доступ к КИИ – эта роль доступна для выбора, если в составе лицензии есть модуль НКЦКИ. Пользователи с этой ролью получают уведомления по умолчанию.

  Права пользователей

  Раздел веб-интерфейса и действия	Главный администратор	Администратор тенанта	Аналитик второго уровня	Аналитик первого уровня	Младший аналитик	Доступ к общим ресурсам	Доступ к НКЦКИ	Доступ к КИИ	Комментарий
  Отчеты
  Создавать шаблон отчета	есть	есть	есть	есть	нет	нет	нет	нет
  Просматривать и изменять шаблоны и отчеты	есть	есть	есть	есть	нет	нет	нет	нет	Аналитик второго уровня и аналитик первого уровня может: Просматривать любые шаблоны и отчеты, свои и других пользователей, при условии что для роли доступны все тенанты, указанные в шаблоне. Изменять шаблоны/отчеты, которые создал сам. Аналитик второго уровня может изменять предустановленные шаблоны. Указание адреса электронной почты пользователя в шаблоне больше не является основанием для предоставления доступа к отчету, сформированному из шаблона. Отчет будет доступен пользователю для просмотра, если для роли пользователя доступны все тенанты, указанные в шаблоне.
  Формировать отчеты	есть	есть	есть	есть	нет	нет	нет	нет	Аналитик второго уровня и аналитик первого уровня может генерировать любые отчеты, свои и других пользователей, при условии что для роли доступны все тенанты, указанные в шаблоне. Аналитик второго уровня и аналитик первого уровня не может генерировать отчеты, которые были отправлены аналитику на почту.
  Выгружать сформированные отчеты	есть	есть	есть	есть	нет	нет	нет	нет	Аналитик второго уровня и аналитик первого уровня могут выгружать любые отчеты, при условии что для роли доступны все тенанты, указанные в шаблоне.
  Удалять шаблоны и сформированные отчеты	есть	есть	есть	есть	нет	нет	нет	нет	Аналитик второго уровня может удалить шабоны и отчеты, которые создал сам, а также предустановленные шаблоны. Аналитик второго уровня не может удалять отчеты, которые пришли ему на почту. Главный администратор, администратор тенанта, аналитик второго уровня может удалять предустановленные шаблоны и отчеты.
  Изменять настройки формирования отчетов	есть	есть	есть	есть	нет	нет	нет	нет	Аналитик второго уровня может изменять параметры формирования предустановленных шаблонов и отчетов, а также шаблонов и отчетов, которые создал сам. Аналитик первого уровня может изменять параметры формирования отчетов, которые создал сам.
  Дублировать шаблон отчета	есть	есть	есть	есть	нет	нет	нет	нет	Аналитик второго уровня и аналитик первого уровня может дублировать свои и предустановленные отчеты.
  Открывать сформированный отчет по почте	есть	есть	есть	есть	есть	нет	нет	нет	Если отчет рассылается в виде ссылки, он доступен только пользователям KUMA. Если отчет рассылается в виде вложения, отчет будет доступен получателю, если для роли получателя доступны все тенанты, указанные в шаблоне отчета.
  Панель мониторинга
  Просматривать данные на панели мониторинга и менять макеты	есть	есть	есть	есть	есть	нет	есть	есть	Доступно, если у пользователя есть полный доступ. Полный доступ означает, что список тенантов, определенных на уровне панели мониторинга, полностью совпадает со списком доступных пользователю тенантов. Также учитываются тенанты в переключателе.
  Просматривать универсальный макет	есть	есть	есть	есть	есть	нет	есть	есть
  Добавлять макеты	есть	есть	есть	есть	нет	нет	нет	нет	В том числе добавлять виджеты в макет. Добавлять универсальный макет может только главный администратор.
  Изменять и переименовывать макеты	есть	есть	есть	есть	нет	нет	нет	нет	В том числе добавлять, изменять и удалять виджеты. Аналитик второго уровня может изменять/переименовывать предустановленные макеты и макеты, созданные своей учетной записью. Аналитик первого уровня может изменять/переименовывать макеты, созданные своей учетной записью.
  Удалять макеты	есть	есть	есть	есть	нет	нет	нет	нет	Администратор тенанта может удалять макеты в доступных ему тенантах. Аналитик второго уровня и аналитик первого уровня может удалять макеты, созданные своей учетной записью. Главный администратор, администратор тенанта и аналитик второго уровня может удалять предустановленные макеты. При перезапуске сервиса kuma-core.service предустановленные макеты будут восстановлены в исходном виде, если прежде были удалены.
  Включать и выключать режим ТВ	есть	есть	есть	есть	есть	нет	есть	есть
  Ресурсы → Сервисы и Ресурсы → Сервисы → Активные сервисы
  Просматривать список активных сервисов	есть	есть	есть	есть	нет	нет	нет	нет	Только главный администратор может просматривать и удалять пространства у хранилища. Права доступа не зависят от выбранных в меню тенантов.
  Просматривать содержимое активного листа	есть	есть	есть	есть	нет	нет	нет	нет
  Импортировать/экспортировать/очищать содержимое активного листа	есть	есть	есть	есть	нет	нет	нет	нет	Аналитик первого уровня может импортировать данные в любой лист или таблицу коррелятора доступного тенанта.
  Создавать набор ресурсов для сервисов	есть	есть	есть	нет	нет	нет	нет	нет	Аналитик второго уровня не может создавать хранилища.
  Создавать сервис в разделе Ресурсы → Сервисы → Активные сервисы	есть	есть	нет	нет	нет	нет	нет	нет	Создать сервис может только главный администратор.
  Удалять сервисы	есть	есть	нет	нет	нет	нет	нет	нет
  Перезапускать сервисы	есть	есть	нет	нет	нет	нет	нет	нет
  Обновлять параметры сервисов	есть	есть	есть	нет	нет	нет	нет	нет
  Сбрасывать сертификаты	есть	есть	нет	нет	нет	нет	нет	нет	Пользователь с ролью администратор тенанта может сбрасывать сертификаты сервисов только в доступных ему тенантах.
  Ресурсы → Ресурсы
  Просматривать список ресурсов	есть	есть	есть	есть	нет	есть	нет	нет	Аналитик второго уровня и аналитик первого уровня не может просматривать список ресурсов секретов, однако эти ресурсы доступны им при создании сервисов.
  Добавлять ресурсы	есть	есть	есть	есть	нет	нет	нет	нет	Аналитик второго уровня и аналитик первого уровня не может добавлять ресурсы секретов.
  Дублировать ресурсы	есть	есть	есть	есть	нет	нет	нет	нет	Аналитик первого уровня может дублировать не созданный им ресурс, включая набор ресурсов сервиса. При этом в копии набора ресурсов сервиса аналитик первого уровня не может менять зависимые ресурсы.
  Изменять ресурсы	есть	есть	есть	есть	нет	нет	нет	нет	Аналитик первого уровня может изменять только те ресурсы, которые создал сам.
  Удалять ресурсы	есть	есть	есть	есть	нет	нет	нет	нет	Аналитик второго уровня не может удалять ресурсы секретов. Аналитик первого уровня может удалять только те ресурсы, которые создал сам.
  Импортировать ресурсы	есть	есть	есть	есть	нет	нет	нет	нет	Импортировать ресурсы в общий тенант может только главный администратор.
  Просматривать репозиторий, импортировать ресурсы из репозитория	есть	есть	есть	нет	нет	нет	нет	нет	Зависимые ресурсы Общего тенанта импортируются в Общий тенант. Отдельного права на Общий тенант не требуется, проверяется только наличие права на импорт в целевом тенанте.
  Экспортировать ресурсы	есть	есть	есть	есть	нет	есть	нет	нет	В том числе ресурсы из общего тенанта.
  Состояние источников → Список источников событий
  Просматривать источники событий	есть	есть	есть	есть	есть	нет	есть	есть
  Изменять источники событий	есть	есть	есть	нет	нет	нет	нет	нет
  Удалять источники событий	есть	есть	есть	нет	нет	нет	нет	нет
  Состояние источников → Политики мониторинга
  Просматривать политики мониторинга	есть	есть	есть	есть	есть	есть	есть	есть
  Создавать политики мониторинга	есть	есть	есть	нет	нет	нет	нет	нет
  Изменять политики мониторинга	есть	есть	есть	нет	нет	нет	нет	нет	Только главный администратор может редактировать предустановленные политики мониторинга.
  Удалять политики мониторинга	есть	есть	есть	нет	нет	нет	нет	нет	Предустановленные политики недоступны для удаления.
  Активы
  Просматривать активы и категории активов	есть	есть	есть	есть	есть	есть	есть	есть	Включая категории общего тенанта.
  Добавлять/редактировать/удалять категории активов	есть	есть	есть	есть	нет	нет	нет	нет	В рамках доступного пользователю тенанта.
  Добавлять категории активов в общем тенанте	есть	нет	нет	нет	нет	нет	нет	нет	В том числе редактировать и удалять категории общего тенанта.
  Привязывать активы к категории активов общего тенанта	есть	есть	есть	есть	нет	нет	нет	нет
  Добавлять активы	есть	есть	есть	есть	нет	нет	нет	нет
  Изменять активы	есть	есть	есть	есть	нет	нет	нет	нет
  Удалять активы	есть	есть	есть	есть	нет	нет	нет	нет
  Импортировать активы из Kaspersky Security Center	есть	есть	есть	есть	нет	нет	нет	нет
  Запускать задачи на активах в Kaspersky Security Center	есть	есть	есть	есть	нет	нет	нет	нет
  Запускать задачи на активах в Kaspersky Endpoint Detection and Response	есть	есть	есть	есть	нет	нет	нет	нет
  Подтверждать обновления для закрытия уязвимостей активов и соглашаться с лицензионными соглашениями	есть	есть	нет	нет	нет	нет	нет	нет
  Редактирование категоризации КИИ в карточке актива	есть	нет	нет	нет	нет	нет	нет	есть
  Редактирование пользовательских полей активов (Параметры → Активы)	есть	есть	есть	есть	нет	нет	нет	нет
  Алерты
  Просматривать список алертов	есть	есть	есть	есть	есть	нет	есть	есть
  Изменять уровень важности алертов	есть	есть	есть	есть	есть	нет	есть	есть
  Открывать детали алертов	есть	есть	есть	есть	есть	нет	есть	есть
  Назначать ответственных пользователей	есть	есть	есть	есть	есть	нет	есть	есть
  Закрывать алерты	есть	есть	есть	есть	есть	нет	есть	есть
  Добавлять комментарий к алертам	есть	есть	есть	есть	есть	нет	есть	есть
  Привязывать событие к алертам	есть	есть	есть	есть	есть	нет	есть	есть
  Отвязывать событие от алертов	есть	есть	есть	есть	есть	нет	есть	есть
  Изменять и удалять чужие фильтры	есть	есть	нет	нет	нет	нет	нет	нет	Аналитик второго уровня, аналитик первого уровня и младший аналитик могут изменять и удалять только свои ресурсы фильтров.
  Инциденты
  Просматривать список инцидентов	есть	есть	есть	есть	есть	нет	есть	есть
  Создавать пустые инциденты	есть	есть	есть	есть	есть	нет
  Создавать вручную инциденты из алертов	есть	есть	есть	есть	есть	нет
  Изменять уровень важности инцидентов	есть	есть	есть	есть	есть	нет	есть	есть
  Открывать детали инцидентов	есть	есть	есть	есть	есть	нет	есть	есть	В деталях инцидента отображаются данные только тех тенантов, к которым у пользователя есть доступ.
  Назначать исполнителей	есть	есть	есть	есть	есть	нет	есть	есть
  Закрывать инциденты	есть	есть	есть	есть	есть	нет	есть	есть
  Добавлять комментарии к инцидентам	есть	есть	есть	есть	есть	нет	есть	есть
  Привязывать алерты к инцидентам	есть	есть	есть	есть	есть	нет	есть	есть
  Отвязывать алерты от инцидентов	есть	есть	есть	есть	есть	нет	есть	есть
  Изменять и удалять чужие фильтры	есть	есть	нет	нет	нет	нет	нет	нет	Аналитик второго уровня, аналитик первого уровня и младший аналитик могут изменять и удалять только свои ресурсы фильтров.
  Экспортировать инциденты в НКЦКИ	есть	нет	нет	нет	нет	нет	есть	нет	Главному администратору функции доступны всегда, для остальных пользователей функции доступны, если у них в профиле установлен флажок "Может взаимодействовать с НКЦКИ".
  Отправлять файлы в НКЦКИ	есть	нет	нет	нет	нет	нет	есть	нет
  Скачивать файлы, отправленные в НКЦКИ	есть	нет	нет	нет	нет	нет	есть	нет
  Экспортировать дополнительные данные инцидентов в НКЦКИ по запросу	есть	нет	нет	нет	нет	нет	есть	нет
  Отправка сообщений в НКЦКИ	есть	нет	нет	нет	нет	нет	есть	нет
  Просмотр сообщений от НКЦКИ	есть	нет	нет	нет	нет	нет	есть	нет
  Просмотр данных инцидента, экспортированного в НКЦКИ	есть	нет	нет	нет	нет	нет	есть	нет
  События
  Просматривать список событий	есть	есть	есть	есть	есть	нет	есть	есть
  Выполнять поиск событий	есть	есть	есть	есть	есть	нет	есть	есть
  Открывать детали событий	есть	есть	есть	есть	есть	нет	есть	есть
  Открывать статистику	есть	есть	есть	есть	есть	нет	есть	есть
  Проводить ретроспективную проверку	есть	есть	есть	нет	нет	нет	нет	нет
  Выгружать события в TSV-файл	есть	есть	есть	есть	есть	нет	есть	есть
  Изменять и удалять чужие фильтры	есть	есть	нет	нет	нет	нет	нет	нет	Аналитик второго уровня, аналитик первого уровня и младший аналитик могут изменять и удалять только свои ресурсы фильтров.
  Запускать ktl-обогащение	есть	есть	есть	есть	нет	нет	нет	нет
  Запускать задачи на активах Kaspersky Endpoint Detection and Response в деталях событий	есть	есть	есть	есть	нет	нет	нет	нет
  Создавать пресеты	есть	есть	есть	есть	есть	нет	есть	есть
  Удалять пресеты	есть	есть	есть	есть	есть	нет	есть	есть	Аналитик второго уровня, аналитик первого уровня и младший аналитик могут удалять только свои пресеты.
  Просматривать и использовать пресеты	есть	есть	есть	есть	есть	нет	есть	есть
  Параметры → Пользователи
  Просматривать список пользователей	есть	нет	нет	нет	нет	нет	нет	нет
  Добавлять пользователя	есть	нет	нет	нет	нет	нет	нет	нет
  Изменять пользователя	есть	нет	нет	нет	нет	нет	нет	нет
  Генерировать токен	есть	есть	есть	есть	есть	есть	есть	есть	Каждый пользователь может сгенерировать себе токен. Главный администратор может сгененрировать токен любому пользователю.
  Изменять права доступа для токена	есть	есть	есть	есть	есть	есть	есть	есть	Главный администратор может изменить права доступа для любого пользователя. Каждый пользователь может назначить себе только те права, которые доступны ему в рамках его роли.
  Просматривать данные своего профиля	есть	есть	есть	есть	есть	есть	есть	есть
  Изменять данные своего профиля	есть	есть	есть	есть	есть	есть	есть	есть	Роль пользователя недоступна для изменения.
  Параметры → LDAP-сервер
  Просматривать параметры подключения к LDAP	есть	есть	есть	есть	нет	нет	нет	нет
  Изменять параметры подключения к LDAP	есть	есть	нет	нет	нет	нет	нет	нет
  Удалять конфигурацию всего тенанта из параметров	есть	есть	нет	нет	нет	нет	нет	нет
  Импортировать активы	есть	есть	нет	нет	нет	нет	нет	нет
  Параметры → Тенанты									Раздел доступен только главному администратору.
  Просматривать список тенантов	есть	нет	нет	нет	нет	нет	нет	нет
  Добавлять тенантов	есть	нет	нет	нет	нет	нет	нет	нет
  Изменять тенантов	есть	нет	нет	нет	нет	нет	нет	нет
  Отключать тенантов	есть	нет	нет	нет	нет	нет	нет	нет
  Параметры → Доменная аутентификация									Раздел доступен только главному администратору.
  Просматривать параметры подключения к Active directory	есть	нет	нет	нет	нет	нет	нет	нет
  Изменять параметры подключения к Active directory	есть	нет	нет	нет	нет	нет	нет	нет
  Добавлять фильтры по ролям для тенантов	есть	нет	нет	нет	нет	нет	нет	нет
  Запускать задачи в Active directory	есть	есть	есть	нет	нет	нет	нет	нет
  Параметры → Общие									Раздел доступен только главному администратору.
  Просматривать параметры подключения к SMTP	есть	нет	нет	нет	нет	нет	нет	нет
  Изменять параметры подключения к SMTP	есть	нет	нет	нет	нет	нет	нет	нет
  Параметры → Лицензия									Раздел доступен только главному администратору.
  Просматривать список добавленных лицензионных ключей	есть	нет	нет	нет	нет	нет	нет	нет
  Добавлять лицензионные ключи	есть	нет	нет	нет	нет	нет	нет	нет
  Удалять лицензионные ключи	есть	нет	нет	нет	нет	нет	нет	нет
  Параметры → Kaspersky Security Center
  Просматривать список Kaspersky Security Center-серверов, с которыми выполнена интеграция	есть	есть	есть	есть	нет	нет	нет	нет
  Добавлять подключения к Kaspersky Security Center	есть	есть	нет	нет	нет	нет	нет	нет
  Удалять подключения к Kaspersky Security Center	есть	есть	нет	нет	нет	нет	нет	нет
  Удалять конфигурацию всего тенанта из параметров	есть	есть	нет	нет	нет	нет	нет	нет
  Запускать задачи на импорт активов Kaspersky Security Center	есть	есть	нет	нет	нет	нет	нет	нет
  Параметры → Kaspersky Industrial CyberSecurity for Networks
  Просматривать список серверов KICS for Networks, с которыми выполнена интеграция	есть	есть	нет	нет	нет	нет	нет	нет
  Добавлять, изменять параметры интеграции с KICS for Networks	есть	есть	нет	нет	нет	нет	нет	нет
  Удалять параметры интеграции с KICS for Networks	есть	есть	нет	нет	нет	нет	нет	нет
  Запускать задачи на импорт активов из настройки для KICS for Networks	есть	есть	нет	нет	нет	нет	нет	нет
  Параметры → Kaspersky Automated Security Awareness Platform
  Просматривать параметры интеграции с ASAP	есть	нет	нет	нет	нет	нет	нет	нет
  Изменять параметры интеграции с ASAP	есть	нет	нет	нет	нет	нет	нет	нет
  Параметры → Kaspersky Endpoint Detection and Response
  Просматривать параметры подключений	есть	есть	есть	есть	нет	нет	нет	нет
  Добавлять, редактировать и отключать подключения при включенном режиме распределенного решения	есть	нет	нет	нет	нет	нет	нет	нет
  Включать режим распределенного решения	есть	нет	нет	нет	нет	нет	нет	нет
  Добавлять подключения при выключенном режиме распределенного решения	есть	есть	нет	нет	нет	нет	нет	нет
  Удалять подключения при выключенном режиме распределенного решения	есть	есть	нет	нет	нет	нет	нет	нет
  Удалять конфигурацию всего тенанта из параметров	есть	есть	нет	нет	нет	нет	нет	нет
  Параметры → Kaspersky CyberTrace									Раздел доступен только главному администратору.
  Просматривать параметры интеграции с CyberTrace	есть	нет	нет	нет	нет	нет	нет	нет
  Изменять параметры интеграции с CyberTrace	есть	нет	нет	нет	нет	нет	нет	нет
  Параметры → IRP / SOAR									Раздел доступен только главному администратору.
  Просматривать параметры интеграции с IRP / SOAR	есть	нет	нет	нет	нет	нет	нет	нет
  Изменять параметры интеграции с IRP / SOAR	есть	нет	нет	нет	нет	нет	нет	нет
  Параметры → Kaspersky Threat Lookup									Раздел доступен только главному администратору.
  Просматривать параметры интеграции с Threat Lookup	есть	нет	нет	нет	нет	нет	нет	нет
  Изменять параметры интеграции с Threat Lookup	есть	нет	нет	нет	нет	нет	нет	нет
  Параметры → Алерты
  Просматривать параметры	есть	есть	есть	есть	нет	нет	нет	нет
  Изменять параметры	есть	есть	есть	нет	нет	нет	нет	нет
  Удалять конфигурацию всего тенанта из параметров	есть	есть	есть	нет	нет	нет	нет	нет
  Параметры → Инциденты → Автоматическая привязка алертов к инцидентам									Раздел доступен для учетной записи с ролями администратор тенанта, аналитик второго уровня и аналитик первого уровня, если роль присвоена в тенанте Main.
  Просматривать параметры	есть	есть	есть	есть	нет	нет	нет	нет
  Изменять параметры	есть	нет	нет	нет	нет	нет	нет	нет
  Параметры → Инциденты → Типы инцидентов
  Просматривать справочник категорий	есть	есть	есть	есть	нет	нет	нет	нет
  Просматривать карточки категорий	есть	есть	есть	есть	нет	нет	нет	нет
  Добавлять категории	есть	есть	нет	нет	нет	нет	нет	нет
  Изменять категории	есть	есть	нет	нет	нет	нет	нет	нет
  Удалять категории	есть	есть	нет	нет	нет	нет	нет	нет
  Параметры → НКЦКИ
  Просматривать параметры	есть	нет	нет	нет	нет	нет	нет	нет
  Изменять параметры	есть	нет	нет	нет	нет	нет	нет	нет
  Параметры → Иерархия
  Просматривать параметры	есть	нет	нет	нет	нет	нет	нет	нет
  Изменять параметры	есть	нет	нет	нет	нет	нет	нет	нет
  Просматривать инциденты дочернего узла	есть	есть	есть	нет	есть	нет	нет	нет	Все пользователи родительского узла имеют доступ к инцидентам дочерних узлов.
  Параметры → Аудит активов
  Создавать, клонировать и редактировать параметры	есть	есть	есть	нет	нет	нет	нет	нет
  Просматривать параметры	есть	есть	есть	есть	нет	нет	нет	нет
  Удалять параметры	есть	есть	есть	нет	нет	нет	нет	нет
  Параметры → Обновление репозитория
  Просматривать параметры	есть	есть	есть	нет	нет	нет	нет	нет
  Изменять параметры	есть	нет	нет	нет	нет	нет	нет	нет
  Запуск задачи обновление репозитория вручную	есть	есть	есть	нет	нет	нет	нет	нет
  Параметры → Активы
  Добавлять, редактировать, удалять поля активов	есть	нет	нет	нет	нет	нет	нет	нет
  Метрики
  Открывать метрики	есть	нет	нет	нет	нет	нет	нет	нет
  Диспетчер задач
  Просматривать список своих задач	есть	есть	есть	есть	есть	нет	есть	есть	Пользователю с ролью главный администратор доступны задачи всех тенантов. Администратор тенанта может видеть и управлять задачами других пользователей в доступных ему тенантах. Пользователям доступны задачи в доступных тенантах. Пользователь может перезапустить задачу другого пользователя, если у него есть права на запуск этого типа задачи.
  Завершать свои задачи	есть	есть	есть	есть	есть	нет	есть	есть
  Перезапускать свои задачи	есть	есть	есть	есть	есть	нет	есть	есть
  Просматривать список всех задач	есть	нет	нет	нет	нет	нет	нет	нет
  Завершать любые задачи	есть	нет	нет	нет	нет	нет	нет	нет
  Перезапускать любые задачи	есть	нет	нет	нет	нет	нет	нет	нет
  CyberTrace									Раздел не отображается в веб-интерфейсе, если не настроена интеграция с CyberTrace в разделе Параметры → CyberTrace.
  Открывать раздел	есть	нет	нет	нет	нет	нет	нет	нет
  Доступ к данным тенантов
  Доступ к тенантам	есть	есть	есть	есть	есть	нет	есть	есть	Пользователь имеет доступ к тенанту, если его название указано в блоках параметров ролей учетной записи пользователя. Уровень доступа зависит от того, в какой из ролей указан тенант.
  Общий тенант	есть	есть	есть	есть	есть	есть	есть	есть	Общий тенант используется для хранения общих ресурсов, которые должны быть доступны для всех тенантов. Сервисы не могут принадлежать общему тенанту, но в них могут использоваться принадлежащие общему тенанту ресурсы. При этом такие сервисы принадлежат к своему тенанту. События, алерты и инциденты не могут быть общими. Права доступа к общему тенанту: чтение и запись – только главный администратор; чтение – остальные пользователи, включая пользователей с правами доступа к главному тенанту.
  Главный тенант	есть	есть	есть	есть	есть	нет	есть	есть	Пользователь имеет доступ к главному тенанту, если его название указано в блоках параметров ролей учетной записи пользователя. Уровень доступа зависит от того, в какой из ролей указан тенант. Права доступа к главному тенанту не дают доступ к другим тенантам.