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

Доверенная загрузка виртуальных машин

1. Общие сведения

Контроль целостности конфигурации виртуальной машины (далее — ВМ) реализуется программным пакетом secure_vms. При холодном старте, то есть при запуске ВМ из состояния «Выключено», фактическая конфигурация ВМ (конфигурация domxml на гипервизоре) сравнивается с эталоном, зафиксированным на сервере Engine. При расхождении служба VDSM (Virtual Desktop and Server Manager) блокирует запуск ВМ. ВМ должна быть указана в файле vars.yml.

2. Алгоритм процесса

  1. Формирование эталона (Engine):

    1. Выполняется запрос конфигурации ВМ через API zVirt.

    2. Выполняется скрипт /etc/ovirt-engine/secure_hasher.py, вычисляющий эталонное значение SHA256 для каждой ВМ, имя которой явно указано в файле vars.yml.

    3. Эталонное значение SHA256 каждой ВМ сохраняется в файл vm_hashes.json на сервере Engine.

  2. Развертывание:

    1. Файл vm_hashes.json и скрипт secure_vms копируются по SSH с Engine на все работающие гипервизоры каждого кластера, указанного в secure_clusters.

    2. Выполняется перезапуск службы vdsmd.

  3. Запуск ВМ:

    1. Перед тем как запустить ВМ, скрипт secure_vms считывает фактическую конфигурацию ВМ (domxml) с гипервизора через VDSM (hooking.read_domxml()).

    2. Скрипт secure_vms вычисляет хеш по тому же правилу и сравнивает с эталонным значением из файла vm_hashes.json, полученного гипервизором с сервера Engine.

    3. При совпадении значений ВМ запускается. При расхождении служба VDSM блокирует запуск ВМ.

3. Архитектура решения

Engine (API zVirt) Гипервизор

ovirt_vm_info → secure_hasher.py (--hash-vm)

before_vm_start secure_vms

Построение канонического JSON

read_domxml()

Вычисление SHA256 по UUID

Сравнение хеш-значений

Сохранение vm_hashes.json (на Engine)

Чтение /var/lib/vdsm/vm_hashes.json

4. Состав отпечатка конфигурации

Группа Поля

Compute

vm_name, vcpu, memory, current_memory, chipset (q35 / i440fx), firmware (bios / efi), secure_boot

Storage

disks[]: id, boot_order, bus; disk_count

Network

nics[]: mac, vlan, plugged; nic_count

Passthrough

hostdevs[]: type, address

Опционально

tpm.enabled, watchdog.model / action

5. Существующие ограничения

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

  2. Динамическое подключение устройств (hotplug) после запуска ВМ не отслеживается. Таким образом, изменения конфигурации, происходящие после запуска ВМ, не попадают под контроль целостности.

  3. В список эталонных хешей защищаемых ВМ (файл vm_hashes.json) попадают хеши только тех ВМ, имена которых явно указаны в файле vars.yml.

  4. Файл vm_hashes.json формируется вручную администратором с правами root на сервере Engine и копируется по SSH на все гипервизоры кластера.

Администратор с правами root на гипервизоре может подменить скрипт secure_vms или файл vm_hashes.json.

6. Установка и настройка пакета контроля целостности конфигурации ВМ

Порядок действий:

  1. Для установки пакета RPM на хосте с Менеджером управления выполните команду:

    dnf install secure-vms-1.0.0-1.zvn2.noarch.rpm

  2. По завершении установки проверьте, что на Engine доступны следующие компоненты:

    Путь Назначение

    /etc/ovirt-engine/secure_hasher.py

    Расчёт эталонного значения SHA256

    /usr/share/secure-vms/secure_vms.yml

    Основной playbook

    /usr/share/secure-vms/process_cluster.yml

    Обработка кластеров

    /usr/share/secure-vms/process_vm.yml

    Обработка одной ВМ

    /usr/share/secure-vms/vars.yml.example

    Шаблон настроек

    /usr/share/secure-vms/50_secure_vms.py

    Скрипт secure_vms (копируется на гипервизоры)

  3. Создайте файл vars.yml вручную из шаблона:

    cd /usr/share/secure-vms
cp vars.yml.example vars.yml
vim vars.yml

    или

    cd /usr/share/secure-vms
cp vars.yml.example vars.yml
nano vars.yml

    Не сохраняйте пароль Engine в файл vars.yml, так как запрос пароля выполняется при запуске процесса контроля целостности конфигурации.

  4. Заполните файл vars.yml по следующему шаблону:

    engine_url: "engine.mgmt.example.com"
engine_user: "admin@zvirt@internal"

secure_clusters:
  - cluster: "Default"
    vms:
      - "vm-database-01"
      - "vm-app-02"
  - cluster: "Production"
    vms:
      - "vm-secure-01"

hypervisor_ssh_user: root
hypervisor_ssh_private_key_file: "/etc/pki/ovirt-engine/keys/engine_id_rsa"
# hypervisor_ssh_common_args: "-o StrictHostKeyChecking=no"

    Описание параметров файла vars.yml приведено в таблице ниже:

Параметр Описание Примечания

engine_url

Имя (hostname) Engine для обращения к API zVirt

Указывается без https://, только FQDN, например engine.company.local

engine_user

Учётная запись для API zVirt

В большинстве случаев указывается admin@zvirt@internal

secure_clusters

Список кластеров и имена защищаемых ВМ

Поле cluster — имя кластера точно как в интерфейсе управления (регистр и пробелы важны). Поле vms — список имён ВМ. Указывается именно имя ВМ, а не её идентификатор UUID

hypervisor_ssh_user

Пользователь SSH для доступа с Engine на гипервизоры

В большинстве случаев указывается root

hypervisor_ssh_private_key_file

Приватный ключ для SSH

По умолчанию на Engine /etc/pki/ovirt-engine/keys/engine_id_rsa

hypervisor_ssh_common_args (опционально)

Дополнительные опции SSH

По умолчанию закомментирован. См. Остановка развертывания при установке hook

Проверьте, что параметры в файле vars.yml указаны корректно:

  • если при заполнении поля cluster будет допущена ошибка, хосты кластера не будут участвовать в процессе контроля целостности;

  • если имя ВМ из другого кластера будет указано не в том блоке, возникнет ошибка VM not found, и эта ВМ не будет участвовать в процессе контроля целостности;

  • если будет продублировано имя ВМ в одном кластере, возникнет ошибка Multiple VMs match.

7. Запуск процесса контроля целостности конфигурации ВМ

Порядок действий:

  1. На хосте с Менеджером управления запустите основной playbook:

    • Без вывода полного JSON ВМ и строк хешей в консоль (рекомендуется для продуктивного контура):

      ansible-playbook secure_vms.yml --skip-tags debug

    • С выводом полного JSON API zVirt (рекомендуется для отладки):

      ansible-playbook secure_vms.yml --tags debug

  2. Введите пароль Engine в ответ на запрос:

    Enter zVirt Engine admin password

    Не указывайте фиктивный пароль, например 1: вход в API zVirt не будет выполнен. Процесс завершится ошибкой аутентификации, либо эталонное значение не сформируется.

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

После установки и настройки пакета контроля целостности конфигурации ВМ выполните следующие действия:

  1. Проверьте наличие скрипта secure_vms и файла эталонных хешей на гипервизоре с помощью команд:

    ls -l /usr/libexec/vdsm/hooks/before_vm_start/50_secure_vms
ls -l /var/lib/vdsm/vm_hashes.json

  2. Проверьте наличие в журнале службы VDSM записей о выполнении скрипта secure_vms:

    grep secure_vm /var/log/vdsm/vdsm.log

  3. Проверьте, что формат файла vm_hashes.json соответствует следующему шаблону:

    {
  "fcd1d51c-73ad-40cf-be7e-b58e07bdfcf6": "3b5c0c7d0ad9d1c58a79413d4c2b4e840ecc2e393629e49831093369fe7247de"
}

    Где:

    • ключ fcd1d51c-73ad-40cf-be7e-b58e07bdfcf6 — UUID виртуальной машины;

    • значение 3b5c0c7d0ad9d1c58a79413d4c2b4e840ecc2e393629e49831093369fe7247de — вычисленное контрольное значение SHA256 конфигурации ВМ.

Значение — это строка из 64 шестнадцатеричных символов, а не вложенный JSON.

9. Регламент работы

Ситуация Действие

Добавлена новая ВМ на защищаемый хост

Добавьте имя ВМ в secure_clusters[].vms. Затем запустите процесс контроля целостности

Добавлен новый хост в защищённый кластер

Запустите процесс контроля целостности

Легитимно изменены RAM, диски, NIC, BIOS

Запустите процесс контроля целостности для обновления эталонного значения

ВМ переименована в интерфейсе управления

Запустите процесс контроля целостности для обновления эталонного значения

ВМ исключена из защиты

Удалите ВМ из файла vars.yml. Затем запустите процесс контроля целостности, по завершении которого запись UUID будет удалена из файла vm_hashes.json

Подозрение на подмену файлов на гипервизоре

Проверьте журнал службы VDSM на наличие записей secure_vm

Не редактируйте /var/lib/vdsm/vm_hashes.json на гипервизорах вручную.

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

10.1. Появляется сообщение skipping: no hosts matched

Сообщение skipping: no hosts matched означает, что этап Формирование эталона (Engine) выполнен без ошибок и эталонные хеши сохранены на Engine. Однако на этапе Развертывание не найдено ни одного гипервизора, поскольку в кластерах, заданных в файле vars.yml, нет хостов со статусом Работает (Up).

Порядок действий:

  1. Проверьте, что имена кластеров в файле vars.yml указаны корректно, и есть хосты со статусом Работает (Up).

  2. Проверьте, что имя кластера в запросе к API zVirt указано корректно.

10.2. ВМ не запускается, появляется сообщение Integrity violation

Порядок действий:

  1. Проверьте журнал службы VDSM, отфильтровав записи командой:

    grep secure_vm /var/log/vdsm/vdsm.log

  2. Сопоставьте следующие значения:

    • expected= — эталонный хеш из файла vm_hashes.json;

    • actual= — хеш текущего domxml;

    • domxml_current_state= — канонический JSON с гипервизора для сравнения с данными API zVirt.

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

  4. Обновите эталонное значение, если изменение выполнено легитимно. Для этого повторно выполните запуск процесса контроля целостности.

  5. Повторите запуск ВМ. После обновления эталонного значения запуск ВМ будет разрешён.

10.3. Появляется сообщение VM …​ not found in cluster

Порядок действий:

  1. Проверьте, что в файле vars.yml указаны правильные имена ВМ и кластеров.

  2. Проверьте, что ВМ указана в правильном кластере (блок secure_clusters) в файле vars.yml.

10.4. Развертывание остановилось при установке hook

Порядок действий:

  1. Проверьте наличие в выводе следующей записи:

    The authenticity of host 'host4.example.local (...)' can't be established.
Are you sure you want to continue connecting (yes/no)?

  2. Раскомментируйте в файле vars.yml параметр hypervisor_ssh_common_args: "-o StrictHostKeyChecking=no" и перезапустите скрипт:

    ansible-playbook secure_vms.yml --skip-tags debug

  3. Убедитесь, что в сводке PLAY RECAP для всех гипервизоров установлены значения ok или changed.

10.5. ВМ не блокируется при изменении конфигурации

Порядок действий:

  1. Проверьте, что ВМ указана в файле vars.yml. Если ВМ не указана, она не участвует в контроле целостности и не блокируется при изменении конфигурации.

  2. Проверьте, что пакет secure_vms установлен, а на гипервизоре выполнен основной playbook. Перезапустите службу VDSM.