Környezeti változók és secret értékek a Dockupon

A környezeti változók és secret értékek kapcsolják össze az alkalmazáskódot az éles konfigurációval, de eltérő közzétételi és életciklus-követelmények vonatkoznak rájuk. Egy nyilvános API base URL biztonságosan megjelenhet a logokban, egy adatbázisjelszó vagy signing key viszont nem. A Dockup ezt a különbséget explicit módon kezeli, és a tárolt secret értékeket maszkolja a lekérdezések eredményében.

A konfiguráció módosítása újratelepítést is igényel. Egy új érték beállítása frissíti a szolgáltatás kívánt konfigurációját, a már futó process azonban továbbra is azt a környezetet használja, amelyet induláskor kapott.

Mi a különbség egy változó és egy secret érték között?

Mindkét érték környezeti adatként kerül be az alkalmazás processébe, de az operatív kezelésük eltér.

Típus	Példa	Megjelenhet a lekérdezés eredményében?	Ajánlott kezelés
Egyszerű változó	NODE_ENV=production	Igen	Ellenőrizhető konfiguráció
Egyszerű változó	PUBLIC_API_URL=https://...	Igen	A dockup.yaml fájlban is tárolható
Secret	DATABASE_URL=postgres://...	A tárolt érték nem	Secret parancs vagy CI-tároló
Secret	JWT_SIGNING_KEY=...	A tárolt érték nem	Rotáld és korlátozd
Secret	DOCKUP_TOKEN=...	Alkalmazáskonfigurációként soha, hacsak nem szükséges	Process-szintű hitelesítés

Akkor jelölj egy értéket secretként, ha a közzététele hozzáférést, megszemélyesítést, visszafejtést, aláírást vagy oldalirányú mozgást tenne lehetővé. Az, hogy „a frontend már tartalmazza”, azt jelzi, hogy az érték nyilvános konfiguráció, nem pedig secret.

Ne helyezz secret értékeket source controlba, dockup.yaml fájlba, példakimenetbe, képernyőképekbe, agent promptjaiba vagy issue-leírásokba. A maszkolt placeholder biztonságosabb, mint egy valószerű token, mert a bemásolt példákból könnyen éles gyakorlat lesz.

Hogyan állítható be és ellenőrizhető a környezeti konfiguráció?

Az aktuális kulcsok listázása pontos célhoz:

dockup env list -s production/api --json

A válasz tartalmazza az egyes kulcsokat, azt, hogy secret értékről van-e szó, valamint az értéket, ha az nincs védelemmel ellátva.

Egyszerű változó beállítása:

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

Secret beállítása az aktuális shell környezetéből:

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

Elavult érték eltávolítása:

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

.env-stílusú fájl tömeges importálása:

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

Importáláskor csak akkor használd a --secret kapcsolót, ha minden importált értéket secretként kell kezelni. A vegyes fájlokat nehezebb felülvizsgálni, és gyakran ahhoz vezetnek, hogy ártalmatlan konfigurációt is secretként jelölnek, vagy a hitelesítő adatokat nem sorolják ebbe a kategóriába. Ha lehetséges, válaszd szét őket.

A parancsok aktuális leírását a Dockup CLI-referenciában találod.

Miért szükséges újratelepítés a konfiguráció módosítása után?

A környezeti változókat a process induláskor olvassa be. A platform konfigurációjának frissítése nem módosítja a futó Node.js-, Python-, Go- vagy más process memóriáját. A szolgáltatást új konténerben kell elindítani az új környezettel.

A helyes sorrend:

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

dockup deploy production/api --wait --json

A --wait kapcsolóval a második lépés ellenőrizhetővé válik. Az alapértelmezett timeout 900 másodperc, a 0-s kilépési kód sikert jelent, a hibák pedig nem nulla kilépési kóddal és strukturált kódokkal térnek vissza.

A Dockup zero-downtime blue-green folyamata elindítja az új verziót, alkalmazza a health gate-et, majd csak ezután irányítja át a forgalmat. Így nem kell a jelenlegi konténert helyben újraindítani ellenőrizetlen konfigurációval.

Ha a secret rotációja a producer és a consumer értékeit is módosítja, tervezz kompatibilitással. Ha az adatbázis jelszavát azelőtt rotálod, hogy az alkalmazás megkapná az új értéket, kiesést okozhatsz. Használj átfedési időszakot, dual-key támogatást vagy sorrendbe rendezett módosítást, ha a külső rendszer ezt lehetővé teszi.

A deployment működését a zero-downtime deploymentekről szóló útmutató ismerteti.

Hogyan csökkenti a secret maszkolása az agentek kockázatát?

A coding agentek gyakran összefoglalják a parancskimenetet. Ha egy tool visszaadja a tárolt secret értékeket, egy ártalmatlannak tűnő „mutasd az aktuális konfigurációt” kérés hitelesítőadat-kitettséghez vezethet.

A Dockup maszkolja a secret értékeket. Az agent láthatja, hogy a DATABASE_URL létezik és secretként van megjelölve, de nem olvashatja ki a tárolt connection stringet. Az értéket akkor cserélheti le, ha a felhasználó biztonságos környezeten keresztül új értéket ad meg.

Ez biztonságosabb utasítást tesz lehetővé:

Erősítsd meg, hogy a szükséges secret kulcsok léteznek, de soha ne írd ki az értékeiket. Ha egy értéket módosítani kell, csak a process környezetéből olvasd be, és ne a secretet, hanem a kulcs nevét add vissza.

A secret maszkolását a diagnosztikára is ki kell terjeszteni. Kerüld a következőt:

printenv

agent transcriptben, még akkor is, ha a PRO exec parancs egyszeri konténerparancsokat tud futtatni. Ehelyett célzott alkalmazás-ellenőrzést használj, amely az érték közzététele nélkül jelzi a jelenlétet, a hossz kategóriáját vagy a kapcsolódás sikerességét.

Az AI agentek éles környezetre vonatkozó védőkorlátairól szóló útmutató együtt tárgyalja a prompt- és tool-határokat.

Hogyan kell rotálni és auditálni a secret értékeket?

A rotáció szabályozott éles módosítás, nem egyszerű szövegszerkesztés. Használd az alábbi sorrendet:

1. Hozd létre vagy szerezd be az új hitelesítő adatot a kezeléséért felelős rendszerben.
2. Tárold a jóváhagyott CI- vagy operátori környezetben.
3. Állítsd be az új secretet a Dockupban anélkül, hogy kiíratnád.
4. Futtass deploymentet --wait kapcsolóval.
5. Ellenőrizd a health állapotot és az alkalmazás működését.
6. Vond vissza a régi hitelesítő adatot, miután az új verzió aktívvá vált.
7. Tekintsd át a Dockup auditlogját.
8. Rögzítsd a rotáció dátumát és felelősét, de magát az értéket ne.

dockup audit --writes --json

Az audit bizonyítékainak azt kell mutatniuk, hogy a konfiguráció módosult, és ezt deployment követte. A secret értéke nem szerepelhet bennük.

Adatbázis-hitelesítő adatok esetén számolj a connection poole-okkal. A meglévő kapcsolatok a rotáció után is hitelesítve maradhatnak, miközben az új kapcsolatok már az új jelszót használják. Az ellenőrzésnek friss kapcsolat létrehozására is ki kell terjednie, nem csak a régi poolból kiszolgált kérésekre.

Jogosultságkezelt API-kulcsoknál a létrehozáskor biztonságosan rögzítsd a generált értéket. Azonnal tárold a jóváhagyott secret-rendszerben, korlátozd a szükséges jogosultságokra, és úgy rotáld, hogy ne jelenjen meg újra a deployment kimenetében.

Milyen konfigurációs szabályzat előzi meg a driftet?

Határozd meg, mely értékek melyik forrásba tartoznak:

Forrás	Megfelelő tartalom
Repository-kód	Nem környezetfüggő alapértékek
dockup.yaml	Felülvizsgálható egyszerű deployment-konfiguráció
Dockup secret változói	Futásidejű hitelesítő adatok
CI secret store	Deployment-token és injektált rotációs értékek
Kezelt adatbázis kimenete	A fogyasztó szolgáltatásnak átadott kapcsolati adatok
Helyi .env	Csak fejlesztéshez használt értékek, Gitből kizárva

A dockup.yaml apply alapértelmezés szerint additív. A fájlban nem szereplő egyszerű környezeti értékek megmaradnak, amíg explicit módon nem használod a --prune kapcsolót, a secret értékeket pedig ezen az útvonalon soha nem törli a rendszer. A manifesttisztítás bevezetése előtt olvasd el a dockup.yaml mint kód útmutatót.

Használj egységes kulcsneveket a környezetekben, de ne feltételezd, hogy az értékek felcserélhetők. Egy staging-kulcs nem adhat éles hozzáférést. A private networkinget használó projekt preview deploymentjei automatikusan létrehozott, csak olvasási jogosultságú adatbázis-felhasználót kapnak az éles adatok eléréséhez; alapértelmezés szerint nem örökölhetnek írási jogosultságú hitelesítő adatokat.

Incident response kiszivárgott secret esetén

Ha egy secret transcriptben, logban, commitban vagy képernyőképen jelenik meg, későbbi maszkolása nem elegendő. Kezeld kompromittáltként:

1. Vond vissza vagy rotáld a forrásrendszerben.
2. Frissítsd a Dockup secretet.
3. Futtass deploymentet, majd ellenőrizd.
4. Ha lehetséges, távolítsd el a közzétett anyagot.
5. Keress visszaélésekre utaló jeleket az audit- és hozzáférési logokban.
6. Dokumentáld az okot és a megelőző módosítást.

A Git-előzmények átírása csökkentheti a későbbi megtalálhatóságot, de nem bizonyítja, hogy egy lemásolt hitelesítő adat eltűnt. A visszavonás a döntő lépés.

Környezeti ellenőrzőlista

Minden éles kiadás előtt ellenőrizd, hogy a szükséges kulcsok léteznek, a secret kulcsok secretként vannak megjelölve, egyetlen secret sincs commitolva, az egyszerű értékek megfelelnek a kívánt környezetnek, és a módosítás része az újratelepítés. Ezután ellenőrizd az állapotot és az uptime-ot:

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

A monitoring percenként fut, és a p95 válaszidőt is tartalmazza. Egy sikeres konfigurációs deploymentet ennek ellenére is figyelni kell futásidejű regressziók szempontjából.

A szolgáltatás létrehozásához és kezdeti beállításához kövesd a Git repositorytól az éles környezetig útmutatót.

Konfiguráció ellenőrzése az értékek közzététele nélkül

Az alkalmazásoknak egyértelműen jelezniük kell, ha hiányzik egy szükséges kulcs, a diagnosztika azonban nem írhatja ki az értéket. Egy induláskor végzett ellenőrzés például ilyen listát adhat vissza: missing: ["DATABASE_URL"] vagy invalid format: ["PUBLIC_URL"], majd nem nulla kilépési kóddal leállhat.

Opcionális érték esetén definiáld a fallbacket a kódban, és dokumentáld, hogy a fallback biztonságos-e éles környezetben. A csendben aktiválódó fejlesztési alapértékeknek — helyi adatbázis-hostoknak, debug módoknak, engedékeny CORS-beállításoknak vagy teszt-hitelesítő adatoknak — nem szabad bekapcsolniuk pusztán azért, mert hiányzott egy éles kulcs.

Ez az ellenőrzés láthatóvá teszi a környezeti változókat és secret értékeket anélkül, hogy a logokat hitelesítőadat-leltárrá változtatná.

Több szolgáltatás és megosztott hitelesítő adatok tudatos kezelése

Ha ugyanazt a secretet több szolgáltatásba másolod, rotációs függőséget hozol létre. Ha a külső rendszer támogatja, részesítsd előnyben a szolgáltatásonként külön hitelesítő adatokat. Egy kompromittált worker-token nem adhat ugyanakkora hozzáférést, mint a nyilvános API.

Ha egy érték megosztása elkerülhetetlen, tarts fenn felelős- és fogyasztólistát. A rotációt koordinált időablakban végezd el minden fogyasztónál, majd minden újratelepítés után ellenőrizd a friss kapcsolatokat. Ne kérj meg egy agentet arra, hogy név alapján, „valószínűleg” megtalálja az összes szolgáltatást, amely használja a kulcsot; használj explicit leltárt és auditbizonyítékokat.

A private networking csökkentheti az adatbázisforgalom kitettségét, de nem teszi szükségtelenné a hitelesítő adatokat. A belső hostnevek az útvonalat szabályozzák, a hitelesítés pedig azt, hogy ki használhatja az adatbázist.

Kezdd ellenőrizhető deploymenttel

Minden kulcsot osztályozz a beállítása előtt, ellenőrizd, hogy a secret-olvasások maszkolva vannak, és ugyanabba a felülvizsgált módosításba vedd fel a szükséges újratelepítést is.

Kezdd ingyenesen az app.dockup.ai oldalon. A Free csomag havi díja $0, induláskor $10 értékű kreditet tartalmaz, és egy workspace-t, három adatbázist, valamint három deploymentet támogat.

GYIK

Visszaadja a Dockup a tárolt secret értékeket?

Nem. A secret értékek maszkolva jelennek meg a lekérdezések eredményében. A kulcsok és a secret jelölések láthatók maradnak, így az üzemeltetők ellenőrizhetik, hogy a szükséges konfiguráció létezik.

Miért kell újratelepítenem egy környezeti változó módosítása után?

A futó process induláskor kapta meg a környezetét. Az új deployment frissített értékekkel hoz létre új konténert, majd a health gate-en keresztül ellenőrzi.

Elhelyezhetek secret értékeket a dockup.yaml fájlban?

Nem. A dockup.yaml fájlt egyszerű, felülvizsgálható konfigurációhoz használd, a hitelesítő adatokat pedig secret környezeti parancsokkal vagy CI secret-injektálással kezeld.

Hogyan importálhatok több környezeti változót?

Használd a dockup env import parancsot .env-stílusú fájllal és a pontos szolgáltatáscéllal. Az import --secret opcióját csak akkor használd, ha minden importált érték secret.

Mit tegyek, ha egy secret megjelent egy logban?

Azonnal vond vissza vagy rotáld, frissítsd a Dockup secretet, futtass új deploymentet, vizsgáld meg a hozzáférési logokat, és javítsd ki a közzétételt lehetővé tevő folyamatot.