Переменные окружения и секреты в Dockup

Переменные окружения и секреты связывают код приложения с production-конфигурацией, но для них действуют разные требования к раскрытию и жизненному циклу. Базовый URL публичного API можно безопасно показывать в логах, а пароль базы данных или ключ подписи — нельзя. Dockup явно разделяет эти понятия и маскирует сохранённые значения секретов в выводе команд чтения.

Изменения конфигурации также требуют повторного развёртывания. Установка нового значения обновляет целевую конфигурацию сервиса, но уже запущенный процесс продолжает использовать окружение, полученное при старте.

В чём разница между переменной и секретом?

Оба значения поступают в процесс приложения как данные окружения, но обрабатываются по-разному.

Тип	Пример	Может отображаться в выводе команд чтения?	Рекомендуемый способ обработки
Обычная переменная	NODE_ENV=production	Да	Конфигурация, доступная для проверки
Обычная переменная	PUBLIC_API_URL=https://...	Да	Может храниться в dockup.yaml
Секрет	DATABASE_URL=postgres://...	Значение не сохраняется в выводе	Команда для работы с секретами или CI-хранилище
Секрет	JWT_SIGNING_KEY=...	Значение не сохраняется в выводе	Ротация и ограничение доступа
Секрет	DOCKUP_TOKEN=...	Никогда не хранить как конфигурацию приложения без необходимости	Авторизация на уровне процесса

Помечайте значение как секрет, если его раскрытие может предоставить доступ, позволить выдать себя за другого пользователя, расшифровать данные, подписать их или выполнить lateral movement. Если значение «уже есть во frontend», это признак публичной конфигурации, а не секрета.

Не добавляйте секреты в систему контроля версий, dockup.yaml, примеры вывода, скриншоты, промпты агентов или описания issue. Замаскированный placeholder безопаснее похожего на настоящий токена: скопированные примеры часто становятся частью production-практики.

Как задавать и проверять конфигурацию окружения?

Выведите текущие ключи для точной целевой среды:

dockup env list -s production/api --json

Ответ содержит каждый ключ, информацию о том, является ли он секретом, и значение только в том случае, если оно не защищено.

Задайте обычную переменную:

dockup env set NODE_ENV=production \
  -s production/api \
  --json

Задайте секрет из текущего окружения shell:

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

Удалите устаревшее значение:

dockup env remove OLD_FEATURE_FLAG \
  -s production/api \
  --json

Импортируйте значения из файла в формате .env:

dockup env import .env.production \
  -s production/api \
  --json

Используйте --secret при импорте только в том случае, если все импортируемые значения должны считаться секретами. Смешанные файлы сложнее проверять; они часто приводят либо к чрезмерной классификации безобидной конфигурации как секретной, либо к недостаточной защите учётных данных. По возможности разделяйте такие значения.

Полный список доступных команд поддерживается в справочнике Dockup CLI.

Почему после изменения конфигурации требуется повторное развёртывание?

Переменные окружения считываются при запуске процесса. Обновление конфигурации платформы не изменяет память уже работающего процесса Node.js, Python, Go или другого runtime. Сервис должен запустить новый контейнер с новым окружением.

Правильная последовательность:

dockup env set FEATURE_FLAG=on \
  -s production/api \
  --json

dockup deploy production/api --wait --json

Параметр --wait позволяет проверить второй шаг. Тайм-аут по умолчанию составляет 900 секунд, код завершения 0 означает успех, а при ошибках возвращается ненулевой код со структурированными кодами ошибок.

Процесс blue-green deployment без простоя в Dockup запускает новую версию, применяет health gate и только после этого переключает трафик. Это позволяет не перезапускать текущий контейнер на месте с непроверенной конфигурацией.

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

Механика deployment описана в разделе развёртывания без простоя.

Как маскирование секретов снижает риски для агентов?

Coding agents часто обобщают вывод команд. Инструмент, возвращающий сохранённые секреты, превращает безобидный запрос «покажи текущую конфигурацию» в раскрытие учётных данных.

Dockup маскирует значения секретов. Агент видит, что DATABASE_URL существует и помечен как секрет, но не может прочитать сохранённую строку подключения. Он может заменить значение, если пользователь передаст новое через защищённое окружение.

Это позволяет использовать более безопасную инструкцию:

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

Маскирование секретов должно распространяться и на диагностику. Не используйте:

printenv

в транскрипте агента, даже несмотря на то, что команда PRO exec может выполнять разовые команды внутри контейнера. Вместо этого используйте целевую проверку приложения, которая сообщает о наличии значения, его примерном размере или успешности подключения, не раскрывая само значение.

Руководство защитные меры для AI-агентов в production рассматривает границы промптов и инструментов вместе.

Как выполнять ротацию секретов и проводить аудит?

Ротация — это контролируемое production-изменение, а не редактирование текста. Используйте следующую последовательность:

1. Создайте или получите новые учётные данные в системе-владельце.
2. Сохраните их в одобренном окружении CI или оператора.
3. Задайте новый секрет в Dockup, не выводя его значение.
4. Выполните deployment с --wait.
5. Проверьте состояние и работу приложения.
6. Отзовите старые учётные данные после активации новой версии.
7. Проверьте audit log Dockup.
8. Зафиксируйте дату ротации и владельца, но не записывайте значение.

dockup audit --writes --json

Аудит должен подтверждать, что конфигурация была изменена и после этого выполнен deployment. Значение секрета не должно в нём присутствовать.

При работе с учётными данными базы данных учитывайте connection pools. Уже существующие подключения могут оставаться авторизованными после ротации, тогда как новые подключения будут использовать новый пароль. Проверка должна включать новое подключение, а не только запросы, обслуженные старым pool.

Для API-ключей с разрешениями безопасно сохраните сгенерированное значение в момент создания. Немедленно поместите его в одобренную систему хранения секретов, ограничьте необходимыми разрешениями и выполняйте ротацию, не воспроизводя значение в выводе deployment.

Какая политика конфигурации предотвращает drift?

Определите, какие значения должны храниться в каждом источнике:

Источник	Подходящее содержимое
Код репозитория	Значения по умолчанию, не зависящие от окружения
dockup.yaml	Проверяемая обычная конфигурация deployment
Секретные переменные Dockup	Учётные данные runtime
CI secret store	Токен deployment и значения для управляемой ротации
Вывод управляемой базы данных	Данные подключения, передаваемые потребляющему сервису
Локальный .env	Значения только для разработчика, исключённые из Git

Применение dockup.yaml по умолчанию выполняется аддитивно. Обычные значения окружения, которых нет в файле, сохраняются до явного использования --prune, а секреты этим способом никогда не удаляются. Перед внедрением очистки manifest ознакомьтесь с разделом dockup.yaml как config as code.

Используйте одинаковые имена ключей в разных окружениях, но не считайте значения взаимозаменяемыми. Staging-ключ не должен предоставлять доступ к production. Preview deployments в проекте с private networking получают автоматически созданного пользователя базы данных с доступом только для чтения к production-данным; по умолчанию им не следует наследовать права на запись.

Реагирование на инцидент с утёкшим секретом

Если секрет появился в транскрипте, логе, commit или на скриншоте, одного последующего маскирования недостаточно. Считайте его скомпрометированным:

1. Отзовите или ротируйте его в исходной системе.
2. Обновите секрет в Dockup.
3. Выполните redeploy и проверьте результат.
4. По возможности удалите раскрытые материалы.
5. Проверьте audit log и access log на предмет злоупотреблений.
6. Зафиксируйте причину и изменение, предотвращающее повторение инцидента.

Переписывание истории Git может снизить вероятность дальнейшего обнаружения, но не доказывает, что скопированные учётные данные исчезли. Отзыв секрета — решающее действие.

Чек-лист проверки окружения

Перед каждым production-релизом убедитесь, что необходимые ключи существуют, ключи секретов помечены как секреты, ни один секрет не добавлен в commit, обычные значения соответствуют целевому окружению, а redeploy включён в план изменения. Затем проверьте статус и uptime:

dockup status production/api --json
dockup uptime production/api --hours 24 --json

Мониторинг выполняется каждую минуту и включает p95 response time. Даже успешный deployment конфигурации следует наблюдать на предмет runtime-регрессий.

Для создания сервиса и первоначальной настройки воспользуйтесь руководством от Git-репозитория до production.

Проверяйте конфигурацию, не раскрывая её

Приложения должны явно завершаться с ошибкой, если отсутствует обязательный ключ, но диагностика не должна выводить его значение. Проверка при старте может сообщить список вроде missing: ["DATABASE_URL"] или invalid format: ["PUBLIC_URL"], а затем завершиться с ненулевым кодом.

Для необязательного значения задайте fallback в коде и задокументируйте, безопасен ли он в production. Беззвучные development defaults — локальные хосты баз данных, debug-режимы, разрешительный CORS или тестовые учётные данные — не должны активироваться только потому, что production-ключ отсутствует.

Такая проверка делает переменные окружения и секреты наблюдаемыми, но не превращает логи в каталог учётных данных.

Осознанно работайте с несколькими сервисами и общими учётными данными

Копирование одного секрета в несколько сервисов создаёт зависимость при ротации. По возможности используйте отдельные учётные данные для каждого сервиса. Скомпрометированный токен worker не должен предоставлять такой же доступ, как публичный API.

Если общего значения не избежать, ведите список владельцев и потребителей. Выполняйте ротацию всех потребителей в согласованное окно и после каждого redeploy проверяйте новые подключения. Не просите агента «найти каждый сервис, который, вероятно, использует этот ключ» на основе похожих имён; используйте явный inventory и данные аудита.

Private networking может уменьшить раскрытие трафика базы данных, но не отменяет необходимость в учётных данных. Внутренние hostname определяют маршрут, а authentication — кто может использовать базу данных.

Начните с проверяемого deployment

Классифицируйте каждый ключ до его установки, убедитесь, что чтение секретов маскируется, и включите необходимый redeploy в то же изменение, которое проходит проверку.

Начните бесплатно на app.dockup.ai. Тариф Free стоит $0 в месяц, включает стартовый кредит $10 и поддерживает один workspace, три базы данных и три deployment.

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

Возвращает ли Dockup сохранённые значения секретов?

Нет. Значения секретов маскируются в выводе команд чтения. Ключи и маркеры секретов остаются видимыми, чтобы операторы могли проверить наличие необходимой конфигурации.

Почему после изменения переменной окружения нужно выполнять redeploy?

Запущенный процесс получил своё окружение при старте. Новый deployment создаёт новый контейнер с обновлёнными значениями и проверяет его через health gate.

Можно ли хранить секреты в dockup.yaml?

Нет. Используйте dockup.yaml для обычной конфигурации, доступной для проверки, а для учётных данных — команды работы с секретами или инъекцию секретов через CI.

Как импортировать несколько переменных окружения?

Используйте dockup env import с файлом в формате .env и точной целевой службой. Применяйте опцию import --secret только в том случае, если все импортируемые значения являются секретами.

Что делать, если секрет попал в лог?

Немедленно отзовите или ротируйте его, обновите секрет в Dockup, выполните redeploy, проверьте access log и исправьте процесс, из-за которого произошло раскрытие.