Змінні середовища та секрети в Dockup

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

Зміни конфігурації також потребують повторного розгортання. Встановлення нового значення оновлює бажану конфігурацію сервісу, але вже запущений процес продовжує використовувати середовище, отримане під час запуску.

У чому різниця між змінною та секретом?

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

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

Позначайте значення як секрет, якщо його розкриття може надати доступ, дозволити видати себе за іншу особу, розшифрувати дані, підписувати їх або переміщуватися мережею. Фраза «фронтенд і так уже його містить» означає, що це публічна конфігурація, а не секрет.

Не зберігайте секрети в source control, dockup.yaml, прикладах виведення, скриншотах, промптах агентів або описах issues. Замаскований placeholder безпечніший за токен, схожий на справжній, адже скопійовані приклади часто стають production-практикою.

Як задавати конфігурацію середовища та перевіряти її?

Виведіть поточні ключі для точної цілі:

dockup env list -s production/api --json

Відповідь містить кожен ключ, інформацію про те, чи є він секретом, і саме значення, лише якщо воно не захищене.

Задайте звичайну змінну:

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

Задайте секрет із поточного shell environment:

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 або іншого процесу. Сервіс має запустити новий container із новим середовищем.

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

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

dockup deploy production/api --wait --json

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

Процес blue-green у Dockup без простою запускає нову версію, застосовує health gate і лише потім перемикає трафік. Це запобігає перезапуску поточного container на місці з неперевіреною конфігурацією.

Якщо ротація секрету змінює і producer, і consumer, сплануйте сумісність. Ротація пароля до бази даних до того, як застосунок отримає нове значення, може спричинити збій. Використовуйте період перекриття, підтримку двох ключів або впорядковану зміну, якщо зовнішня система це дозволяє.

Механіку розгортання описано в матеріалі розгортання без простою.

Як маскування секретів зменшує ризики для агентів?

Coding agents часто підсумовують виведення команд. Інструмент, який повертає збережені секрети, перетворює нешкідливий запит «покажи поточну конфігурацію» на розкриття облікових даних.

Dockup маскує значення секретів. Агент може побачити, що DATABASE_URL існує та позначений як секрет, але не може прочитати збережений connection string. Він може замінити значення, коли користувач надає нове через безпечне середовище.

Це дає змогу використовувати безпечнішу інструкцію:

Підтвердь, що необхідні ключі секретів існують, але ніколи не виводь їхні значення. Якщо значення потрібно змінити, зчитай його лише з environment процесу та поверни назву ключа, а не секрет.

Маскування секретів має поширюватися й на діагностику. Уникайте:

printenv

у transcript агента, навіть якщо команда PRO exec може виконувати одноразові команди в container. Натомість використовуйте цільову перевірку застосунку, яка повідомляє про наявність, клас довжини або успішність підключення, не розкриваючи значення.

У посібнику виробничі обмеження для AI-агентів промпти й межі інструментів розглянуто разом.

Як ротувати секрети та проводити аудит?

Ротація — це контрольована production-зміна, а не редагування тексту. Використовуйте таку послідовність:

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

dockup audit --writes --json

Аудиторські дані мають показувати, що конфігурацію змінено, а після цього виконано deployment. Вони не повинні містити значення секрету.

Для облікових даних баз даних враховуйте connection pools. Уже встановлені з’єднання можуть залишатися автентифікованими після ротації, тоді як нові з’єднання використовуватимуть новий пароль. Перевірка має охоплювати нове з’єднання, а не лише запити, які обслуговує старий pool.

Для API keys із дозволами безпечно отримайте згенероване значення під час створення. Негайно збережіть його в схваленій системі секретів, обмежте необхідними дозволами й ротуват�� його, не відтворюючи у виведенні deployment.

Яка політика конфігурації запобігає drift?

Визначте, які значення належать до кожного джерела:

Джерело	Відповідний вміст
Код repository	Значення за замовчуванням, що не залежать від середовища
dockup.yaml	Конфігурація deployment у відкритому вигляді, доступна для перевірки
Secret variables Dockup	Runtime credentials
CI secret store	Deployment token і значення, що вводяться під час ротації
Виведення managed database	Дані підключення, передані сервісу-споживачу
Локальний .env	Значення лише для розробника, виключені з Git

Застосування dockup.yaml за замовчуванням є additive. Звичайні значення середовища, яких немає у файлі, зберігаються, доки явно не використано --prune, а секрети цим шляхом ніколи не видаляються. Перед використанням очищення manifest ознайомтеся з матеріалом dockup.yaml як config as code.

Використовуйте узгоджені назви ключів у різних середовищах, але не вважайте значення взаємозамінними. Staging key не повинен надавати доступ до production. Preview deployments у проєкті з private networking отримують автоматично створеного read-only користувача бази даних для доступу до production-даних; за замовчуванням вони не повинні успадковувати write credentials.

Реагування на інцидент із витоком секрету

Якщо секрет з’явився в transcript, log, commit або screenshot, простого подальшого маскування недостатньо. Вважайте його скомпрометованим:

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

Переписування Git history може зменшити ймовірність подальшого виявлення, але не доводить, що скопійовані облікові дані зникли. Відкликання — вирішальна дія.

Чекліст перевірки середовища

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

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

Моніторинг запускається щохвилини та містить p95 response time. Успішне розгортання конфігурації все одно потрібно спостерігати на предмет runtime-регресій.

Для створення сервісу й початкового налаштування дотримуйтеся інструкції від Git repository до production.

Перевіряйте конфігурацію, не розкриваючи її

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

Для необов’язкового значення визначте fallback у коді та задокументуйте, чи безпечний він у production. Непомітні development defaults — локальні host-и баз даних, debug modes, permissive CORS або test credentials — не повинні активуватися лише через відсутність production-ключа.

Така перевірка робить змінні середовища та секрети спостережуваними, не перетворюючи логи на inventory облікових даних.

Обдумано працюйте з кількома сервісами та спільними обліковими даними

Копіювання одного секрету в кілька сервісів створює залежність під час ротації. Якщо зовнішня система підтримує це, надавайте перевагу credentials, специфічним для кожного сервісу. Скомпрометований worker token не повинен надавати такий самий доступ, як public API.

Коли спільне значення неминуче, підтримуйте список відповідального та споживачів. Ротуйте всіх споживачів у скоординоване вікно й перевіряйте нові з’єднання після кожного redeploy. Не просіть агента «знайти кожен сервіс, який, імовірно, використовує цей ключ» на основі схожості назв; використовуйте явний inventory і аудиторські дані.

Private networking може зменшити exposure database traffic, але не усуває потребу в credentials. Internal hostnames визначають шлях, а authentication — хто може використовувати базу даних.

Почніть із deployment, який можна перевірити

Класифікуйте кожен ключ до його встановлення, перевірте, що читання секретів маскується, і включіть необхідний redeploy до тієї самої зміни, що пройшла review.

Почніть безкоштовно на app.dockup.ai. План Free коштує $0 на місяць, містить стартовий кредит $10 і підтримує один workspace, три databases та три deployments.

FAQ

Чи повертає Dockup збережені значення секретів?

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

Чому після зміни змінної середовища потрібно виконати redeploy?

Запущений процес отримав своє середовище під час запуску. Новий deployment створює новий container з оновленими значеннями та перевіряє його через health gate.

Чи можна зберігати секрети в dockup.yaml?

Ні. Використовуйте dockup.yaml для звичайної конфігурації, яку можна перевірити, а для credentials — secret environment commands або CI secret injection.

Як імпортувати кілька змінних середовища?

Використовуйте dockup env import із файлом у форматі .env і точною ціллю сервісу. Опцію import --secret використовуйте лише тоді, коли всі імпортовані значення є секретами.

Що робити, якщо секрет розкрито в логу?

Негайно відкличте або ротируйте його, оновіть секрет Dockup, виконайте redeploy, перевірте access logs і виправте процес, який спричинив розкриття.