Miljövariabler och hemligheter på Dockup

Miljövariabler och hemligheter kopplar applikationskod till produktionskonfiguration, men har olika krav på exponering och livscykel. En offentlig bas-URL för ett API kan vara säker att visa i loggar, medan ett databaslösenord eller en signeringsnyckel inte är det. Dockup representerar denna skillnad uttryckligen och maskerar lagrade hemlighetsvärden i läsresultat.

Konfigurationsändringar kräver också en omdistribution. När du anger ett nytt värde uppdateras tjänstens önskade konfiguration, men den redan körande processen behåller den miljö som den fick vid starten.

Vad är skillnaden mellan en variabel och en hemlighet?

Båda värdena går in i applikationsprocessen som miljödata, men hanteras olika ur driftssynpunkt.

Typ	Exempel	Kan förekomma i läsresultat?	Rekommenderad hantering
Vanlig variabel	NODE_ENV=production	Ja	Konfiguration som kan granskas
Vanlig variabel	PUBLIC_API_URL=https://...	Ja	Kan finnas i dockup.yaml
Hemlighet	DATABASE_URL=postgres://...	Inget lagrat värde	Secret-kommandot eller CI-lager
Hemlighet	JWT_SIGNING_KEY=...	Inget lagrat värde	Rotera och begränsa
Hemlighet	DOCKUP_TOKEN=...	Lagra aldrig som appkonfiguration om det inte krävs	Auth på processnivå

Markera ett värde som en hemlighet när exponering skulle möjliggöra åtkomst, imitation, dekryptering, signering eller lateral förflyttning. ”Frontend innehåller det redan” är ett tecken på att värdet är offentlig konfiguration, inte en hemlighet.

Lägg inte hemligheter i versionshantering, dockup.yaml, exempelutdata, skärmbilder, agentprompter eller ärendebeskrivningar. En maskerad platshållare är säkrare än en realistiskt utformad token, eftersom kopierade exempel ofta blir produktionspraxis.

Hur anger och granskar du miljökonfiguration?

Lista aktuella nycklar för ett exakt mål:

dockup env list -s production/api --json

Svaret innehåller varje nyckel, om den är en hemlighet och värdet endast när det inte är skyddat.

Ange en vanlig variabel:

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

Ange en hemlighet från den aktuella shellmiljön:

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

Ta bort ett föråldrat värde:

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

Importera flera värden från en fil i .env-stil:

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

Använd --secret vid import endast när alla importerade värden ska behandlas som hemligheter. Blandade filer är svårare att granska och leder ofta till att ofarlig konfiguration klassificeras som hemlig i onödan eller att autentiseringsuppgifter inte klassificeras som hemligheter. Separera dem när det är möjligt.

Den exakta kommandouppsättningen underhålls i Dockup CLI-referensen.

Varför krävs en omdistribution efter konfigurationsändringar?

Miljövariabler läses när en process startar. En uppdatering av plattformskonfigurationen ändrar inte minnet i en körande Node.js-, Python-, Go- eller annan process. Tjänsten måste starta en ny container med den nya miljön.

Den korrekta sekvensen är:

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

dockup deploy production/api --wait --json

--wait gör det möjligt att verifiera det andra steget. Standardtidsgränsen är 900 sekunder, avslutskod 0 betyder att åtgärden lyckades och fel returnerar en kod som inte är noll tillsammans med strukturerade felkoder.

Dockups blue-green-process utan driftstopp startar den nya versionen, tillämpar hälsokontrollen och växlar först därefter trafiken. Det förhindrar att den aktuella containern startas om på plats med en konfiguration som inte har verifierats.

Om en rotation av en hemlighet ändrar både producent och konsument måste du planera för kompatibilitet. Om ett databaslösenord roteras innan applikationen har fått det nya värdet kan det orsaka ett driftstopp. Använd en överlappningsperiod, stöd för dubbla nycklar eller en ordnad ändring när det externa systemet tillåter det.

Distributionsmekaniken förklaras i distributioner utan driftstopp.

Hur minskar maskering av hemligheter agentrisker?

Kodningsagenter sammanfattar ofta kommandoutdata. Ett verktyg som returnerar lagrade hemligheter förvandlar en ofarlig begäran om att ”visa aktuell konfiguration” till exponering av autentiseringsuppgifter.

Dockup maskerar hemlighetsvärden. Agenten kan se att DATABASE_URL finns och är markerad som en hemlighet, men kan inte läsa den lagrade anslutningssträngen. Den kan ersätta värdet när användaren tillhandahåller ett nytt genom en säker miljö.

Detta möjliggör en säkrare instruktion:

Bekräfta att de nödvändiga hemlighetsnycklarna finns, men skriv aldrig ut deras värden. Om ett värde måste ändras ska du endast läsa det från processmiljön och returnera nyckelnamnet, inte hemligheten.

Maskering av hemligheter bör även omfatta diagnostik. Undvik:

printenv

i en agenttranskription, även om kommandot PRO exec kan köra engångskommandon i containrar. Föredra en riktad applikationskontroll som rapporterar om ett värde finns, dess längdklass eller om anslutningen lyckades, utan att avslöja värdet.

Guiden produktionsskyddsräcken för AI-agenter behandlar prompt- och verktygsgränser tillsammans.

Hur bör hemligheter roteras och granskas?

Rotation är en kontrollerad produktionsändring, inte en textredigering. Använd denna sekvens:

1. Skapa eller hämta den nya autentiseringsuppgiften i det ägande systemet.
2. Lagra den i den godkända CI- eller operatörsmiljön.
3. Ange den nya hemligheten i Dockup utan att skriva ut den.
4. Distribuera med --wait.
5. Verifiera hälsa och applikationsbeteende.
6. Återkalla den gamla autentiseringsuppgiften efter att den nya versionen är aktiv.
7. Granska Dockups auditlogg.
8. Dokumentera rotationsdatum och ägare utan att dokumentera värdet.

dockup audit --writes --json

Granskningsunderlaget bör visa att konfigurationen ändrades och att en distribution följde. Det får inte innehålla hemlighetens värde.

För databasautentiseringsuppgifter bör du ta anslutningspooler i beaktande. Befintliga anslutningar kan fortsätta vara autentiserade efter rotationen medan nya anslutningar använder det nya lösenordet. Verifieringen bör omfatta en ny anslutning, inte bara förfrågningar som hanteras av en gammal pool.

För API-nycklar med behörigheter ska du fånga det genererade värdet på ett säkert sätt när det skapas. Lagra det omedelbart i det godkända hemlighetssystemet, begränsa det till nödvändiga behörigheter och rotera det utan att återge det i distributionsutdata.

Vilken konfigurationspolicy förhindrar drift?

Definiera vilka värden som hör hemma i varje källa:

Källa	Lämpligt innehåll
Kod i repositoryt	Standardvärden som inte är miljöspecifika
dockup.yaml	Granskningsbar, vanlig distributionskonfiguration
Dockups hemlighetsvariabler	Autentiseringsuppgifter vid körning
CI-hemlighetslager	Distributionstoken och injicerade rotationsvärden
Utdata från hanterad databas	Anslutningsdata som lämnas till den konsumerande tjänsten
Lokal .env	Utvecklarspecifika värden som exkluderas från Git

dockup.yaml apply är additivt som standard. Vanliga miljövärden som inte finns i filen ligger kvar tills --prune uttryckligen används, och hemligheter rensas aldrig via den sökvägen. Läs dockup.yaml-konfiguration som kod innan du börjar rensa manifest.

Använd konsekventa nyckelnamn i olika miljöer, men anta inte att värdena är utbytbara. En staging-nyckel ska inte ge åtkomst till produktion. Preview-distributioner i ett projekt med privat nätverk får en automatiskt skapad skrivskyddad databasanvändare för åtkomst till produktionsdata; de bör inte ärva skrivbehörigheter som standard.

Incidenthantering för en läckt hemlighet

Om en hemlighet förekommer i en transkription, logg, commit eller skärmbild räcker det inte att maskera den i efterhand. Behandla den som komprometterad:

1. Återkalla eller rotera den i källsystemet.
2. Uppdatera Dockup-hemligheten.
3. Distribuera om och verifiera.
4. Ta bort det exponerade materialet där det är möjligt.
5. Sök i audit- och åtkomstloggar efter missbruk.
6. Dokumentera orsaken och den förebyggande ändringen.

Omskrivning av Git-historiken kan minska framtida upptäckter, men kan inte bevisa att en kopierad autentiseringsuppgift har försvunnit. Återkallande är den avgörande åtgärden.

Checklista för miljögranskning

Inför varje produktionsrelease ska du verifiera att nödvändiga nycklar finns, att hemlighetsnycklar är markerade som hemligheter, att ingen hemlighet har committats, att vanliga värden överensstämmer med den avsedda miljön och att en omdistribution ingår i ändringen. Kontrollera sedan status och drifttid:

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

Övervakningen körs varje minut och omfattar svarstidens p95. En lyckad konfigurationsdistribution bör ändå övervakas för regressioner vid körning.

Följ Från Git-repository till produktion för att skapa tjänster och genomföra den första konfigurationen.

Validera konfiguration utan att avslöja den

Applikationer bör ge tydliga fel när en nödvändig nyckel saknas, men diagnostik får inte skriva ut värdet. En startkontroll kan rapportera en lista som missing: ["DATABASE_URL"] eller invalid format: ["PUBLIC_URL"] och därefter avsluta med en avslutskod som inte är noll.

För ett valfritt värde ska du definiera reservvärdet i koden och dokumentera om reservvärdet är säkert i produktion. Tysta standardvärden för utveckling – lokala databashostnamn, felsökningslägen, tillåtande CORS eller testautentiseringsuppgifter – bör inte aktiveras enbart för att en produktionsnyckel saknas.

Denna validering gör miljövariabler och hemligheter observerbara utan att förvandla loggar till ett register över autentiseringsuppgifter.

Hantera flera tjänster och delade autentiseringsuppgifter medvetet

Att kopiera en hemlighet till flera tjänster skapar ett rotationsberoende. Föredra tjänstespecifika autentiseringsuppgifter när det externa systemet stöder det. En komprometterad token för en worker bör inte ge samma åtkomst som det offentliga API:t.

När ett delat värde inte kan undvikas ska du upprätthålla en lista över ägare och konsumenter. Rotera alla konsumenter under ett samordnat tidsfönster och verifiera nya anslutningar efter varje omdistribution. Be inte en agent att ”hitta alla tjänster som troligen använder den här nyckeln” baserat på namnlikhet; använd en uttrycklig inventering och granskningsunderlag.

Privata nätverk kan minska exponeringen av databastrafik, men gör inte autentiseringsuppgifter onödiga. Interna värdnamn styr sökvägen; autentisering styr vem som får använda databasen.

Börja med en verifierbar distribution

Klassificera varje nyckel innan du anger den, verifiera att läsning av hemligheter är maskerad och inkludera den nödvändiga omdistributionen i samma granskade ändring.

Börja gratis på app.dockup.ai. Free-planen kostar 0 USD per månad, inkluderar 10 USD i startkredit och stöder en workspace, tre databaser och tre distributioner.

Vanliga frågor

Returnerar Dockup lagrade hemlighetsvärden?

Nej. Hemlighetsvärden maskeras i läsresultat. Nycklar och markeringar för hemligheter förblir synliga så att operatörer kan verifiera att den nödvändiga konfigurationen finns.

Varför måste jag distribuera om efter att ha ändrat en miljövariabel?

Den körande processen fick sin miljö vid starten. En ny distribution skapar en ny container med de uppdaterade värdena och verifierar den genom hälsokontrollen.

Kan jag lägga hemligheter i dockup.yaml?

Nej. Använd dockup.yaml för vanlig, granskningsbar konfiguration och använd kommandon för hemliga miljövariabler eller injicering av CI-hemligheter för autentiseringsuppgifter.

Hur importerar jag flera miljövariabler?

Använd dockup env import med en fil i .env-stil och det exakta tjänstemålet. Använd alternativet import --secret endast när alla importerade värden är hemligheter.

Vad ska jag göra om en hemlighet exponeras i en logg?

Återkalla eller rotera den omedelbart, uppdatera Dockup-hemligheten, distribuera om, undersök åtkomstloggarna och åtgärda processen som möjliggjorde exponeringen.