Пользовательский код нельзя принимать только потому, что workflow успешно обработал обычную заявку. До рабочего запуска нужно установить, зачем нужен каждый фрагмент кода, какие данные и ресурсы ему доступны и что произойдёт при запрещённом действии.
Решение состоит из трёх частей: описать границы кода, настроить ограничения среды и проверить фактическое поведение. Отдельный контейнер или запрет одного узла помогает лишь в своей области и не доказывает безопасность всей установки.
Когда пользовательский код действительно нужен
Для каждой операции выберите один из трёх вариантов: оставить Code node, собрать действие из стандартных узлов или вынести его в отдельный контролируемый сервис. Общий запрет на Code node не нужен, но удобство написания кода само по себе не обосновывает его допуск.
Перед решением ответьте на пять вопросов:
- Какую рабочую задачу выполняет код?
- Какие данные он получает?
- Какой результат должен вернуть?
- Что workflow делает с результатом дальше?
- К чему приведёт ошибка или неожиданное действие?
Если стандартные узлы дают тот же результат с понятными полномочиями и сопровождением, пользовательский код может оказаться лишним. Если операция требует собственного алгоритма, зафиксируйте его границы до настройки среды.
Составьте паспорт выполнения кода
Паспорт превращает неизвестные возможности Code node в вопросы, которые можно проверить. Не заполняйте пробелы предположениями: доступные языки, библиотеки и способы выполнения зависят от версии, редакции и конфигурации конкретной среды.
| Поле | Что зафиксировать |
|---|---|
| Владелец | Кто отвечает за workflow и принимает остаточный риск |
| Назначение | Какую одну операцию выполняет код |
| Выполнение | Язык и фактический механизм запуска |
| Вход | Источник и минимальный набор передаваемых полей |
| Выход | Схема результата и допустимые ошибки |
| Зависимости | Фактически доступные и необходимые модули |
| Сеть | Нужные адреса, методы и направления обмена |
| Файлы | Пути и допустимые операции чтения или записи |
| Временные данные | Что хранится временно, где и как долго |
| Секреты | Какие учётные данные нужны коду и зачем |
| Внешние действия | Какие записи, сообщения или запросы может создать workflow |
| Последствия ошибки | Максимальный ущерб и способ остановки процесса |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Неизвестное значение записывайте как вопрос обследования: например, «может ли этот runner подключить библиотеку X?» или «доступен ли процессу том Y?». Ответ должен появиться из конфигурации и испытания, а не из предположения о типовой установке.
Разделите функции n8n и требования проекта
Официальная документация n8n подтверждает несколько функций продукта:
- task runners выполняют код из Code node;
- во внешнем режиме runners запускаются в отдельных контейнерах, чтобы изолировать выполнение JavaScript от основного процесса n8n;
- в self-hosted n8n переменная
NODES_EXCLUDEне даёт системе загрузить указанный тип узла; - node type policies управляют доступностью типов узлов для инстанса или проекта.
Эти функции не определяют требования конкретного проекта. Отдельно нужно решить, какие данные разрешено передавать коду, куда он может обращаться по сети, какие секреты и файлы ему доступны, какие зависимости допустимы, с какими правами работает контейнер и как workflow обрабатывает отказ.
Не представляйте эти проектные ограничения как настройки n8n по умолчанию. Их наличие и результат нужно устанавливать для принимаемой среды.
Ограничьте среду task runners
Для self-hosted n8n документация предлагает несколько независимых мер усиления. Их нужно подбирать под архитектуру и проверять после настройки.
| Мера | Что она меняет | Что ещё нужно проверить |
|---|---|---|
| Внешний режим | Запускает task runners в отдельных контейнерах | Сеть, тома, секреты и права контейнеров |
| Distroless-образ | Оставляет приложение и нужные runtime-зависимости без менеджеров пакетов, оболочек и лишних утилит | Совместимость workflow и используемый тег образа |
Пользователь nobody | Не даёт процессу работать с правами root; документация указывает UID и GID 65532 | Права на необходимые каталоги и временные данные |
| Read-only root filesystem | Запрещает изменение корневой файловой системы во время работы | Отдельный минимальный том /tmp и нужный ему размер |
| Профиль AppArmor | Может запретить и журналировать доступ к отдельным файлам /proc | Применение профиля к нужному pod и фактический отказ доступа |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Описанная документацией мера AppArmor касается, в частности, файлов environ и mounts отдельных процессов. Они могут раскрывать переменные окружения и сведения о монтировании. Такой запрет усиливает защиту именно этих путей, но не доказывает защиту всех секретов, файлов и данных среды.
После каждой меры проверяйте не только успешный запуск допустимой операции. Нужны также контролируемый отказ запрещённого действия, запись ошибки в журнале и остановка последующего внешнего действия.
Закройте ненужные типы узлов и альтернативные пути
Сначала составьте перечень механизмов, через которые пользователь workflow способен выполнять код или команды, читать и записывать файлы либо обращаться к внешним системам. Не ограничивайтесь одним Code node.
В self-hosted n8n можно добавить ненужный тип узла в NODES_EXCLUDE. Тогда n8n не загрузит этот тип. Документация приводит Execute Command и Read/Write Files from Disk как примеры узлов, которые можно исключить, но универсального списка для любого проекта нет.
Node type policies доступны в редакции Enterprise для n8n Cloud и self-hosted начиная с n8n 2.45.0. На момент проверки документация помечает механизм как Preview и рекомендует не полагаться на него в production. Поэтому его нельзя выдавать за окончательную производственную границу.
Исключение Code node запрещает конкретный тип узла. Оно не доказывает, что в установке отсутствуют другие способы выполнить пользовательский код или аналогичную операцию. После изменения перечня узлов повторите инвентаризацию доступных путей.
Не путайте доступность узла с границей данных
Запрет типа узла и запрет доступа к сервису — разные меры. Документация node type policies прямо предупреждает: заблокированный узел не перекрывает сам сервис или API. Доступ может сохраниться через HTTP Request, Code node или другой разрешённый механизм.
Поэтому отдельно проектируйте и проверяйте:
- исходящие сетевые направления;
- выдачу секретов конкретному процессу;
- права внешних учётных записей;
- доступные контейнеру тома и файлы;
- минимальный состав полей, передаваемых в Code node;
- действия workflow после ошибки.
Предоставленные источники не подтверждают наличие таких границ в конкретной установке. До испытания нельзя обещать, что один запрет узла остановит сетевой запрос, чтение файла или работу с внешней системой.
Проведите условную приёмку Code node
Ниже — синтетический учебный пример, а не клиентский кейс и не отчёт о выполненном тесте Switch On AI.
Условный workflow получает заявку и передаёт в Code node только телефон и комментарий. Код нормализует телефон и возвращает данные по согласованной схеме. Для этой операции не нужны системные команды, чтение произвольных файлов или обращения к посторонним адресам.
Сначала проверьте допустимый путь: заданные поля поступили в Code node, результат соответствует схеме, а следующий узел получил именно этот результат. Затем проверяйте запрещённые действия, но только при подтверждённой предпосылке и после настройки соответствующего ограничения.
| Испытание | Предпосылка | Применяемая мера | Наблюдаемый критерий |
|---|---|---|---|
| Допустимая нормализация | Зафиксированы язык, режим выполнения, вход и схема выхода | Code node получает только телефон и комментарий | Результат соответствует схеме; последующее согласованное действие получает его без лишних полей |
| Чтение контрольного файла | Подтверждён реальный файловый API или другой путь чтения | Настроено конкретное файловое ограничение | Файл не прочитан; ошибка записана; последующее рабочее действие не началось |
| Контрольная команда | В среде действительно доступен узел или иной механизм выполнения команд | Этот механизм ограничен, например соответствующий тип узла исключён через NODES_EXCLUDE | Узел не загружается или не запускается; ошибка контролируема; внешнего действия нет |
| Запрос на тестовый адрес | Подтверждён исходящий сетевой путь; принимающая сторона подготовлена для испытания | Применено согласованное сетевое правило | На принимающей стороне нет запроса; workflow фиксирует контролируемую ошибку и не продолжает рабочее действие |
| Подключение зависимости | Установлены язык, режим runner и фактическая доступность выбранной зависимости | Зафиксирован минимально допустимый состав зависимостей | Разрешённая зависимость работает в заданном сценарии, а неподтверждённые варианты не считаются доступными |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Все результаты в таблице — ожидаемые до испытания. Не пытайтесь читать файл, выполнять команду или отправлять запрос, пока не подтверждены соответствующий путь и безопасная тестовая среда. Для каждого фактического запуска сохраните вход, конфигурацию, журнал и наблюдаемый результат.
Зафиксируйте приёмку, изменения и ограничения
Решение о запуске должно опираться на протокол, а не на наличие настройки. Зафиксируйте:
- версию и редакцию n8n;
- способ размещения;
- версии workflow и пользовательского кода;
- режим и конфигурацию runner;
- доступные типы узлов;
- подтверждённые зависимости;
- тестовые входы;
- применённые ограничения;
- наблюдаемые результаты и журналы;
- остаточные риски;
- ответственного и его решение.
Повторно проверяйте затронутое поведение после изменения кода, языка, зависимостей, образа, режима runner, доступных узлов, сетевых правил или прав доступа. Общую методику можно сверить с приёмкой автоматизации, а порядок повторных выпусков — с управлением изменениями workflow.
Эта последовательность не доказывает безопасность конкретной установки и не заменяет обследование инфраструктуры. Она помогает принять ограниченное решение: какой код допустить, в какой среде его выполнять и какими наблюдениями подтвердить согласованные границы.
Если нужно подготовить такую приёмку для конкретного workflow, Switch On AI занимается разработкой и внедрением автоматизации. Пришлите схему workflow, перечень узлов, способ размещения n8n и описание пользовательского кода. Мы поможем определить границы выполнения, составить проверочный сценарий и оценить необходимые доработки перед рабочим запуском.
Вопросы по этой задаче
Можно ли запретить именно Code node в self-hosted n8n?
Тип Code node можно добавить в NODES_EXCLUDE, чтобы self-hosted n8n его не загружал. Это не доказывает запрет всех способов выполнения пользовательского кода или аналогичных операций: остальные узлы, пакеты и механизмы нужно инвентаризировать отдельно.
Достаточно ли запустить task runner в отдельном контейнере?
Нет. Отдельный контейнер изолирует выполнение кода от основного процесса n8n, но права процесса, файловая система, временное хранилище, секреты и сетевой доступ требуют отдельной настройки и проверки.
Можно ли использовать node type policies как производственную границу?
Документация помечает node type policies как Preview и рекомендует не полагаться на них в production. Кроме того, политика управляет доступностью типов узлов, но не блокирует сам сервис или API.
Какие модули можно разрешить пользовательскому коду?
Сначала нужно установить язык, версию и редакцию n8n, режим выполнения и фактически доступные зависимости в конкретной среде. Затем фиксируют минимально необходимый состав и проверяют его поведение; универсальный список из предоставленных источников не следует.
Как проверить чтение файла, выполнение команды или сетевой запрос?
Только после подтверждения реального пути и настройки соответствующего ограничения в контролируемой среде. Для испытания заранее задают предпосылку, меру и критерий: действие не выполнено, ошибка записана, а последующая рабочая операция не началась.