External secrets в n8n: Vault, AWS, GCP, Azure, 1Password и безопасная работа с токенами ¶

Обновлено: 2026-05-29

Секреты в n8n — это не только API keys в credentials. В production есть несколько уровней: N8N_ENCRYPTION_KEY, переменные окружения, credentials внутри n8n, секреты Docker/Kubernetes и внешние secret stores. Если всё хранить в одном .env на сервере, система работает, но масштабировать доступы, аудит и rotation становится сложно.

External secrets нужны командам, где токены не должны копироваться между людьми и серверами. Но важно понимать ограничение: в n8n эта возможность относится к enterprise/self-hosted сценариям. Для обычного self-hosted контура без enterprise всё равно можно построить аккуратную схему на .env, Docker secrets, Kubernetes Secrets и строгих правах.

Какие уровни секретов есть в n8n ¶

Уровень	Что хранит	Главный риск
`N8N_ENCRYPTION_KEY`	ключ шифрования credentials в базе	потеря key ломает доступ к credentials
Credentials в UI	OAuth, API keys, SMTP, CRM-токены	слишком широкие права токена
`.env` / Docker secrets	инфраструктурные пароли	копии на ноутбуках и в чатах
Vault/Secret Manager	централизованные секреты	неправильный RBAC или отсутствие rotation

Провайдеры внешних секретов ¶

В enterprise-сценариях n8n поддерживает внешние провайдеры вроде 1Password Connect Server, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager и HashiCorp Vault. Выбор зависит не от “что моднее”, а от того, где уже живёт инфраструктура и кто отвечает за аудит доступа.

Провайдер	Когда удобен	Что проверить
HashiCorp Vault	self-hosted/enterprise контур	policies, tokens, audit log, HA
AWS Secrets Manager	инфраструктура в AWS	IAM role, region, rotation policy
GCP Secret Manager	GCP/Yandex-like подходы через сервисные аккаунты не заменяют GCP	service account permissions
Azure Key Vault	Microsoft/Azure окружение	managed identity, access policies
1Password	команда уже хранит секреты в 1Password	Connect Server, vault permissions

Минимальная схема без enterprise ¶

Если external secrets недоступны, сделайте аккуратный baseline:

N8N_ENCRYPTION_KEY=long-random-value-keep-it-forever
POSTGRES_PASSWORD=replace-with-strong-password
REDIS_PASSWORD=replace-with-strong-password
N8N_BASIC_AUTH_USER=admin
N8N_BASIC_AUTH_PASSWORD=replace-with-strong-password

не храните .env в публичном Git;
ограничьте доступ к серверу по SSH;
делайте backup .env вместе с backup БД, но храните отдельно от сервера;
создавайте API tokens с минимальными правами: read-only там, где не нужна запись;
разделяйте dev/staging/prod токены.

Rotation: как менять токены без простоя ¶

Создайте новый token в целевом сервисе, не удаляя старый.
Добавьте новый credential в n8n и переведите один workflow.
Прогоните smoke-test на тестовом payload.
Переведите остальные workflows.
Отключите старый token и проверьте error workflow.
Запишите дату rotation и владельца токена в внутренний реестр.

Не меняйте сразу все токены ночью “на всякий случай”. При ошибке будет непонятно, какой workflow сломался первым.

Как именовать credentials ¶

bitrix24-prod-webhook-write-leads
amocrm-prod-oauth-deals-readwrite
yookassa-prod-webhook-read-events
dadata-prod-api-suggest-clean
google-sheets-prod-service-account-reports

Имя должно отвечать на три вопроса: сервис, окружение, права. Тогда через полгода будет ясно, какой credential можно отключить, а какой обслуживает production.

Что нельзя делать ¶

вставлять токены прямо в Code node или prompt AI Agent;
передавать секреты в Telegram/Slack-алертах;
использовать один админский токен для всех workflows;
копировать production credentials в тестовое окружение;
потерять N8N_ENCRYPTION_KEY при переезде на другой сервер.

Smoke-test секретов ¶

Проверка	Как понять, что всё нормально
перезапуск n8n	credentials открываются и тестируются
worker в queue mode	worker использует тот же encryption key
backup/restore	на чистом окружении credentials не сломались
rotation одного токена	старый token отключён, workflow работает на новом

Связанные инструкции ¶

Операционный runbook для self-hosted ¶

Для темы «External secrets в n8n» важно разделять настройку и эксплуатацию. Настройка отвечает на вопрос “запустилось ли”, эксплуатация — “сможем ли мы восстановиться, обновиться и расследовать инцидент без потери credentials и execution history”.

Перед изменениями проверьте бэкап базы, значение N8N_ENCRYPTION_KEY, состояние volume, логи web-процесса и worker-процесса. Главный риск — поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key.

Слой	Что зафиксировать	Зачем
Вход	состояние контейнеров, очередь, переменные окружения, volume и последние строки логов	позволяет повторить проблему без доступа к production-секретам
Контроль	restart_count, memory_usage, queue_depth, worker_concurrency, failed_executions	показывает деградацию раньше, чем пользователи начинают писать в поддержку
Безопасность	поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key	снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
Готовность	есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «External secrets в n8n»	делает статью пригодной для runbook, а не только для чтения

Пример безопасного входного контракта ¶

docker compose ps
docker compose logs --tail=200 n8n
docker compose logs --tail=200 n8n-worker
printenv | grep -E 'N8N_|WEBHOOK_|DB_|QUEUE_'
# перед изменениями: backup базы + проверка N8N_ENCRYPTION_KEY

Критерий готовности ¶

есть свежий backup базы и проверено значение N8N_ENCRYPTION_KEY
web, worker, queue и database используют согласованные переменные окружения
после изменения проверены логи, healthcheck и запуск критичных workflow
записан rollback-план с командами и ответственным

Практический контекст для внедрения ¶

Эта страница полезна не как абстрактная справка, а как рабочая инструкция под эксплуатацию self-hosted n8n по теме «External secrets в n8n: Vault, AWS, GCP, Azure, 1Password и безопасная работа с токенами | Nodbot»: окружение, секреты, обновления, backup и мониторинг. Перед изменением workflow зафиксируйте источник события: входные данные по теме external secrets: webhook, schedule, ручной запуск или событие внешнего сервиса. Так проще отделить ошибку данных от ошибки настройки n8n и не превратить исправление в набор случайных правок.

Минимальная проверка перед публикацией workflow: один happy path, один пустой payload, один повтор события и одна ошибка внешнего сервиса. Для мониторинга используйте successful executions, skipped items, retry count, error branch usage; эти показатели быстро покажут, что сценарий работает иначе, чем ожидалось.