N8n credentials

N8n Credentials: Полное руководство по управлению учетными данными

В N8n credentials (учетные данные) представляют собой централизованный и безопасный механизм для хранения и многократного использования конфиденциальной информации, необходимой для аутентификации в различных сервисах, API и базах данных. Это ключевой компонент платформы автоматизации, обеспечивающий безопасность, повторное использование и удобство управления секретами. В отличие от жесткого кодирования чувствительных данных в узлах, учетные данные хранятся отдельно, что позволяет обновлять их в одном месте и безопасно делиться рабочими процессами, не раскрывая пароли, токены или ключи.

Архитектура и типы учетных данных

Учетные данные в N8n строго типизированы. Каждый тип соответствует конкретному сервису или протоколу и имеет предопределенную схему полей. Это обеспечивает валидацию данных и корректное их использование соответствующими узлами. Все учетные данные шифруются с использованием алгоритма AES-256-GCM перед сохранением в базе данных N8n. Главный ключ шифрования (секрет) определяется переменной окружения N8N_ENCRYPTION_KEY. Без этого ключа расшифровать данные невозможно.

Существуют сотни различных типов учетных данных, которые можно классифицировать по категориям:

API Keys & Tokens: Учетные данные для сервисов вроде OpenAI, GitHub, Slack, Telegram, SendGrid. Обычно содержат одно или несколько полей для ключей API, токенов доступа (Access Token) или токенов обновления (Refresh Token).
Базы данных: Подключение к SQL и NoSQL СУБД: PostgreSQL, MySQL, MongoDB, Redis, Microsoft SQL Server. Содержат поля для хоста, порта, пользователя, пароля и имени базы данных.
Протоколы прикладного уровня: FTP/SFTP, IMAP/SMTP, SSH. Используются для передачи файлов и электронной почты.
OAuth: Поддержка OAuth 1.0 и OAuth 2.0 для таких сервисов, как Google, Twitter, Microsoft 365. N8n может управлять процессом получения и обновления токенов.
Облачные платформы: AWS, Google Cloud, Azure. Часто используют пару Access Key ID и Secret Access Key.

Жизненный цикл учетных данных: Создание, использование и управление

Создание и сохранение

Учетные данные создаются через интерфейс N8n. При добавлении узла, требующего аутентификации, появляется кнопка «Create New Credential». После выбора типа открывается форма с полями, специфичными для этого типа. Заполнив поля, пользователь нажимает «Save». Данные шифруются и сохраняются в базе данных N8n, ассоциируясь с текущим пользователем (в облачной или корпоративной версии) или с экземпляром (в self-hosted).

Использование в рабочих процессах

После создания учетные данные можно выбирать в любом узле, который поддерживает данный тип. Узел ссылается на учетную запись по ее имени, а не хранит фактические данные. Это позволяет:

Использовать одни и те же учетные данные в нескольких узлах и рабочих процессах.
Обновить пароль или токен один раз в центральном хранилище, и изменение автоматически применится ко всем связанным рабочим процессам.
Делиться рабочим процессом (экспортировать его как JSON), не раскрывая секреты — они не включаются в экспорт.

Управление и безопасность

Все сохраненные учетные данные доступны для управления в разделе «Credentials» под аватаркой пользователя (в левом боковом меню). Здесь можно просматривать, редактировать, переименовывать и удалять учетные записи. Важные аспекты безопасности:

Шифрование при хранении: Все секреты зашифрованы в БД.
Отсутствие отображения секретов: В интерфейсе пароли и ключи отображаются как скрытый текст.
Изоляция: В N8n Cloud учетные данные изолированы между workspace и пользователями в соответствии с правами доступа.
Переменные окружения: Альтернативный способ хранения секретов — через переменные окружения, на которые можно ссылаться в полях учетных данных с помощью {{env.VARIABLE_NAME}}.

Специальные типы и продвинутые сценарии

OAuth 2.0 и управление токенами

N8n выступает в роли OAuth-клиента. Для настройки необходимо зарегистрировать приложение в целевом сервисе (например, Google Cloud Console), получить Client ID и Client Secret, и ввести их в соответствующие поля типа учетных данных. При первой аутентификации N8n перенаправит пользователя на страницу авторизации сервиса. После согласия N8n получит и сохранит access token и refresh token. Платформа может автоматически обновлять access token по истечении срока его действия, используя refresh token, что критически важно для долгоживущих автоматизаций.

Учетные данные с несколькими параметрами

Некоторые типы, например для баз данных, содержат множество полей. N8n позволяет создавать несколько наборов учетных данных для одного типа, что удобно для подключения к разным экземплярам (продакшен, тестирование, разработка) или с разными правами доступа.

Общие (Shared) и персональные учетные данные

В корпоративной и облачной версиях N8n реализована система управления доступом. Администраторы или владельцы workspace могут создавать общие учетные данные, доступные для выбора всем членам команды, что обеспечивает согласованность и безопасность. Персональные учетные данные видны и editable только их создателю.

Сравнение методов хранения секретов в N8n

Метод	Место хранения	Безопасность	Удобство	Идеальный случай использования
Встроенные Credentials	База данных N8n (зашифрована)	Высокая. Зависит от сложности N8N_ENCRYPTION_KEY и безопасности сервера.	Очень высокое. Интеграция в UI, простое управление.	Большинство сценариев, особенно в self-hosted окружении с одним пользователем или доверенной командой.
Переменные окружения + плейсхолдеры	Файл .env или переменные процесса на сервере.	Очень высокая. Секреты никогда не попадают в БД N8n. Управляются на уровне инфраструктуры.	Среднее. Требует настройки сервера, усложняет редактирование через UI.	Критически важные секреты (мастер-ключи БД), развертывание в Docker/Kubernetes, соблюдение строгих compliance-требований.
External Secrets Managers (HashiCorp Vault)	Специализированное внешнее хранилище.	Наивысшая. Централизованное управление, аудит, ротация.	Низкое. Требует сложной настройки интеграции через код или плагины.	Крупные корпоративные развертывания N8n с развитой DevOps-культурой.

Практические рекомендации и лучшие практики

Используйте осмысленные имена: Имя учетной записи должно четко указывать на сервис и контекст (например, «PostgreSQL-Prod-MainDB», «Slack-Bot-Notifications»).
Минимизируйте права доступа: Предоставляйте учетным данным только минимально необходимые привилегии в целевых системах (принцип наименьших привилегий).
Регулярно обновляйте секреты: Планируйте периодическую ротацию ключей API и паролей. В N8n это делается редактированием существующей учетной записи.
Резервное копирование ключа шифрования: Без N8N_ENCRYPTION_KEY все сохраненные учетные данные станут нечитаемыми. Храните его в надежном месте.
Аудит использования: В корпоративной версии отслеживайте, какие учетные данные и какими пользователями используются в рабочих процессах.
Не используйте учетные данные владельца в автоматизациях: Для сервисов, где это возможно, создавайте отдельные служебные аккаунты или учетные записи ботов с ограниченными правами.

Интеграция с внешними системами и CI/CD

При развертывании N8n через Docker Compose или Kubernetes секреты часто выносятся в виде переменных окружения. Это позволяет использовать один и тот же образ контейнера для разных сред (stage, prod), подставляя разные наборы секретов. Экспортированные рабочие процессы (JSON-файлы) содержат только ссылки на имена учетных данных. При импорте в новом окружении N8n будет искать учетные данные с такими же именами. Это требует предварительного создания соответствующих учетных записей в целевом экземпляре N8n, что можно автоматизировать с помощью скриптов или инструментов управления инфраструктурой.

Ответы на часто задаваемые вопросы (FAQ)

Где физически хранятся мои пароли и ключи в N8n?

Они хранятся в зашифрованном виде (AES-256-GCM) в базе данных, которую использует ваш экземпляр N8n (по умолчанию SQLite, но может быть PostgreSQL, MySQL и др.). Ключ шифрования задается переменной окружения N8N_ENCRYPTION_KEY и никогда не сохраняется в БД.

Можно ли импортировать/экспортировать сами учетные данные?

Нет, напрямую через стандартный UI — нельзя. Это сделано в целях безопасности. При экспорте рабочего процесса учетные данные не включаются в JSON-файл. Для переноса учетных данных между экземплярами необходимо воссоздать их вручную в новом окружении или использовать переменные окружения для хранения секретов, которые будут одинаковыми в разных средах.

Что произойдет, если я потеряю N8N_ENCRYPTION_KEY?

Все сохраненные учетные данные станут нерасшифровываемыми и бесполезными. Их необходимо будет заново создать. Рабочие процессы, ссылающиеся на эти учетные данные, перестанут работать. Поэтому резервное копирование этого ключа критически важно.

Как использовать одну учетную запись для разных пользователей в команде?

В планах N8n Professional и Enterprise есть функция общих (Shared) учетных данных. Пользователь с соответствующими правами (например, владелец workspace) может создать учетную запись и сделать ее доступной для выбора другими членами workspace. В бесплатной self-hosted версии такой функциональности нет — учетные данные привязаны к пользователю, создавшему их.

Можно ли использовать N8n Credentials для хранения любых произвольных секретов?

Нет, напрямую — нельзя. Учетные данные строго типизированы под конкретные сервисы и узлы. Для хранения произвольных конфиденциальных данных следует использовать системные переменные (Settings -> Variables) или, что более безопасно, внешние переменные окружения, на которые можно ссылаться в полях узлов.

Как N8n обрабатывает OAuth Refresh Token?

При настройке OAuth 2.0 учетных данных N8n, после первоначальной аутентификации, сохраняет как Access Token, так и Refresh Token. Когда Access Token истекает, узел, выполняющий запрос, автоматически попытается использовать Refresh Token для получения нового Access Token. Этот процесс происходит «под капотом», если сервис поддерживает стандартный OAuth 2.0 flow с refresh token.

Безопасно ли запускать N8n с учетными данными в облаке (n8n.cloud)?

N8n Cloud использует те же принципы шифрования для хранения учетных данных. Безопасность зависит от мер, применяемых облачным провайдером (AWS). Рекомендуется использовать принцип наименьших привилегий для облачных учетных записей и, по возможности, включать двухфакторную аутентификацию для вашей учетной записи N8n Cloud. Для сверхкритичных данных рассмотрите self-hosted развертывание в вашем контролируемом окружении.