Task Runners: безопасный запуск Code-нод

Task Runners - это функция n8n, которая больше не выполняет JavaScript- и Python-код из Code-ноды в основном процессе n8n, а в отдельном изолированном процессе или контейнере. Это защищает остальную часть экземпляра n8n от того, что ошибочный или нежелательный код из workflow получает доступ к переменным окружения, файловой системе или другим выполняющимся workflow. Начиная с версии 1.111.0 внешний, полностью изолированный режим можно использовать в продакшене, внутренний режим (выполнение в качестве дочернего процесса с теми же правами, что и n8n) согласно документации n8n прямо не считается пригодным для продакшена. По состоянию на: июль 2026.

Почему выполнение кода напрямую в основном процессе является риском

До недавнего времени n8n выполнял код из Code-ноды напрямую в том же процессе, в котором работает и остальная часть движка workflow. Это просто реализовать, но рискованно: скрипт с доступом к встроенным средствам Node.js теоретически может получить доступ к переменным окружения, файловой системе или другим ресурсам экземпляра n8n, которые на самом деле не имеют отношения к отдельному workflow. Task Runners решают эту проблему, вынося выполнение кода из основного процесса. Согласно документации n8n, этот принцип представляет собой универсальный механизм для безопасного и производительного выполнения задач, конкретно для управляемого пользователем JavaScript- и Python-кода в Code-ноде. Три компонента работают вместе: Task Runner, который фактически выполняет код, Task Broker, являющийся частью основного экземпляра n8n или воркера и координирующий коммуникацию, и Task Requester, то есть сама Code-нода, запрашивающая выполнение. Коммуникация происходит через WebSocket-соединения: runner забирает задачи у брокера и возвращает результаты.

Сравнение внутреннего и внешнего режимов

n8n различает два режима работы. Во внутреннем режиме, настройке по умолчанию через N8N_RUNNERS_MODE=internal, n8n запускает Task Runner как дочерний процесс с тем же ID пользователя и группы, что и основной экземпляр. Это несколько снижает риск по сравнению со старым встроенным выполнением, но согласно документации не обеспечивает настоящей изоляции и явно не рекомендуется для продакшн-сред. Во внешнем режиме отдельное приложение-лаунчер берет на себя runner'ы в собственных контейнерах, обычно в виде sidecar-контейнера с образом n8nio/runners рядом с самим экземпляром n8n. Каждому воркеру в режиме очереди нужен собственный sidecar, как и основным экземплярам, которые сами обрабатывают ручные выполнения. Важно для эксплуатации: версия образа n8nio/runners должна соответствовать версии n8n, а внешние Task Runners требуют минимум n8n 1.111.0.

Защита с помощью изолированных контейнеров

Тот, кто эксплуатирует внешний режим в продакшене, может, согласно документации n8n по hardening, применить дополнительные защитные меры. К ним относятся distroless Docker-образ с суффиксом тега -distroless без менеджера пакетов и shell, выполнение от имени непривилегированного пользователя nobody с ID пользователя и группы 65532, корневая файловая система только для чтения с минимальным emptyDir-томом для /tmp, а также профиль AppArmor, блокирующий доступ к файлам /proc, таким как environ и mounts, тем самым предотвращающий чтение кодом из ноды переменных окружения или информации о монтировании. Все эти меры вместе дают заметно более узкую песочницу для Code-нод по сравнению со старым выполнением в основном процессе.

Важные переменные окружения в обзоре

• N8N_RUNNERS_MODE: internal (по умолчанию) или external, управляет режимом работы.
• N8N_RUNNERS_AUTH_TOKEN: общий секрет, с помощью которого Task Runner аутентифицируется в n8n.
• N8N_RUNNERS_BROKER_PORT: порт Task Broker, по умолчанию 5679.
• N8N_RUNNERS_BROKER_LISTEN_ADDRESS: адрес, на котором слушает broker, по умолчанию 127.0.0.1, для внешних контейнеров обычно устанавливается на 0.0.0.0.
• N8N_RUNNERS_MAX_CONCURRENCY: количество одновременных задач на runner, по умолчанию 5.
• N8N_RUNNERS_TASK_TIMEOUT: максимальное время выполнения задачи в секундах, по умолчанию 300, после чего runner перезапускается.
• NODE_FUNCTION_ALLOW_BUILTIN и NODE_FUNCTION_ALLOW_EXTERNAL: allowlist разрешенных модулей Node.js в Code-ноде.
• N8N_RUNNERS_STDLIB_ALLOW и N8N_RUNNERS_EXTERNAL_ALLOW: соответствующие allowlist для стандартной библиотеки Python и сторонних модулей.
• N8N_BLOCK_RUNNER_ENV_ACCESS: по умолчанию (true) блокирует доступ Python-кода к переменным окружения runner'а.

Кому стоит переходить

Task Runners в первую очередь касаются самостоятельно размещаемых экземпляров n8n с Docker или Kubernetes, в которых Code-ноды разных команд или с конфиденциальными учетными данными работают в одном экземпляре. Тот, кто эксплуатирует лишь несколько собственных, доверенных workflow, выигрывает меньше, но все же должен иметь в виду внешний режим, поскольку n8n начиная с версии 2.0 помечает переменную N8N_RUNNERS_ENABLED как устаревшую, и старый встроенный режим со временем исчезнет. Если честно, внешний режим означает дополнительные эксплуатационные затраты: еще один контейнер на воркера, подходящую версию образа и собственные allowlist для модулей. Кто хочет избежать этих затрат, пока остается во внутреннем режиме, но должен осознавать, что, по мнению самого n8n, это не является стандартом для продакшена. Для компаний, использующих n8n в качестве центральной платформы автоматизации и придающих значение немецкому суверенитету данных и прослеживаемой эксплуатационной безопасности, осознанное решение в пользу внешнего режима того стоит. NordFlux помогает с настройкой и защитой экземпляров n8n, см. консультации по n8n.

Часто задаваемые вопросы о Task Runners в n8n

В чем разница между внутренним и внешним режимом Task Runner?

Во внутреннем режиме Task Runner работает как дочерний процесс n8n с теми же правами, во внешнем режиме он работает в собственном контейнере и, согласно документации n8n, полностью изолирован от основного процесса. Только внешний режим считается пригодным для продакшена.

Начиная с какой версии n8n работают внешние Task Runners?

Внешние Task Runners согласно документации требуют минимум n8n 1.111.0, кроме того версия образа n8nio/runners должна соответствовать используемой версии n8n.

Нужно ли эксплуатировать отдельный контейнер Task Runner для каждого воркера?

Да, в режиме очереди каждому воркеру нужен собственный sidecar-контейнер. Основным экземплярам, которые сами обрабатывают ручные выполнения, согласно документации также нужен собственный runner, если только не включен OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS.

Блокируют ли Task Runners автоматически доступ к переменным окружения?

Для Python-кода доступ к переменным окружения runner'а через N8N_BLOCK_RUNNER_ENV_ACCESS по умолчанию заблокирован. Для изоляции на уровне операционной системы n8n дополнительно рекомендует такие меры, как профиль AppArmor, предотвращающий доступ к файлам /proc.

Источники: Документация n8n: Set up task runners и Документация n8n: Harden task runners.