Miljøvariabler og secrets på Dockup

Miljøvariabler og secrets forbinder applikationskode med produktionskonfiguration, men de har forskellige krav til eksponering og livscyklus. En offentlig API-base-URL kan være sikker at vise i logs, mens en databaseadgangskode eller en signing key ikke er det. Dockup repræsenterer denne forskel eksplicit og maskerer gemte secret-værdier i output fra læseoperationer.

Konfigurationsændringer kræver også en genudrulning. Når du angiver en ny værdi, opdateres den ønskede servicekonfiguration, men den allerede kørende proces beholder det miljø, den modtog ved opstart.

Hvad er forskellen på en variabel og en secret?

Begge værdier kommer ind i applikationsprocessen som miljødata, men de håndteres forskelligt i driften.

Type	Eksempel	Må den vises i output fra læseoperationer?	Anbefalet håndtering
Almindelig variabel	NODE_ENV=production	Ja	Konfiguration, der kan gennemgås
Almindelig variabel	PUBLIC_API_URL=https://...	Ja	Kan ligge i dockup.yaml
Secret	DATABASE_URL=postgres://...	Ingen gemt værdi	Secret-kommando eller CI-store
Secret	JWT_SIGNING_KEY=...	Ingen gemt værdi	Rotér og begræns adgangen
Secret	DOCKUP_TOKEN=...	Gem den aldrig som app-konfiguration, medmindre det er nødvendigt	Auth på procesniveau

Markér en værdi som secret, når eksponering kan give adgang, muliggøre impersonation, dekryptering, signing eller lateral movement. “Frontend indeholder den allerede” er et tegn på, at værdien er offentlig konfiguration og ikke en secret.

Læg ikke secrets i source control, dockup.yaml, eksempler på output, screenshots, agent-prompts eller issue-beskrivelser. En redigeret placeholder er sikrere end en token, der ligner en rigtig, fordi kopierede eksempler ofte bliver til produktionspraksis.

Hvordan angiver og inspicerer du miljøkonfiguration?

Vis de aktuelle keys for et specifikt target:

dockup env list -s production/api --json

Svaret indeholder hver key, om den er en secret, samt kun værdien, når den ikke er beskyttet.

Angiv en almindelig variabel:

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

Angiv en secret fra det aktuelle shell-miljø:

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

Fjern en forældet værdi:

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

Importér flere værdier fra en .env-fil:

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

Brug kun --secret ved import, når alle importerede værdier skal behandles som secrets. Blandede filer er sværere at gennemgå og fører ofte til, at harmløs konfiguration klassificeres som secret, eller at credentials ikke klassificeres som secrets. Adskil dem, når det er muligt.

Den præcise kommandoflade vedligeholdes i Dockup CLI-reference.

Hvorfor kræves der en genudrulning efter konfigurationsændringer?

Miljøvariabler læses, når en proces starter. Opdatering af platformkonfiguration ændrer ikke hukommelsen i en kørende Node.js-, Python-, Go- eller anden proces. Servicen skal starte en ny container med det nye miljø.

Den korrekte rækkefølge er:

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

dockup deploy production/api --wait --json

--wait gør det muligt at verificere det andet trin. Standard-timeout er 900 sekunder, exit 0 betyder succes, og fejl returneres med en exit-kode, der ikke er nul, samt strukturerede koder.

Dockups blue-green-proces uden nedetid starter den nye version, anvender health gate og flytter først derefter trafikken. Det undgår at genstarte den aktuelle container på stedet med en konfiguration, der ikke er verificeret.

Hvis en secret-rotation ændrer både producer og consumer, skal du planlægge kompatibiliteten. Hvis du roterer en databaseadgangskode, før applikationen modtager den nye værdi, kan det forårsage et nedbrud. Brug en overlap-periode, understøttelse af to keys eller en ændring i den rigtige rækkefølge, når det eksterne system tillader det.

Implementeringen af deployment er forklaret i deployments uden nedetid.

Hvordan reducerer secret-masking risikoen ved agents?

Coding agents opsummerer ofte output fra kommandoer. Et værktøj, der returnerer gemte secrets, kan gøre en harmløs anmodning om at “vise den aktuelle konfiguration” til en eksponering af credentials.

Dockup maskerer secret-værdier. Agenten kan se, at DATABASE_URL findes og er markeret som secret, men kan ikke læse den gemte connection string. Den kan erstatte værdien, når brugeren angiver en ny gennem et sikkert miljø.

Det understøtter en sikrere instruktion:

Bekræft, at de nødvendige secret-keys findes, men udskriv aldrig deres værdier. Hvis en værdi skal ændres, må den kun læses fra procesmiljøet, og returnér key-navnet – ikke secreten.

Secret-masking bør også omfatte diagnostics. Undgå:

printenv

i en agent-transskription, selvom PRO-kommandoen exec kan køre enkeltstående container-kommandoer. Foretræk i stedet et målrettet applikationstjek, der rapporterer, om værdien findes, dens længdeklasse eller om forbindelsen lykkes, uden at afsløre værdien.

Guiden produktionsbeskyttelse til AI-agents dækker prompt- og værktøjsgrænser samlet.

Hvordan bør secrets roteres og auditeres?

Rotation er en kontrolleret produktionsændring, ikke en tekstændring. Brug denne rækkefølge:

1. Opret eller hent den nye credential i det ansvarlige system.
2. Gem den i det godkendte CI- eller operatørmiljø.
3. Angiv den nye secret i Dockup uden at udskrive den.
4. Deploy med --wait.
5. Verificér health og applikationens adfærd.
6. Tilbagekald den gamle credential, når den nye version er aktiv.
7. Gennemgå Dockups auditlog.
8. Registrér rotationsdato og ejer uden at registrere værdien.

dockup audit --writes --json

Auditspor bør vise, at konfigurationen blev ændret, og at en deployment fulgte efter. Det må ikke indeholde secret-værdien.

For databasecredentials bør du tage connection pools i betragtning. Eksisterende forbindelser kan forblive autentificerede efter rotation, mens nye forbindelser bruger den nye adgangskode. Verificeringen bør omfatte en ny forbindelse og ikke kun requests, der håndteres af en gammel pool.

For API-keys med tilladelser skal den genererede værdi opfanges sikkert under oprettelsen. Gem den straks i det godkendte secretsystem, begræns den til de nødvendige tilladelser, og rotér den uden at gengive den i deployment-output.

Hvilken konfigurationspolitik forhindrer drift?

Definér, hvilke værdier der hører til i hver kilde:

Kilde	Egnet indhold
Repository-kode	Defaults, der ikke er miljøspecifikke
dockup.yaml	Konfiguration til deployment, som kan gennemgås
Dockup secret-variabler	Runtime-credentials
CI secret store	Deployment-token og injicerede rotationsværdier
Managed database-output	Connection-data, der overdrages til den forbrugende service
Lokal .env	Udviklerværdier, der er udeladt fra Git

dockup.yaml apply er som standard additiv. Almindelige miljøværdier, der ikke findes i filen, bevares, indtil --prune bruges eksplicit, og secrets fjernes aldrig via denne sti. Gennemgå dockup.yaml som config as code, før du tager oprydning i manifests i brug.

Brug ensartede key-navne på tværs af miljøer, men antag ikke, at værdierne kan udskiftes. En staging-key må ikke give adgang til produktion. Preview-deployments i et projekt med private networking får automatisk oprettet en read-only databasebruger til adgang til produktionsdata; de bør ikke som standard arve write-credentials.

Incident response ved en lækket secret

Hvis en secret optræder i en transskription, log, commit eller et screenshot, er det ikke nok at maskere den senere. Behandl den som kompromitteret:

1. Tilbagekald eller rotér den i kildesystemet.
2. Opdatér Dockup-secreten.
3. Deploy igen, og verificér resultatet.
4. Fjern det eksponerede materiale, hvor det er muligt.
5. Søg efter misbrug i audit- og access-logs.
6. Dokumentér årsagen og ændringen, der skal forhindre gentagelse.

Omskrivning af Git-historikken kan gøre fremtidig opdagelse mindre sandsynlig, men kan ikke bevise, at en kopieret credential er forsvundet. Tilbagekaldelse er den afgørende handling.

Tjekliste til miljøgennemgang

Før hver produktionsrelease skal du verificere, at de nødvendige keys findes, at secret-keys er markeret som secrets, at ingen secret er committed, at almindelige værdier matcher det tilsigtede miljø, og at en genudrulning er en del af ændringen. Kontrollér derefter status og uptime:

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

Monitoring kører hvert minut og omfatter p95-responstid. En vellykket konfigurations-deployment bør stadig overvåges for regressioner under runtime.

Følg Git-repository til produktion for oprettelse af services og den indledende opsætning.

Validér konfiguration uden at afsløre den

Applikationer bør fejle tydeligt, når en påkrævet key mangler, men diagnostics må ikke udskrive værdien. Et starttjek kan rapportere en liste som missing: ["DATABASE_URL"] eller invalid format: ["PUBLIC_URL"] og derefter afslutte med en exit-kode, der ikke er nul.

For en valgfri værdi skal du definere fallback-værdien i koden og dokumentere, om fallback-værdien er sikker i produktion. Stille development-defaults – lokale databasehosts, debug modes, tilladelig CORS eller testcredentials – bør ikke aktiveres, blot fordi en produktionskey mangler.

Denne validering gør miljøvariabler og secrets observerbare uden at gøre logs til et credential-register.

Håndtér flere services og delte credentials bevidst

Hvis du kopierer én secret til flere services, skaber det en rotationsafhængighed. Foretræk servicespecifikke credentials, når det eksterne system understøtter dem. En kompromitteret worker-token bør ikke give samme adgang som den offentlige API.

Når en delt værdi ikke kan undgås, skal du vedligeholde en liste over ejer og forbrugere. Rotér alle forbrugere i et koordineret tidsvindue, og verificér nye forbindelser efter hver genudrulning. Bed ikke en agent om at “finde alle services, der sandsynligvis bruger denne key” ud fra navnelighed; brug en eksplicit fortegnelse og auditspor.

Private networking kan reducere eksponeringen af databasetrafik, men gør ikke credentials unødvendige. Interne hostnames styrer stien; authentication styrer, hvem der må bruge databasen.

Start med en deployment, der kan verificeres

Klassificér hver key, før du angiver den, verificér, at secret-læsninger er maskeret, og medtag den nødvendige genudrulning i den samme ændring, der er blevet gennemgået.

Start gratis på app.dockup.ai. Free-planen koster $0 om måneden, inkluderer $10 i startkredit og understøtter ét workspace, tre databaser og tre deployments.

FAQ

Returnerer Dockup gemte secret-værdier?

Nej. Secret-værdier maskeres i output fra læseoperationer. Keys og secret-markører forbliver synlige, så operatører kan verificere, at den nødvendige konfiguration findes.

Hvorfor skal jeg deploye igen efter at have ændret en miljøvariabel?

Den kørende proces modtog sit miljø ved opstart. En ny deployment opretter en ny container med de opdaterede værdier og verificerer den gennem health gate.

Kan jeg lægge secrets i dockup.yaml?

Nej. Brug dockup.yaml til almindelig konfiguration, der kan gennemgås, og brug secret-miljøkommandoer eller CI-secret-injektion til credentials.

Hvordan importerer jeg flere miljøvariabler?

Brug dockup env import med en .env-fil og det specifikke servicetarget. Brug kun importens --secret-option, når alle importerede værdier er secrets.

Hvad skal jeg gøre, hvis en secret eksponeres i en log?

Tilbagekald eller rotér den straks, opdatér Dockup-secreten, deploy igen, undersøg access-logs, og ret den proces, der gjorde eksponeringen mulig.