Экстренная изоляция хоста

Экстренная изоляция ограничивает один скомпрометированный хост, не создавая обычную редактируемую policy. Системные правила изоляции подписываются Control Plane и применяются агентом раньше пользовательских правил. Изменять режим могут роли admin и editor; остальные авторизованные роли видят состояние без кнопок изменения.

Режимы

Полная изоляция блокирует входящий и исходящий IPv4/IPv6-трафик на всех интерфейсах, которые агент успешно подключил к datapath. Блокируются в том числе установленные соединения, фрагменты и протоколы без TCP/UDP-портов.
Частичная изоляция дополнительно пропускает перечисленные TCP/UDP-потоки. Исключение задаёт направление инициирования относительно хоста, протокол и service port либо диапазон. Ответный поток разрешается только при состоянии conntrack ESTABLISHED или RELATED.
Обычный режим означает, что экстренная изоляция снята и действует актуальный набор пользовательских политик.

Management path не настраивается как исключение. Агент всегда ставит перед изоляцией неизменяемую пару правил для своих IPv4-соединений к gRPC- и enrollment-endpoint Control Plane: исходящий TCP-запрос и входящий ответ от того же /32 и service port с обязательным флагом ACK. Это сохраняет SYN-ACK и установленный агентом поток, но не разрешает Control Plane открыть новое входящее соединение с SYN; socket tuple и TCP sequence проверяет стек ядра. Guard не включает conntrack и не меняет его настройки по умолчанию. ARP, необходимый для IPv4-маршрута, сохраняется. SSH, произвольные административные порты и IPv6-endpoint Control Plane в management path не входят.

Изоляция распространяется только на интерфейсы в attached-состоянии агента. Интерфейс с ATTACH_MODE_NONE не защищён. Автоматическое подключение нового NIC без перезапуска агента не выполняется; после штатного перезапуска активное состояние из кэша применяется ко всему новому набору успешно подключённых интерфейсов.

Состояние применения

В списке хостов и на странице хоста отображается один и тот же вложенный статус:

pending — Control Plane сохранил желаемый режим, но агент ещё не подтвердил его;
applied — агент подтвердил применение целевой generation ко всем attached-интерфейсам;
failed — сборка, доставка или применение завершились ошибкой; причина показана рядом.

Поля Запрошенный режим и Применённый режим намеренно могут различаться. До подтверждения операционной правдой остаётся применённый режим. Ошибка не заменяет last-good: агент восстанавливает предыдущую полную раскладку правил, а Control Plane не выдаёт новое состояние за применённое.

Применение и замена

На странице хоста в карточке Экстренная изоляция действие Настроить изоляцию открывает форму полного или частичного режима. Для частичного режима требуется хотя бы одно исключение; порты задаются целыми числами от 1 до 65535. Подтверждение создаёт целевую generation.

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

Повтор запроса с тем же желаемым состоянием при pending или applied возвращает существующее состояние без новой generation. Тот же запрос после failed создаёт новую попытку доставки. Замена режима или исключений выполняется одним полным набором без промежуточного возврата обычного доступа.

Недоступный хост остаётся в pending. Запрос хранится в PostgreSQL, переживает перезапуск Control Plane и отправляется при первом подключении агента с capability hostIsolation. Повторять операцию вручную после reconnect не требуется.

Восстановление сети

Действие Восстановить сеть создаёт отдельную подтверждаемую цель с режимом none. Обычная policy компилируется заново на момент восстановления, поэтому учитывает изменения, сделанные во время изоляции. Между containment и обычной policy не возникает пустого allow-all набора. Повторное восстановление уже применённого none не меняет revision или generation.

Если восстановление завершилось ошибкой, применённая изоляция остаётся last-good. Повтор того же действия после failed запускает новую попытку.

REST API

Все запросы используют обычную аутентификацию qf и tenant-заголовок X-Tenant-ID:

GET  /hosts/{id}/isolation
PUT  /hosts/{id}/isolation
POST /hosts/{id}/isolation/restore

Полная изоляция:

{"mode":"full"}

Частичная изоляция с исходящим HTTPS и входящим UDP-диапазоном:

{
  "mode": "partial",
  "exceptions": [
    {"direction":"egress","protocol":"tcp","port_start":443,"port_end":443},
    {"direction":"ingress","protocol":"udp","port_start":5000,"port_end":5010}
  ]
}

Новая цель и повтор после failed возвращают HTTP 202. Семантический no-op возвращает HTTP 200. Невалидная форма возвращает 400, запрещённая роль — 403, чужой или отсутствующий хост — 404, отсутствие capability — 409, недоступный механизм доставки до записи цели — 503. Полный контракт и примеры ответов находятся в справочнике REST API.

Обновление и откат компонентов

Безопасный порядок обновления:

Применить миграцию и обновить Control Plane.
Обновить агенты и дождаться capability hostIsolation в состоянии хостов.
Использовать экстренную изоляцию только на хостах с подтверждённой capability.

Безопасный порядок отката:

Восстановить сеть у всех хостов со статусом pending, applied или failed и дождаться desired.mode=none, applied.mode=none, status=applied.
Откатить агенты и Control Plane. Миграцию 000053 оставить применённой.
Down-миграция допустима только после проверки отсутствия строк с активным или неразрешённым состоянием; встроенный guard отклонит небезопасное удаление таблицы.

Удаление agent cache или ручная правка BPF maps не являются способом отката: кэш хранит подписанный last-good и защищает хост при потере связи с Control Plane.

Проверка после применения

Статус applied подтверждает применение агента, но операционная приёмка также включает проверку трафика:

Зафиксировать исходный статус, generation и обычный доступ.
Для полной изоляции проверить IPv4/IPv6 TCP, UDP, ICMP, фрагменты, уже установленную сессию и протокол без TCP/UDP-портов в обоих направлениях на каждом attached-интерфейсе.
Для частичной изоляции проверить разрешённые инициирующие потоки и их ответы, затем соседний порт, обратное незапрошенное подключение, фрагмент и другой протокол.
Одновременно наблюдать heartbeat агента и достижимость IPv4 gRPC/enrollment path.
После восстановления проверить возврат актуальной обычной policy и отсутствие новой generation при повторном restore.
В audit log сверить запрос и отдельный результат host-isolation.applied либо host-isolation.failed с revision, generation и причиной ошибки.

Для многоинтерфейсного хоста проверка выполняется с отдельного traffic peer на каждом интерфейсе. Состояние нельзя считать подтверждённым по одному статусу или одному сетевому пробнику: нужны и acknowledgement агента, и наблюдение трафика.

Режимы​

Состояние применения​

Применение и замена​

Восстановление сети​

REST API​

Обновление и откат компонентов​

Проверка после применения​