Променливи на средата и тайни в Dockup

Променливите на средата и тайните свързват кода на приложението с production конфигурацията, но имат различни изисквания по отношение на разкриването и жизнения цикъл. Публичен базов URL на API може безопасно да се показва в логове; парола за база данни или ключ за подписване — не. Dockup представя това разграничение изрично и маскира съхранените стойности на тайните в изхода за четене.

Промените в конфигурацията също изискват повторно внедряване. Задаването на нова стойност актуализира желаната конфигурация на услугата, но вече работещият процес запазва средата, която е получил при стартиране.

Каква е разликата между променлива и тайна?

И двата типа стойности постъпват в процеса на приложението като данни от средата, но оперативното им обработване е различно.

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

Маркирайте дадена стойност като тайна, когато разкриването ѝ би позволило достъп, представяне за друг потребител, декриптиране, подписване или странично придвижване. „Frontend-ът вече я съдържа“ е знак, че стойността е публична конфигурация, а не тайна.

Не поставяйте тайни в source control, dockup.yaml, примерен изход, екранни снимки, подсказки към агенти или описания на issues. Заличен заместител е по-безопасен от токен, който изглежда реален, защото копираните примери често се превръщат в 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 или друга технология. Услугата трябва да стартира нов контейнер с новата среда.

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

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

dockup deploy production/api --wait --json

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

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

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

Механиката на deployment-а е обяснена в deployments без прекъсване.

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

Агентите за програмиране често обобщават изхода от командите. Инструмент, който връща съхранени тайни, превръща безобидна заявка от типа „покажи текущата конфигурация“ в изтичане на идентификационни данни.

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

Това позволява използването на по-безопасна инструкция:

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

Маскирането на тайни трябва да обхваща и диагностиката. Избягвайте:

printenv

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

Ръководството Производствени ограничения за AI агенти разглежда заедно границите на prompt-ите и инструментите.

Как трябва да се ротират и одитират тайните?

Ротацията е контролирана промяна в production, а не редактиране на текст. Използвайте следната последователност:

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

dockup audit --writes --json

Одитните доказателства трябва да показват, че конфигурацията е променена и след това е извършен deploy. Те не трябва да съдържат стойността на тайната.

При идентификационни данни за база данни вземете предвид connection pool-овете. Съществуващите връзки може да останат удостоверени след ротацията, докато новите връзки използват новата парола. Проверката трябва да включва нова връзка, а не само заявки, обслужени от стар pool.

При API ключове с разрешения запазете генерираната стойност по сигурен начин още при създаването. Съхранете я незабавно в одобрената система за тайни, ограничете я до необходимите разрешения и я ротирайте, без да я възпроизвеждате в изхода от deployment-а.

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

Определете кои стойности принадлежат към всеки източник:

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

Прилагането на dockup.yaml е additive по подразбиране. Обикновените стойности на средата, които не присъстват във файла, се запазват, докато изрично не бъде използван --prune, а тайните никога не се премахват чрез този път. Прегледайте dockup.yaml като code as code, преди да използвате почистване чрез manifest.

Използвайте последователни имена на ключовете в различните среди, но не приемайте, че стойностите са взаимозаменяеми. Staging ключ не трябва да предоставя достъп до production. Preview deployment-ите в проект с private networking получават автоматично създаден read-only потребител на база данни за достъп до production данни; по подразбиране не трябва да наследяват credentials с права за запис.

Реакция при инцидент с изтекла тайна

Ако тайна се появи в транскрипция, log, commit или екранна снимка, последващото ѝ маскиране не е достатъчно. Приемете, че е компрометирана:

1. Оттеглете я или я ротирайте в системата източник.
2. Актуализирайте тайната в Dockup.
3. Направете deploy и проверете резултата.
4. Премахнете разкрития материал, където е възможно.
5. Потърсете злоупотреба в audit и access логовете.
6. Документирайте причината и промяната за предотвратяване на повторение.

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

Контролен списък за преглед на средата

Преди всяко production release проверете дали необходимите ключове съществуват, ключовете за тайни са маркирани като тайни, никоя тайна не е commit-ната, обикновените стойности съответстват на целевата среда и повторното внедряване е част от прегледаната промяна. След това проверете статуса и uptime-а:

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

Мониторингът се изпълнява всяка минута и включва p95 време за отговор. Успешният config deployment все пак трябва да бъде наблюдаван за регресии по време на работа.

За създаване на услуга и първоначална настройка следвайте От Git repository до production.

Валидирайте конфигурацията, без да я разкривате

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

За незадължителна стойност дефинирайте fallback в кода и документирайте дали той е безопасен за production. Безшумните development стойности по подразбиране — локални хостове на бази данни, debug режими, разрешителен CORS или тестови credentials — не трябва да се активират само защото production ключът липсва.

Тази валидация прави променливите на средата и тайните наблюдаеми, без да превръща логовете в инвентар на идентификационни данни.

Обработвайте целенасочено множество услуги и споделени credentials

Копирането на една тайна в няколко услуги създава зависимост при ротация. Предпочитайте credentials, специфични за всяка услуга, когато външната система ги поддържа. Компрометиран token на worker не трябва да предоставя същия достъп като публичния API.

Когато споделената стойност е неизбежна, поддържайте списък с owner и consumers. Ротирайте всички consumers в координиран прозорец и проверявайте новите връзки след всеки redeploy. Не карайте агент да „открие всяка услуга, която вероятно използва този ключ“ въз основа на сходство в имената; използвайте изричен inventory и одитни доказателства.

Private networking може да намали излагането на трафика към базата данни, но не прави credentials ненужни. Вътрешните имена на хостове контролират пътя, а удостоверяването контролира кой може да използва базата данни.

Започнете с проверим deployment

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

Започнете безплатно в app.dockup.ai. Планът Free е $0 на месец, включва начален кредит от $10 и поддържа един workspace, три бази данни и три deployment-а.

Често задавани въпроси

Връща ли Dockup съхранените стойности на тайните?

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

Защо трябва да направя redeploy след промяна на променлива на средата?

Работещият процес е получил средата си при стартиране. Новият deployment създава нов контейнер с актуализираните стойности и го проверява чрез health gate.

Мога ли да поставям тайни в dockup.yaml?

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

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

Използвайте dockup env import с файл във формат .env и точната целева услуга. Използвайте опцията за import --secret само когато всички импортирани стойности са тайни.

Какво да направя, ако тайна е разкрита в log?

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