Безопасность

Агент никогда не работает от root — ни при мониторинге, ни при автолечении. Всё, что требует root, делают две маленькие службы с закрытым списком действий. Ниже — честно о том, что каждая из них может, как это ограничено и что можно выключить на самом сервере.

Агент

Агент работает от системного пользователя warpfleet: без root, без единой capability, повысить права не может (sudo, su и setuid-программы для него не работают). Он собирает состояние, находит проблемы и сообщает о них, но сам ничего не меняет. Своё состояние держит в /var/lib/warpfleet/monitor.

sudo warpfleet-agent mode status    # что включено на сервере
sudo warpfleet-agent mode monitor   # применить настройки (флаги ниже)

Переустановка той же командой настройки сохраняет. Сервер, где стояла старая версия с лечением под root, после обновления сам переходит на эту схему: политика лечения переносится.

Помощник проверок

Часть данных без root не прочитать: проверки конфигураций nginx, Apache, HAProxy, PHP-FPM и BIND, запросы к PostgreSQL, LVM, SMART дисков, Kubernetes, keytab Active Directory, резервные копии закрытых системных файлов. Их в режиме мониторинга выполняет помощник проверок — отдельная служба warpfleet-probe под root, которую systemd запускает по запросу через локальный сокет.

• Помощник выполняет только проверки из закрытого списка, зашитого в программу: команды с точно заданными аргументами и разделы проверок по имени. Произвольную команду, SQL-запрос или путь к файлу ему передать нельзя.
• Сокет доступен только пользователю warpfleet; помощник дополнительно сверяет, кто к нему обратился.
• Резервные копии закрытых файлов (sudoers, подключения NetworkManager) помощник хранит в каталоге root; агенту он отдаёт только пути и контрольные суммы, не содержимое.
• Если агента взломают, через помощника можно лишь повторить эти проверки на чтение.

Данные с помощником те же, что получал бы агент под root. Помощника можно не ставить — curl … | sudo env WARPFLEET_PROBE_HELPER=off bash или sudo warpfleet-agent mode monitor --helper=off: тогда эти проверки не выполняются, а в карточке сервера перечислено, что именно не проверяется. В журналах при этом не остаётся «неудачных входов»: без помощника агент даже не пытается войти от имени postgres.

Служба исполнения: действия, обновления, терминал

Кнопки действий консоли, установку обновлений и веб-терминал для агента без root выполняет служба warpfleet-exec под root. Сам агент попросить её ни о чём не может:

• каждую команду консоль подписывает одноразовым билетом (Ed25519) — на эту команду, этот сервер и на 5 минут. Служба проверяет подпись открытым ключом консоли, который root сохранил при установке (/opt/warpfleet/runtime/console-key.pub), и не принимает один билет дважды;
• действия собираются только из встроенного каталога — по сети команды оболочки не передаются;
• каждое действие и каждая сессия терминала попадают в журнал авторизации сервера: кто запустил, что именно, результат;
• сессия терминала зашифрована от браузера до службы: браузер и служба договариваются об одноразовом ключе (ECDH P-256), каждое направление шифруется своим ключом AES-256-GCM, кадры пронумерованы. Агент и всё, через что идёт поток, видят только шифр — подсмотреть ввод, вставить команду или повторить кадр нельзя. Служба подписывает рукопожатие постоянным ключом сервера (exec-identity.key, root 0600), консоль закрепляет его открытую часть при первом подключении и без верной подписи сессию не начинает;
• вывод сессий терминала записывается на сервере в /var/log/warpfleet/sessions (формат asciinema, воспроизводится командой asciinema play). Ввод не пишется — в нём бывают пароли. Сессия закрывается после 30 минут без ввода.

Что разрешено, решает администратор сервера:

Терминал можно дополнительно закрыть кодом из письма — для отдельных, самых важных серверов: замок ставится в списке серверов консоли, а снять его тоже можно только с кодом. Остальные серверы открываются сразу.

Автолечение

Плейбуки исполняет та же служба исполнения, а не агент. Агент только сообщает ей об аварии и предлагает плейбук; дальше служба всё проверяет сама:

• плейбук берётся из её собственного каталога /opt/warpfleet/playbooks (root), который она обновляет только по манифесту, подписанному ключом WarpFleet; что предложил агент, служба заново сверяет с классом аварии;
• каждый параметр плейбука (имя службы, путь, пакет) проходит строгую проверку: неизвестный параметр — отказ, пакет должен быть владельцем файла, резервная копия — та, что сделала сама служба;
• службу, которую администратор остановил вручную, она не поднимает;
• политику лечения (что чинить самому, что спрашивать) служба читает из каталога, куда пишет только она сама — по билету консоли. Нет политики — не лечит;
• счётчики попыток, бюджет и защита от «вечного» перезапуска (3 успешные починки за сутки — дальше решает человек) ведутся у службы, агент их подделать не может.

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

Файл на сервер

Файл из консоли (до 200 МБ) шифруется от браузера до службы так же, как терминал, и кладётся в /var/lib/warpfleet/inbox — права 0640, без права на исполнение, существующий файл не перезаписывается. Через 7 дней служба удаляет его сама.

Что можно выключить на сервере

sudo warpfleet-agent mode monitor --terminal=root    # терминал сразу под root (по умолчанию)
sudo warpfleet-agent mode monitor --terminal=login   # вход по учётной записи сервера
sudo warpfleet-agent mode monitor --terminal=off     # без терминала
sudo warpfleet-agent mode monitor --actions=off      # без действий и установки обновлений
sudo warpfleet-agent mode monitor --heal=off         # без автолечения
sudo warpfleet-agent mode monitor --files=off        # без приёма файлов

При установке то же задаётся переменными WARPFLEET_TERMINAL, WARPFLEET_ACTIONS и WARPFLEET_HEAL, например curl … | sudo env WARPFLEET_TERMINAL=login bash. Если выключено всё — терминал, действия, лечение и файлы, — служба не устанавливается вовсе. Выбор сохраняется при переустановке.

Что исполняется на сервере

Всё ниже выполняет служба исполнения, а не агент, — по билетам консоли или по политике лечения (выше).

• Плейбуки из подписанного каталога — если автолечение разрешено политикой. Сами выполняются только сценарии, проверенные поломкой на стендах; остальные — по подтверждению оператора. Диски, RAID, тома LVM, файловые системы и сеть агент не меняет никогда, даже по подтверждению: в карточке — причина, чем это грозит, и готовые команды по шагам.
• Выполнять действия и пробы из встроенного каталога по запросу оператора из консоли (перезапуск службы, обновление пакетов, просмотр процессов и логов). Скрипты собирает сам агент из своего каталога — по сети команды оболочки не передаются.
• Открыть веб-терминал — полноценный root-доступ к серверу через консоль. Его можно выключить на сервере (см. ниже).
• Обновить себя по подписанному манифесту — по запросу оператора.

Как запретить исполнение на самом сервере

Надёжнее всего — режим мониторинга без службы исполнения: sudo warpfleet-agent mode monitor --actions=off --terminal=off --heal=off --files=off. Если нужно оставить пробы, но запретить остальное, есть выключатели в /opt/warpfleet/runtime/agent.env; из облака они не переопределяются, после правки — systemctl restart warpfleet-agent.

• WARPFLEET_OBSERVE_ONLY=1 — только наблюдение: агент находит проблемы и показывает, что сделал бы, но ничего не исполняет, не принимает действий и самообновления, терминал выключен. Пробы только на чтение (процессы, логи, сеть) работают. Задать сразу при установке: curl … | sudo WARPFLEET_OBSERVE_ONLY=1 bash.
• HA_AGENT_DISABLE_TERMINAL=1 — выключить только веб-терминал.
• HA_AGENT_DISABLE_ACTIONS=1 — никаких команд из консоли, даже на чтение.

Ограничения плейбуков

• Только команды из allowlist плейбука. Каждый плейбук объявляет разрешённые бинари; проверка выполняется дважды — до и после подстановки переменных.
• Оболочка — только где объявлена. Большинство шагов исполняются напрямую (argv). Примерно половина плейбуков использует sh для составных шагов — это видно в их allowed_commands, все плейбуки открыты в каталоге. Для переменных, попадающих в такой шаг, дополнительно запрещены пробелы и фигурные скобки.
• Переменные валидируются. Значения с shell-метасимволами (; | $ ` >…) или похожие на подстановку флагов отклоняются — плейбук откажется рендериться.
• Жёсткий таймаут — ни один шаг не живёт дольше 5 минут, что бы ни запросил плейбук.

Рискованное — только через человека

У каждого плейбука есть уровень риска. Низкий чинится автоматически, средний — по вашей политике, высокий (рестарт критичных служб, доменные операции) — только после явного подтверждения оператора в консоли. До подтверждения можно посмотреть dry-run: что именно будет исполнено.

Проверка результата и откат

После починки агент верифицирует, что проблема ушла. Не ушла — исполняет описанные в плейбуке шаги отката; как последняя линия — восстановление из бэкапа, снятого до вмешательства. Необратимые операции откат не имитируют: такие плейбуки честно помечены «ручной разбор» и эскалируются.

Цепочка доверия: всё подписано

• Бинарь агента и архив плейбуков распространяются с Ed25519-подписанным манифестом.
• Не совпала контрольная сумма или подпись — обновление отклоняется, текущая версия продолжает работать, в консоли открывается инцидент целостности.
• Подмена плейбука по пути «сервер → нода» невозможна без ключа подписи.

Изоляция самого агента

• Systemd-юнит с жёсткими лимитами: память — hard-cap 1 ГБ (обычно кратно меньше), watchdog перезапускает зависший процесс.
• Ограниченный набор Linux capabilities — без CAP_SYS_MODULE и прочего, что агенту не нужно.
• Сеть: только исходящий HTTPS с Bearer-токеном. Ни одного открытого порта, ни входящего SSH.

Аудит и роли

• Каждое действие — решение политики, исполненные команды, их вывод — в аудит-журнале.
• Секреты маскируются на сервере до отправки: в выводе команд, журналах и поиске по логам скрываются токены ботов (bot…:…), Bearer/Basic, пароли в URL, JWT, приватные ключи, ключи облаков и пары вида password=…. Маска шаблонная — секрет в нестандартном виде может пройти, поэтому не пишите секреты в журналы.
• Экспорт журнала (ndjson/csv) для вашего SIEM — на плане Business+.
• RBAC: viewer / operator / approver / admin — смотреть, действовать и подтверждать рискованное могут разные люди (Business+).

Данные

Облако размещено в РФ (152-ФЗ соблюдён, уведомление РКН подано). Состояние ноды хранится локально на ней (SQLite). В облачном варианте агент отправляет в WarpFleet (app.warpfleet.ru) снимки метрик и инцидентов, а по запросу из консоли — строки журналов служб, вывод проб и результаты поиска по логам (с маской секретов). Self-hosted-вариант не отправляет наружу ничего: всё уходит на ваш собственный сервер.

Установщик меняет только своё: создаёт службу warpfleet-agent и файлы в /opt/warpfleet и /var/lib/warpfleet. Настройки журнала сервера (journald) и приоритеты процессов при нехватке памяти он не трогает.

Полное удаление

Удаление из консоли (нода → удалить) останавливает и удаляет службу, стирает бинарь, плейбуки, файл с токеном (/opt/warpfleet), базу и рантайм-файлы (/var/lib/warpfleet), а также настройки журнала, которые писали прежние версии установщика. Ручная команда — в FAQ. Чего удаление вернуть не может: записи журнала, удалённые ротацией, и результаты уже выполненных починок.