Miljøvariabler og secrets på Dockup

Miljøvariabler og secrets kobler applikasjonskoden til produksjonskonfigurasjonen, men har ulike krav til eksponering og livssyklus. En offentlig API base URL kan være trygg å vise i logger, mens et databasepassord eller en signeringsnøkkel ikke er det. Dockup representerer dette skillet eksplisitt og maskerer lagrede secret-verdier i leseoutput.

Konfigurasjonsendringer krever også en ny utrulling. Når du angir en ny verdi, oppdateres ønsket tjenestekonfigurasjon, men prosessen som allerede kjører, beholder miljøet den mottok ved oppstart.

Hva er forskjellen mellom en variabel og en secret?

Begge verdiene kommer inn i applikasjonsprosessen som miljødata, men behandles forskjellig i drift.

Type	Eksempel	Kan vises i leseoutput?	Anbefalt håndtering
Vanlig variabel	NODE_ENV=production	Ja	Konfigurasjon som kan gjennomgås
Vanlig variabel	PUBLIC_API_URL=https://...	Ja	Kan ligge i dockup.yaml
Secret	DATABASE_URL=postgres://...	Ingen lagret verdi	Secret-kommando eller CI-lager
Secret	JWT_SIGNING_KEY=...	Ingen lagret verdi	Roter og begrens tilgang
Secret	DOCKUP_TOKEN=...	Skal aldri lagres som appkonfigurasjon med mindre det er nødvendig	Autentisering på prosessnivå

Merk en verdi som secret når eksponering kan gi tilgang, gjøre det mulig å utgi seg for noen andre, dekryptere, signere eller bevege seg sidelengs i systemet. At «frontend allerede inneholder den», er et tegn på at verdien er offentlig konfigurasjon, ikke en secret.

Ikke legg secrets i kildekontroll, dockup.yaml, eksempeloutput, skjermbilder, agentprompter eller problembeskrivelser. En maskert plassholder er tryggere enn et token som ser realistisk ut, fordi kopierte eksempler ofte blir brukt som produksjonspraksis.

Hvordan angir og inspiserer du miljøkonfigurasjon?

List gjeldende nøkler for et eksakt mål:

dockup env list -s production/api --json

Responsen inkluderer hver nøkkel, om den er en secret, og verdien bare når den ikke er beskyttet.

Angi en vanlig variabel:

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

Angi en secret fra miljøet i gjeldende shell:

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

Fjern en utdatert verdi:

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

Importer flere verdier fra en .env-lignende fil:

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

Bruk --secret ved import bare når alle importerte verdier skal behandles som secrets. Filer med blandet innhold er vanskeligere å gjennomgå og fører ofte til at ufarlig konfigurasjon klassifiseres som secret, eller at legitimasjon ikke klassifiseres som det. Skill dem når det er mulig.

Det nøyaktige kommandooppsettet vedlikeholdes i Dockup CLI-referansen.

Hvorfor kreves en ny utrulling etter konfigurasjonsendringer?

Miljøvariabler leses når en prosess starter. Når plattformkonfigurasjonen oppdateres, endres ikke minnet til en prosess som allerede kjører, enten det er en Node.js-, Python-, Go- eller annen prosess. Tjenesten må starte en ny container med det nye miljøet.

Riktig rekkefølge er:

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

dockup deploy production/api --wait --json

--wait gjør det mulig å verifisere det andre trinnet. Standard timeout er 900 sekunder, exit 0 betyr at operasjonen var vellykket, og feil returnerer en verdi ulik null med strukturerte koder.

Dockups blue-green-prosess uten nedetid starter den nye versjonen, utfører helsesjekken og flytter først deretter trafikken. Dermed unngår du å starte den gjeldende containeren på nytt på stedet med en konfigurasjon som ikke er verifisert.

Hvis en secret-rotasjon endrer både produsent og konsument, må du planlegge for kompatibilitet. Rotering av et databasepassord før applikasjonen mottar den nye verdien kan føre til driftsavbrudd. Bruk en overlappingsperiode, støtte for to nøkler eller en trinnvis endring når det eksterne systemet tillater det.

Distribusjonsmekanismene er forklart i utrullinger uten nedetid.

Hvordan reduserer maskering av secrets risikoen med agenter?

Kodeagenter oppsummerer ofte kommandooutput. Et verktøy som returnerer lagrede secrets, gjør en ufarlig forespørsel om å «vise gjeldende konfigurasjon» til en eksponering av legitimasjon.

Dockup maskerer secret-verdier. Agenten kan se at DATABASE_URL finnes og er merket som secret, men kan ikke lese den lagrede tilkoblingsstrengen. Den kan erstatte verdien når brukeren oppgir en ny verdi gjennom et sikkert miljø.

Dette støtter en tryggere instruksjon:

Bekreft at de nødvendige secret-nøklene finnes, men skriv aldri ut verdiene. Hvis en verdi må endres, skal den bare leses fra prosessmiljøet, og du skal returnere nøkkelnavnet, ikke secret-en.

Maskering av secrets bør også gjelde diagnostikk. Unngå:

printenv

i en agenttranskripsjon, selv om PRO-kommandoen exec kan kjøre engangskommandoer i containeren. Foretrekk en målrettet applikasjonssjekk som rapporterer om verdien finnes, lengdeklasse eller om tilkoblingen var vellykket, uten å eksponere verdien.

Veiledningen produksjonsrekkverk for AI-agenter dekker prompt- og verktøygrenser samlet.

Hvordan bør secrets roteres og revideres?

Rotasjon er en kontrollert produksjonsendring, ikke en tekstredigering. Bruk denne rekkefølgen:

1. Opprett eller hent den nye legitimasjonen i systemet som eier den.
2. Lagre den i det godkjente CI- eller operatørmiljøet.
3. Angi den nye secret-en i Dockup uten å skrive den ut.
4. Rull ut med --wait.
5. Bekreft helse og applikasjonsfunksjonalitet.
6. Tilbakekall den gamle legitimasjonen etter at den nye versjonen er aktiv.
7. Gå gjennom Dockup-revisjonsloggen.
8. Registrer rotasjonsdato og eier uten å registrere verdien.

dockup audit --writes --json

Revisjonssporene bør vise at konfigurasjonen ble endret og at en utrulling fulgte etter. De skal ikke inneholde secret-verdien.

For databaselegitimasjon bør du ta hensyn til connection pools. Eksisterende tilkoblinger kan fortsatt være autentisert etter rotasjonen, mens nye tilkoblinger bruker det nye passordet. Verifiseringen bør inkludere en ny tilkobling, ikke bare forespørsler som håndteres av en gammel pool.

For API-nøkler med tillatelser må du ta vare på den genererte verdien på en sikker måte når den opprettes. Lagre den umiddelbart i det godkjente secretsystemet, begrens den til nødvendige tillatelser, og roter den uten å gjengi den i utrullingsoutput.

Hvilken konfigurasjonspolicy hindrer drift?

Definer hvilke verdier som hører hjemme i hver kilde:

Kilde	Egnet innhold
Repository-kode	Standardverdier som ikke er miljøspesifikke
dockup.yaml	Konfigurasjon for utrulling som kan gjennomgås
Dockup secret-variabler	Legitimasjon ved kjøring
CI secrets-lager	Utrullingstoken og injiserte rotasjonsverdier
Output fra administrert database	Tilkoblingsdata som overleveres til tjenesten som bruker dem
Lokal .env	Verdier som bare brukes av utviklere og er ekskludert fra Git

dockup.yaml apply er additiv som standard. Vanlige miljøverdier som ikke finnes i filen, blir værende til --prune brukes eksplisitt, og secrets fjernes aldri gjennom denne banen. Les dockup.yaml som konfigurasjon som kode før du tar i bruk opprydding av manifestet.

Bruk konsekvente nøkkelnavn på tvers av miljøer, men ikke anta at verdiene kan brukes om hverandre. En staging-nøkkel skal ikke gi tilgang til produksjon. Preview-utrullinger i et prosjekt med private nettverk får automatisk opprettet en skrivebeskyttet databasebruker for tilgang til produksjonsdata. De skal ikke arve skrivetilgang som standard.

Hendelseshåndtering for en lekket secret

Hvis en secret vises i en transkripsjon, logg, commit eller skjermbilde, er det ikke nok å maskere den senere. Behandle den som kompromittert:

1. Tilbakekall eller roter den i kildesystemet.
2. Oppdater Dockup-secret-en.
3. Rull ut på nytt og verifiser.
4. Fjern det eksponerte materialet der det er mulig.
5. Søk i revisjons- og tilgangslogger etter misbruk.
6. Dokumenter årsaken og endringen som skal forhindre gjentakelse.

Omskriving av Git-historikken kan redusere fremtidig oppdagelse, men kan ikke bevise at en kopiert legitimasjon er borte. Tilbakekalling er det avgjørende tiltaket.

Sjekkliste for miljøgjennomgang

Før hver produksjonsrelease må du kontrollere at de nødvendige nøklene finnes, at secret-nøkler er merket som secrets, at ingen secret er commitet, at vanlige verdier samsvarer med det tiltenkte miljøet, og at en ny utrulling er en del av endringen. Kontroller deretter status og oppetid:

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

Overvåkingen kjører hvert minutt og inkluderer p95-responstid. En vellykket konfigurasjonsutrulling bør fortsatt overvåkes for regresjoner i kjøretid.

For opprettelse av tjenester og førstegangsoppsett kan du følge Fra Git-repository til produksjon.

Valider konfigurasjon uten å eksponere den

Applikasjoner bør feile tydelig når en nødvendig nøkkel mangler, men diagnostikk må ikke skrive ut verdien. En oppstartssjekk kan rapportere en liste som missing: ["DATABASE_URL"] eller invalid format: ["PUBLIC_URL"] og deretter avslutte med en exit-verdi ulik null.

For en valgfri verdi bør du definere fallbacken i koden og dokumentere om fallbacken er trygg i produksjon. Stille utviklingsstandarder – lokale databaseverter, debug-modus, tillatende CORS eller testlegitimasjon – bør ikke aktiveres bare fordi en produksjonsnøkkel mangler.

Denne valideringen gjør miljøvariabler og secrets synlige uten å gjøre logger til en oversikt over legitimasjon.

Håndter flere tjenester og delte credentials bevisst

Når du kopierer én secret til flere tjenester, oppstår en rotasjonsavhengighet. Foretrekk tjenestespesifikk legitimasjon når det eksterne systemet støtter det. Et kompromittert worker-token skal ikke gi samme tilgang som det offentlige API-et.

Når en delt verdi ikke kan unngås, må du føre en liste over eier og konsumenter. Roter alle konsumenter i et koordinert tidsvindu og verifiser nye tilkoblinger etter hver utrulling. Ikke be en agent om å «finne alle tjenester som sannsynligvis bruker denne nøkkelen» basert på navnelikhet. Bruk en eksplisitt oversikt og revisjonsspor som dokumentasjon.

Private nettverk kan redusere eksponeringen av databasetrafikk, men gjør ikke legitimasjon unødvendig. Interne vertsnavn styrer nettverksbanen, mens autentisering styrer hvem som kan bruke databasen.

Start med en verifiserbar utrulling

Klassifiser hver nøkkel før du angir den, bekreft at lesing av secrets er maskert, og ta med den nødvendige nye utrullingen i samme endring som gjennomgås.

Start gratis på app.dockup.ai. Free-planen koster $0 per måned, inkluderer $10 i startkreditt og støtter ett workspace, tre databaser og tre utrullinger.

Vanlige spørsmål

Returnerer Dockup lagrede secret-verdier?

Nei. Secret-verdier maskeres i leseoutput. Nøkler og secret-markører er fortsatt synlige, slik at operatører kan bekrefte at den nødvendige konfigurasjonen finnes.

Hvorfor må jeg rulle ut på nytt etter at jeg har endret en miljøvariabel?

Prosessen som kjører, mottok miljøet sitt ved oppstart. En ny utrulling oppretter en ny container med de oppdaterte verdiene og verifiserer den gjennom helsesjekken.

Kan jeg legge secrets i dockup.yaml?

Nei. Bruk dockup.yaml til vanlig konfigurasjon som kan gjennomgås, og bruk secret-miljøkommandoer eller injisering av secrets fra CI til legitimasjon.

Hvordan importerer jeg flere miljøvariabler?

Bruk dockup env import med en .env-lignende fil og det nøyaktige tjenestemålet. Bruk importalternativet --secret bare når alle de importerte verdiene er secrets.

Hva bør jeg gjøre hvis en secret eksponeres i en logg?

Tilbakekall eller roter den umiddelbart, oppdater Dockup-secret-en, rull ut på nytt, undersøk tilgangsloggene og rett prosessen som tillot eksponeringen.