Proměnné prostředí a secrets na Dockup

Proměnné prostředí a secrets propojují kód aplikace s produkční konfigurací, ale mají odlišné požadavky na zpřístupnění a životní cyklus. Veřejná základní URL API může být bezpečná i v logu, heslo k databázi nebo podpisový klíč nikoli. Dockup tento rozdíl explicitně zachovává a uložené hodnoty secretů maskuje ve výstupu příkazů pro čtení.

Změny konfigurace vyžadují také nové nasazení. Nastavením nové hodnoty aktualizujete požadovanou konfiguraci služby, ale již běžící proces si ponechá prostředí, které obdržel při spuštění.

Jaký je rozdíl mezi proměnnou a secretem?

Obě hodnoty vstupují do procesu aplikace jako data prostředí, ale v provozu se s nimi zachází odlišně.

Typ	Příklad	Může se objevit ve výstupu příkazu pro čtení?	Doporučené zacházení
Běžná proměnná	NODE_ENV=production	Ano	Konfigurace vhodná ke kontrole
Běžná proměnná	PUBLIC_API_URL=https://...	Ano	Může být v dockup.yaml
Secret	DATABASE_URL=postgres://...	Uložená hodnota ne	Příkaz pro práci se secrety nebo CI store
Secret	JWT_SIGNING_KEY=...	Uložená hodnota ne	Rotujte a omezte přístup
Secret	DOCKUP_TOKEN=...	Nikdy neukládat jako konfiguraci aplikace, pokud to není nutné	Autentizace na úrovni procesu

Označte hodnotu jako secret, pokud by její zpřístupnění umožnilo získat přístup, vydávat se za jiného uživatele, dešifrovat data, podepisovat nebo provést laterální pohyb v síti. Tvrzení „frontend ho už obsahuje“ znamená, že jde o veřejnou konfiguraci, nikoli secret.

Nedávejte secrets do source control, dockup.yaml, ukázkového výstupu, screenshotů, promptů agentů ani popisů issue. Redigovaný placeholder je bezpečnější než realisticky vypadající token, protože zkopírované příklady se často stanou produkční praxí.

Jak nastavit a zkontrolovat konfiguraci prostředí?

Pro výpis aktuálních klíčů pro konkrétní target použijte:

dockup env list -s production/api --json

Odpověď obsahuje každý klíč, informaci, zda jde o secret, a hodnotu pouze tehdy, když není chráněná.

Nastavte běžnou proměnnou:

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

Nastavte secret z prostředí aktuálního shellu:

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

Odstraňte zastaralou hodnotu:

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

Hromadně importujte soubor ve stylu .env:

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

Při importu použijte --secret pouze tehdy, když má být se secrety zacházeno u všech importovaných hodnot. Smíšené soubory se hůře kontrolují a často vedou k tomu, že se neškodná konfigurace označí jako secret, nebo se naopak credentials neoznačí. Pokud je to možné, oddělte je.

Přesná syntaxe příkazů je udržována v referenci Dockup CLI.

Proč je po změně konfigurace nutné nové nasazení?

Proměnné prostředí se načítají při spuštění procesu. Aktualizace konfigurace platformy nemění paměť již běžícího procesu Node.js, Pythonu, Go ani jiného procesu. Služba musí spustit nový container s novým prostředím.

Správný postup je:

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

dockup deploy production/api --wait --json

--wait umožňuje ověřit druhý krok. Výchozí timeout je 900 sekund, ukončovací kód 0 znamená úspěch a při selhání se vrátí nenulový kód spolu se strukturovanými kódy chyb.

Proces Dockup pro blue-green nasazení bez výpadku spustí novou verzi, provede health gate a teprve poté na ni přesměruje traffic. Tím se zabrání restartování aktuálního containeru na místě s neověřenou konfigurací.

Pokud rotace secretu mění producenta i konzumenta, naplánujte kompatibilitu. Rotace hesla k databázi před tím, než aplikace obdrží novou hodnotu, může způsobit výpadek. Pokud to externí systém umožňuje, použijte období překryvu, podporu dvou klíčů nebo změnu v určeném pořadí.

Mechanismus nasazení je vysvětlen v článku nasazení bez výpadku.

Jak maskování secretů snižuje riziko pro agenty?

Coding agents často shrnují výstup příkazů. Nástroj, který vrací uložené secrets, může z neškodného požadavku „zobraz aktuální konfiguraci“ udělat únik credentials.

Dockup hodnoty secretů maskuje. Agent vidí, že DATABASE_URL existuje a je označena jako secret, ale nemůže přečíst uložený connection string. Hodnotu může nahradit, když uživatel zadá novou prostřednictvím zabezpečeného prostředí.

To umožňuje použít bezpečnější instrukci:

Ověř, že požadované klíče secretů existují, ale nikdy nevypisuj jejich hodnoty. Pokud se hodnota musí změnit, načti ji pouze z prostředí procesu a vrať název klíče, nikoli secret.

Maskování secretů by se mělo vztahovat i na diagnostiku. Vyhněte se příkazu:

printenv

v transcriptu agenta, přestože příkaz PRO exec může spouštět jednorázové příkazy v containeru. Místo toho použijte cílenou kontrolu aplikace, která oznámí přítomnost hodnoty, její délkovou kategorii nebo úspěšné připojení, aniž by hodnotu zpřístupnila.

Průvodce ochrannými pravidly pro AI agenty v produkci popisuje hranice promptů i nástrojů společně.

Jak secrets rotovat a auditovat?

Rotace je řízená produkční změna, nikoli úprava textu. Použijte tento postup:

1. Vytvořte nebo získejte nové credentials v systému, který je spravuje.
2. Uložte je do schváleného CI nebo prostředí operátora.
3. Nastavte nový secret v Dockup, aniž byste ho vypsali.
4. Proveďte nasazení s --wait.
5. Ověřte health a chování aplikace.
6. Po aktivaci nové verze zneplatněte původní credential.
7. Zkontrolujte audit log Dockup.
8. Zaznamenejte datum rotace a vlastníka, nikoli hodnotu.

dockup audit --writes --json

Auditní záznam by měl prokazovat, že se konfigurace změnila a následovalo nasazení. Neměl by obsahovat hodnotu secretu.

U databázových credentials zvažte connection pools. Existující připojení mohou po rotaci zůstat autentizovaná, zatímco nová připojení použijí nové heslo. Ověření by mělo zahrnovat nové připojení, nejen požadavky obsloužené starým poolem.

U API keys s omezenými oprávněními bezpečně zachyťte vygenerovanou hodnotu během vytvoření. Okamžitě ji uložte do schváleného systému pro secrets, omezte ji na požadovaná oprávnění a rotujte ji tak, aby se znovu neobjevila ve výstupu nasazení.

Jaká konfigurační politika zabraňuje driftu?

Definujte, které hodnoty patří do jednotlivých zdrojů:

Zdroj	Vhodný obsah
Kód repository	Výchozí hodnoty, které nejsou závislé na prostředí
dockup.yaml	Konfigurace nasazení, kterou lze kontrolovat
Secret proměnné Dockup	Runtime credentials
CI secret store	Deployment token a hodnoty vložené při rotaci
Výstup managed databáze	Connection data předaná konzumentské službě
Lokální .env	Hodnoty pouze pro vývojáře, vyloučené z Gitu

dockup.yaml apply je ve výchozím nastavení aditivní. Běžné hodnoty prostředí, které v souboru nejsou, zůstávají zachovány, dokud není explicitně použit parametr --prune; secrets se touto cestou nikdy neodstraňují. Před zavedením čištění manifestu si projděte konfiguraci jako kód pomocí dockup.yaml.

Mezi prostředími používejte konzistentní názvy klíčů, ale nepředpokládejte, že hodnoty jsou zaměnitelné. Klíč pro staging by neměl poskytovat přístup do produkce. Preview deployments v projektu s private networking automaticky dostávají read-only databázového uživatele pro přístup k produkčním datům; ve výchozím nastavení by neměly přebírat write credentials.

Reakce na incident s uniklým secretem

Pokud se secret objeví v transcriptu, logu, commitu nebo screenshotu, jeho pozdější zamaskování nestačí. Považujte ho za kompromitovaný:

1. Zneplatněte ho nebo rotujte v systému, který ho spravuje.
2. Aktualizujte secret v Dockup.
3. Proveďte nasazení a ověřte ho.
4. Pokud je to možné, odstraňte zveřejněný materiál.
5. Vyhledejte známky zneužití v auditních a přístupových logách.
6. Zdokumentujte příčinu a změnu, která zamezí opakování.

Přepsání historie Gitu může omezit budoucí nalezení credentials, ale nemůže prokázat, že zkopírovaný credential zmizel. Rozhodujícím krokem je zneplatnění.

Checklist kontroly prostředí

Před každým produkčním releasem ověřte, že požadované klíče existují, klíče secretů jsou označené jako secrets, žádný secret není v commitu, běžné hodnoty odpovídají zamýšlenému prostředí a součástí změny je nové nasazení. Poté zkontrolujte status a uptime:

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

Monitoring se spouští každou minutu a zahrnuje dobu odezvy p95. Úspěšné nasazení konfigurace by mělo být i nadále sledováno kvůli regresím za běhu.

Pro vytvoření služby a úvodní nastavení postupujte podle článku z Git repository do produkce.

Ověřujte konfiguraci bez zpřístupnění hodnot

Aplikace by měla při chybějícím požadovaném klíči selhat srozumitelným způsobem, diagnostika však nesmí hodnotu vypsat. Kontrola při spuštění může oznámit například missing: ["DATABASE_URL"] nebo invalid format: ["PUBLIC_URL"] a poté skončit s nenulovým kódem.

U volitelné hodnoty definujte fallback v kódu a zdokumentujte, zda je v produkci bezpečný. Tiché vývojové výchozí hodnoty — lokální hostitelé databází, debug režimy, příliš volný CORS nebo testovací credentials — by se neměly aktivovat jen proto, že chybí produkční klíč.

Díky této validaci jsou proměnné prostředí a secrets pozorovatelné, aniž by se z logů stal seznam credentials.

S více službami a sdílenými credentials zacházejte promyšleně

Kopírování jednoho secretu do několika služeb vytváří závislost při rotaci. Pokud to externí systém podporuje, dávejte přednost credentials určeným pro konkrétní službu. Kompromitovaný token workeru by neměl poskytovat stejný přístup jako veřejné API.

Pokud se sdílené hodnotě nelze vyhnout, veďte seznam vlastníků a konzumentů. Rotujte všechny konzumenty v koordinovaném okně a po každém novém nasazení ověřte nová připojení. Nežádejte agenta, aby podle podobnosti názvů „našel každou službu, která tento klíč pravděpodobně používá“; použijte explicitní inventář a auditní důkazy.

Private networking může omezit vystavení databázového provozu, neznamená však, že credentials již nejsou potřeba. Interní hostname určují cestu; autentizace určuje, kdo může databázi používat.

Začněte ověřitelným nasazením

Před nastavením každý klíč klasifikujte, ověřte, že načítání secretů je maskované, a zahrňte požadované nové nasazení do stejné změny podléhající kontrole.

Začněte zdarma na app.dockup.ai. Tarif Free stojí 0 $ měsíčně, zahrnuje počáteční kredit 10 $ a podporuje jeden workspace, tři databáze a tři nasazení.

FAQ

Vrací Dockup uložené hodnoty secretů?

Ne. Hodnoty secretů jsou ve výstupu příkazů pro čtení maskované. Klíče a označení secretů zůstávají viditelné, takže operátoři mohou ověřit, že požadovaná konfigurace existuje.

Proč musím po změně proměnné prostředí provést nové nasazení?

Běžící proces obdržel své prostředí při spuštění. Nové nasazení vytvoří nový container s aktualizovanými hodnotami a ověří ho prostřednictvím health gate.

Mohu dát secrets do dockup.yaml?

Ne. dockup.yaml používejte pro běžnou konfiguraci, kterou lze kontrolovat, a pro credentials použijte příkazy pro práci se secrets nebo vložení secretů z CI.

Jak importuji více proměnných prostředí?

Použijte dockup env import se souborem ve stylu .env a přesným targetem služby. Volbu importu --secret použijte pouze tehdy, když jsou všechny importované hodnoty secrets.

Co mám dělat, když se secret objeví v logu?

Okamžitě ho zneplatněte nebo rotujte, aktualizujte secret v Dockup, proveďte nové nasazení, prověřte access logy a opravte proces, který únik umožnil.