Premenné prostredia a secrets v Dockup

Premenné prostredia a secrets prepájajú kód aplikácie s production konfiguráciou, no majú odlišné požiadavky na zverejňovanie a životný cyklus. Verejná base URL API môže byť bezpečná v logoch, heslo do databázy alebo signing key však nie. Dockup tento rozdiel explicitne zachováva a pri čítaní maskuje uložené hodnoty secrets.

Zmeny konfigurácie si zároveň vyžadujú opätovné nasadenie. Nastavením novej hodnoty aktualizujete požadovanú konfiguráciu služby, ale už bežiaci process naďalej používa environment, ktorý dostal pri štarte.

Aký je rozdiel medzi premennou a secretom?

Obe hodnoty vstupujú do application processu ako údaje environmentu, no v prevádzke sa s nimi zaobchádza odlišne.

Typ	Príklad	Môže sa objaviť vo výstupe čítania?	Odporúčané zaobchádzanie
Bežná premenná	NODE_ENV=production	Áno	Konfigurácia vhodná na kontrolu
Bežná premenná	PUBLIC_API_URL=https://...	Áno	Môže byť v dockup.yaml
Secret	DATABASE_URL=postgres://...	Uložená hodnota nie	Secret command alebo CI store
Secret	JWT_SIGNING_KEY=...	Uložená hodnota nie	Rotujte a obmedzte prístup
Secret	DOCKUP_TOKEN=...	Nikdy neukladať ako konfiguráciu aplikácie, pokiaľ to nie je nevyhnutné	Auth na úrovni processu

Hodnotu označte ako secret, ak by jej zverejnenie umožnilo prístup, impersonation, dešifrovanie, signing alebo lateral movement. Tvrdenie „frontend ju už aj tak obsahuje“ je znakom, že ide o verejnú konfiguráciu, nie o secret.

Secrets nevkladajte do source control, dockup.yaml, ukážkového výstupu, screenshotov, promptov pre agentov ani popisov issues. Redacted placeholder je bezpečnejší než realisticky vyzerajúci token, pretože skopírované príklady sa často stanú production praktikou.

Ako nastavíte a skontrolujete konfiguráciu environmentu?

Zoznam aktuálnych kľúčov pre presne určený target:

dockup env list -s production/api --json

Odpoveď obsahuje každý kľúč, informáciu, či ide o secret, a hodnotu iba v prípade, že nie je chránená.

Nastavte bežnú premennú:

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

Nastavte secret z environmentu aktuálneho shellu:

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

Odstráňte zastaranú hodnotu:

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

Hromadne importujte súbor v štýle .env:

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

Pri importe použite --secret iba vtedy, keď sa má každá importovaná hodnota považovať za secret. Zmiešané súbory sa kontrolujú ťažšie a často vedú k nadmernému označovaniu neškodnej konfigurácie alebo naopak k nedostatočnému označovaniu prihlasovacích údajov. Ak je to možné, oddeľte ich.

Presné možnosti príkazov sú uvedené v referencii Dockup CLI.

Prečo je po zmenách konfigurácie potrebné opätovné nasadenie?

Premenné prostredia sa načítavajú pri štarte processu. Aktualizácia konfigurácie platformy nemení pamäť už bežiaceho processu v Node.js, Pythone, Go ani inom runtime. Service sa musí spustiť v novom containery s novým environmentom.

Správny postup je:

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

dockup deploy production/api --wait --json

--wait umožňuje overiť druhý krok. Predvolený timeout je 900 sekúnd, exit 0 znamená úspech a pri zlyhaní sa vráti nenulový kód so štruktúrovanými kódmi.

Dockup pri blue-green procese bez downtime spustí novú verziu, aplikuje health gate a až potom na ňu presmeruje traffic. Vyhnete sa tak reštartovaniu aktuálneho containera na mieste s neoverenou konfiguráciou.

Ak rotácia secretu mení producer aj consumer, naplánujte kompatibilitu. Rotácia hesla do databázy skôr, než aplikácia dostane novú hodnotu, môže spôsobiť výpadok. Použite overlap period, podporu dual-key alebo zmenu v správnom poradí, ak to externý systém umožňuje.

Mechanizmus nasadenia je vysvetlený v článku nasadenia bez downtime.

Ako maskovanie secrets znižuje riziko pre agentov?

Coding agents často sumarizujú výstup príkazov. Nástroj, ktorý vracia uložené secrets, môže z neškodnej požiadavky „zobraz aktuálnu konfiguráciu“ urobiť odhalenie prihlasovacích údajov.

Dockup maskuje hodnoty secrets. Agent vidí, že DATABASE_URL existuje a je označený ako secret, ale nemôže prečítať uložený connection string. Hodnotu môže nahradiť, keď mu používateľ poskytne novú hodnotu prostredníctvom bezpečného environmentu.

To umožňuje bezpečnejšie inštrukcie:

Potvrďte, že požadované kľúče secrets existujú, ale ich hodnoty nikdy nevypisujte. Ak sa hodnota musí zmeniť, načítajte ju iba z process environmentu a vráťte názov kľúča, nie secret.

Maskovanie secrets by sa malo vzťahovať aj na diagnostics. Vyhnite sa:

printenv

v transcripte agenta, hoci príkaz PRO exec dokáže spúšťať jednorazové príkazy v containery. Uprednostnite cielenú kontrolu aplikácie, ktorá bez zverejnenia hodnoty oznámi jej prítomnosť, triedu dĺžky alebo úspešné pripojenie.

Príručka produkčné guardrails pre AI agentov sa venuje hraniciam promptov a nástrojov spoločne.

Ako rotovať a auditovať secrets?

Rotácia je riadená production zmena, nie úprava textu. Použite tento postup:

1. Vytvorte alebo získajte nové prihlasovacie údaje v systéme, ktorý ich vlastní.
2. Uložte ich do schváleného CI alebo operator environmentu.
3. Nastavte nový secret v Dockup bez jeho vypísania.
4. Nasaďte zmenu s --wait.
5. Overte health a správanie aplikácie.
6. Po aktivácii novej verzie odvolajte staré prihlasovacie údaje.
7. Skontrolujte Dockup audit log.
8. Zaznamenajte dátum rotácie a vlastníka, nie však hodnotu.

dockup audit --writes --json

Audit evidence by mala preukázať, že sa konfigurácia zmenila a nasledovalo nasadenie. Nemala by obsahovať hodnotu secretu.

Pri prihlasovacích údajoch do databázy zohľadnite connection pools. Existujúce connections môžu po rotácii zostať autentifikované, zatiaľ čo nové connections použijú nové heslo. Overenie by malo zahŕňať nové pripojenie, nielen requests obslúžené starým poolom.

Pri API keys s permissions bezpečne zachyťte vygenerovanú hodnotu počas vytvárania. Okamžite ju uložte do schváleného secret systému, obmedzte ju na požadované permissions a rotujte ju bez opätovného uvádzania vo výstupe nasadenia.

Aká konfiguračná politika zabraňuje driftu?

Určte, ktoré hodnoty patria do jednotlivých zdrojov:

Zdroj	Vhodný obsah
Repository code	Defaults, ktoré nie sú špecifické pre environment
dockup.yaml	Konfigurácia nasadenia v plain texte vhodná na kontrolu
Dockup secret variables	Runtime credentials
CI secret store	Deployment token a injected rotation values
Managed database output	Connection data odovzdané consuming service
Local .env	Hodnoty iba pre developerov, vylúčené z Gitu

dockup.yaml apply je predvolene additive. Bežné environment values, ktoré nie sú v súbore, zostávajú zachované, kým sa explicitne nepoužije --prune, a secrets sa touto cestou nikdy nepruneujú. Pred zavedením čistenia manifestu si prečítajte dockup.yaml ako config as code.

V rôznych environmentoch používajte konzistentné názvy kľúčov, ale nepredpokladajte, že hodnoty sú zameniteľné. Staging key by nemal poskytovať prístup do production. Preview deployments v projekte s private networkingom dostávajú automaticky vytvoreného read-only database usera na prístup k production dátam; predvolene by nemali preberať write credentials.

Reakcia na incident s uniknutým secretom

Ak sa secret objaví v transcripte, logu, commite alebo screenshote, neskoršie maskovanie nestačí. Považujte ho za kompromitovaný:

1. Odvolajte ho alebo rotujte v zdrojovom systéme.
2. Aktualizujte secret v Dockup.
3. Znovu nasaďte zmenu a overte ju.
4. Ak je to možné, odstráňte zverejnený materiál.
5. Vyhľadajte zneužitie v audit a access logoch.
6. Zdokumentujte príčinu a zmenu, ktorá jej má zabrániť.

Prepísanie histórie Gitu môže znížiť pravdepodobnosť budúceho nájdenia údaja, no nedokáže preukázať, že skopírovaný credential zmizol. Odvolanie je rozhodujúci krok.

Checklist kontroly environmentu

Pred každým production release overte, že požadované kľúče existujú, kľúče secrets sú označené ako secrets, žiadny secret nie je commitnutý, plain values zodpovedajú zamýšľanému environmentu a opätovné nasadenie je súčasťou zmeny. Potom skontrolujte status a uptime:

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

Monitoring sa spúšťa každú minútu a zahŕňa response time p95. Úspešné nasadenie konfigurácie by sa napriek tomu malo sledovať z hľadiska runtime regresií.

Pri vytváraní služby a úvodnom nastavení postupujte podľa článku od Git repository po production.

Validujte konfiguráciu bez jej zverejnenia

Aplikácie by mali pri chýbajúcom povinnom kľúči zlyhať zrozumiteľne, no diagnostics nesmú vypísať jeho hodnotu. Startup check môže oznámiť napríklad zoznam missing: ["DATABASE_URL"] alebo invalid format: ["PUBLIC_URL"] a potom skončiť s nenulovým kódom.

Pri voliteľnej hodnote definujte fallback v kóde a zdokumentujte, či je tento fallback bezpečný v production. Tiché development defaults — lokálne hosty databáz, debug modes, permissive CORS alebo test credentials — by sa nemali aktivovať len preto, že chýbal production key.

Táto validácia robí premenné prostredia a secrets pozorovateľnými bez toho, aby sa logy zmenili na inventár prihlasovacích údajov.

S viacerými službami a zdieľanými credentials zaobchádzajte uvážene

Kopírovanie jedného secretu do viacerých služieb vytvára závislosť pri rotácii. Ak to externý systém podporuje, uprednostnite credentials špecifické pre jednotlivé služby. Kompromitovaný token workera by nemal poskytovať rovnaký prístup ako public API.

Ak sa zdieľanej hodnote nedá vyhnúť, udržiavajte zoznam vlastníkov a consumerov. Rotujte všetkých consumerov v koordinovanom okne a po každom opätovnom nasadení overte nové connections. Nežiadajte agenta, aby z podobnosti názvov „našiel každú službu, ktorá tento kľúč pravdepodobne používa“; použite explicitný inventory a audit evidence.

Private networking môže obmedziť vystavenie database trafficu, no neruší potrebu credentials. Internal hostnames určujú cestu; authentication určuje, kto smie databázu používať.

Začnite overiteľným nasadením

Pred nastavením klasifikujte každý kľúč, overte, že čítanie secrets je maskované, a zahrňte požadované opätovné nasadenie do tej istej skontrolovanej zmeny.

Začnite bezplatne na app.dockup.ai. Plán Free stojí 0 $ mesačne, zahŕňa úvodný kredit 10 $ a podporuje jeden workspace, tri databázy a tri nasadenia.

FAQ

Vracia Dockup uložené hodnoty secrets?

Nie. Hodnoty secrets sú vo výstupe čítania maskované. Kľúče a označenia secrets zostávajú viditeľné, aby operátori mohli overiť existenciu požadovanej konfigurácie.

Prečo musím po zmene premennej prostredia znovu nasadiť aplikáciu?

Bežiaci process dostal svoj environment pri štarte. Nové nasadenie vytvorí nový container s aktualizovanými hodnotami a overí ho prostredníctvom health gate.

Môžem vložiť secrets do dockup.yaml?

Nie. dockup.yaml používajte na bežnú konfiguráciu vhodnú na kontrolu a na credentials použite secret environment commands alebo CI secret injection.

Ako importujem viacero premenných prostredia?

Použite dockup env import so súborom v štýle .env a presne určeným targetom služby. Možnosť importu --secret použite iba vtedy, keď sú všetky importované hodnoty secrets.

Čo mám urobiť, ak sa secret objaví v logu?

Okamžite ho odvolajte alebo rotujte, aktualizujte secret v Dockup, znovu nasaďte zmenu, preskúmajte access logy a opravte proces, ktorý umožnil jeho zverejnenie.