Omgevingsvariabelen en secrets op Dockup

Omgevingsvariabelen en secrets verbinden applicatiecode met productieconfiguratie, maar hebben verschillende vereisten voor openbaarmaking en lifecyclebeheer. Een openbare API-basis-URL kan veilig in logs worden weergegeven; een databasewachtwoord of signing key niet. Dockup maakt dat onderscheid expliciet en maskeert opgeslagen secretwaarden in leesuitvoer.

Voor configuratiewijzigingen is ook een nieuwe deployment nodig. Door een nieuwe waarde in te stellen, wordt de gewenste serviceconfiguratie bijgewerkt, maar het al draaiende proces behoudt de omgeving die het bij de start heeft ontvangen.

Wat is het verschil tussen een variabele en een secret?

Beide waarden komen als omgevingsdata het applicatieproces binnen, maar de operationele verwerking verschilt.

Type	Voorbeeld	Mag in leesuitvoer verschijnen?	Aanbevolen verwerking
Gewone variabele	NODE_ENV=production	Ja	Controleerbare configuratie
Gewone variabele	PUBLIC_API_URL=https://...	Ja	Mag in dockup.yaml staan
Secret	DATABASE_URL=postgres://...	Geen opgeslagen waarde	Secretopdracht of CI-store
Secret	JWT_SIGNING_KEY=...	Geen opgeslagen waarde	Roteer en beperk toegang
Secret	DOCKUP_TOKEN=...	Nooit als appconfiguratie opslaan, tenzij vereist	Authenticatie op procesniveau

Markeer een waarde als secret wanneer openbaarmaking toegang, impersonatie, decryptie, signing of laterale verplaatsing mogelijk zou maken. “De frontend bevat het al” is een teken dat de waarde openbare configuratie is en geen secret.

Zet secrets niet in source control, dockup.yaml, voorbeelduitvoer, screenshots, agentprompts of issuebeschrijvingen. Een geredigeerde placeholder is veiliger dan een realistisch ogende token, omdat gekopieerde voorbeelden al snel onderdeel worden van de productiepraktijk.

Hoe stel je omgevingsconfiguratie in en inspecteer je die?

Bekijk de huidige keys voor een exact target:

dockup env list -s production/api --json

De respons bevat elke key, of deze secret is en de waarde alleen wanneer die niet is beveiligd.

Stel een gewone variabele in:

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

Stel een secret in vanuit de huidige shellomgeving:

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

Verwijder een verouderde waarde:

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

Importeer in bulk een bestand in .env-stijl:

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

Gebruik --secret bij het importeren alleen wanneer elke geïmporteerde waarde als secret moet worden behandeld. Gemengde bestanden zijn moeilijker te controleren en moedigen vaak aan tot het onnodig classificeren van onschadelijke configuratie of het onvoldoende classificeren van inloggegevens. Splits ze waar mogelijk op.

De exacte commandoset wordt bijgehouden in de Dockup CLI reference.

Waarom is na configuratiewijzigingen een nieuwe deployment nodig?

Omgevingsvariabelen worden gelezen wanneer een proces start. Het bijwerken van platformconfiguratie wijzigt het geheugen van een draaiend Node.js-, Python-, Go- of ander proces niet. De service moet een nieuwe container starten met de nieuwe omgeving.

De juiste volgorde is:

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

dockup deploy production/api --wait --json

Met --wait kun je de tweede stap verifiëren. De standaardtime-out is 900 seconden, exit 0 betekent succes en bij fouten wordt een non-zero-waarde met gestructureerde codes geretourneerd.

Dockup’s zero-downtime blue-green-proces start de nieuwe versie, voert de health gate uit en verplaatst daarna pas het verkeer. Zo wordt voorkomen dat de huidige container ter plekke wordt herstart met niet-geverifieerde configuratie.

Als een secret rotation zowel de producer als de consumer wijzigt, plan dan compatibiliteit in. Het roteren van een databasewachtwoord voordat de applicatie de nieuwe waarde ontvangt, kan een storing veroorzaken. Gebruik een overlapperiode, ondersteuning voor dual keys of een geordende wijziging wanneer het externe systeem dit toestaat.

De deploymentmechanismen worden uitgelegd in zero-downtime deployments.

Hoe vermindert secret masking het risico voor agents?

Coding agents vatten commandoutput vaak samen. Een tool die opgeslagen secrets retourneert, verandert een onschuldig verzoek als “toon de huidige configuratie” in het blootleggen van inloggegevens.

Dockup maskeert secretwaarden. De agent kan zien dat DATABASE_URL bestaat en als secret is gemarkeerd, maar kan de opgeslagen connection string niet lezen. De agent kan de waarde vervangen wanneer de gebruiker via een veilige omgeving een nieuwe waarde aanlevert.

Dit ondersteunt een veiligere instructie:

Bevestig dat de vereiste secretkeys bestaan, maar druk hun waarden nooit af. Als een waarde moet worden gewijzigd, lees deze dan alleen uit de procesomgeving en retourneer de keynaam, niet de secret.

Secret masking moet ook gelden voor diagnostics. Vermijd:

printenv

in een agenttranscript, ook al kan de PRO-opdracht exec eenmalige containeropdrachten uitvoeren. Geef de voorkeur aan een gerichte applicatiecontrole die aanwezigheid, een lengteklasse of succesvolle verbinding rapporteert zonder de waarde openbaar te maken.

De handleiding AI agent production guardrails behandelt prompt- en toolgrenzen samen.

Hoe roteer en controleer je secrets?

Rotation is een gecontroleerde productiewijziging, geen tekstbewerking. Gebruik deze volgorde:

1. Maak de nieuwe credential aan of haal deze op in het systeem dat eigenaar is.
2. Sla deze op in de goedgekeurde CI- of operatoromgeving.
3. Stel de nieuwe secret in Dockup in zonder deze af te drukken.
4. Implementeer opnieuw met --wait.
5. Controleer de health en het gedrag van de applicatie.
6. Trek de oude credential in nadat de nieuwe versie actief is.
7. Controleer het auditlog van Dockup.
8. Leg de rotatiedatum en eigenaar vast zonder de waarde te registreren.

dockup audit --writes --json

Auditbewijs moet aantonen dat de configuratie is gewijzigd en dat daarna een deployment heeft plaatsgevonden. Het mag de secretwaarde niet bevatten.

Houd bij databasecredentials rekening met connection pools. Bestaande verbindingen kunnen na de rotation geauthenticeerd blijven, terwijl nieuwe verbindingen het nieuwe wachtwoord gebruiken. Bij de verificatie moet daarom een nieuwe verbinding worden meegenomen, niet alleen requests die door een oude pool worden afgehandeld.

Leg bij API-keys met rechten de gegenereerde waarde veilig vast tijdens het aanmaken. Sla deze onmiddellijk op in het goedgekeurde secretsysteem, beperk de key tot de vereiste rechten en roteer deze zonder de waarde opnieuw op te nemen in deploymentoutput.

Welk configuratiebeleid voorkomt drift?

Definieer welke waarden bij elke bron horen:

Bron	Geschikte inhoud
Repositorycode	Standaardwaarden die niet omgevingsspecifiek zijn
dockup.yaml	Controleerbare, gewone deploymentconfiguratie
Dockup-secretvariabelen	Runtime-credentials
CI-secretstore	Deploymenttoken en geïnjecteerde rotatiewaarden
Output van beheerde database	Verbindingsgegevens die aan de consumerende service worden doorgegeven
Lokale .env	Alleen ontwikkelaarswaarden, uitgesloten van Git

dockup.yaml apply is standaard additief. Gewone omgevingswaarden die niet in het bestand staan, blijven behouden totdat --prune expliciet wordt gebruikt, en secrets worden nooit via die route opgeschoond. Lees dockup.yaml config as code voordat je manifestopruiming invoert.

Gebruik consistente keynamen in verschillende omgevingen, maar ga er niet van uit dat waarden uitwisselbaar zijn. Een staging-key mag geen toegang tot productie verlenen. Preview-deployments in een project met private networking krijgen automatisch een read-only databasegebruiker voor toegang tot productiegegevens; standaard mogen ze geen write-credentials overnemen.

Incidentrespons voor een gelekte secret

Als een secret in een transcript, log, commit of screenshot verschijnt, is achteraf maskeren niet voldoende. Behandel de secret als gecompromitteerd:

1. Trek de secret in of roteer deze in het bronsysteem.
2. Werk de Dockup-secret bij.
3. Implementeer opnieuw en verifieer.
4. Verwijder het blootgestelde materiaal waar mogelijk.
5. Zoek in audit- en toegangslogs naar misbruik.
6. Documenteer de oorzaak en de preventieve wijziging.

Het herschrijven van de Git-geschiedenis kan toekomstige ontdekking beperken, maar bewijst niet dat een gekopieerde credential verdwenen is. Intrekking is de doorslaggevende actie.

Checklist voor omgevingscontrole

Controleer vóór elke productierelease of de vereiste keys bestaan, secretkeys als secret zijn gemarkeerd, geen secret is gecommit, gewone waarden overeenkomen met de beoogde omgeving en een nieuwe deployment onderdeel is van de wijziging. Controleer daarna de status en uptime:

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

Monitoring wordt elke minuut uitgevoerd en omvat de p95-responstijd. Ook een geslaagde configuratiedeployment moet worden gemonitord op runtime-regressies.

Volg voor het aanmaken van een service en de eerste configuratie Git repository to production.

Configuratie valideren zonder deze openbaar te maken

Applicaties moeten duidelijk falen wanneer een vereiste key ontbreekt, maar diagnostics mogen de waarde niet afdrukken. Een startupcontrole kan bijvoorbeeld een lijst rapporteren als missing: ["DATABASE_URL"] of invalid format: ["PUBLIC_URL"] en vervolgens met een non-zero-waarde afsluiten.

Definieer voor een optionele waarde de fallback in de code en documenteer of deze fallback veilig is in productie. Stille development-defaults—lokale databasehosts, debugmodi, permissieve CORS of testcredentials—mogen niet alleen worden geactiveerd omdat een productiesleutel ontbreekt.

Deze validatie maakt omgevingsvariabelen en secrets observeerbaar zonder logs in een inventaris van inloggegevens te veranderen.

Meerdere services en gedeelde credentials bewust beheren

Het kopiëren van één secret naar meerdere services creëert een rotatieafhankelijkheid. Geef waar mogelijk de voorkeur aan servicespecifieke credentials als het externe systeem deze ondersteunt. Een gecompromitteerde workertoken mag niet dezelfde toegang verlenen als de publieke API.

Wanneer een gedeelde waarde onvermijdelijk is, houd dan een lijst bij van de eigenaar en de consumers. Roteer alle consumers binnen een gecoördineerd tijdvenster en controleer na elke nieuwe deployment verse verbindingen. Vraag een agent niet om op basis van naamovereenkomst “elke service te vinden die deze key waarschijnlijk gebruikt”; gebruik een expliciete inventaris en auditbewijs.

Private networking kan de blootstelling van databasetraffic beperken, maar maakt credentials niet overbodig. Interne hostnamen bepalen de route; authenticatie bepaalt wie de database mag gebruiken.

Begin met een verifieerbare deployment

Classificeer elke key voordat je deze instelt, controleer of secretreads worden gemaskeerd en neem de vereiste nieuwe deployment op in dezelfde gecontroleerde wijziging.

Start gratis op app.dockup.ai. Het Free-abonnement kost $0 per maand, bevat $10 aan starttegoed en ondersteunt één workspace, drie databases en drie deployments.

FAQ

Retourneert Dockup opgeslagen secretwaarden?

Nee. Secretwaarden worden in leesuitvoer gemaskeerd. Keys en secretmarkeringen blijven zichtbaar, zodat operators kunnen controleren of de vereiste configuratie bestaat.

Waarom moet ik opnieuw deployen nadat ik een omgevingsvariabele heb gewijzigd?

Het draaiende proces heeft de omgeving bij de start ontvangen. Een nieuwe deployment maakt een nieuwe container met de bijgewerkte waarden en verifieert deze via de health gate.

Kan ik secrets in dockup.yaml zetten?

Nee. Gebruik dockup.yaml voor gewone, controleerbare configuratie en gebruik secretomgevingsopdrachten of CI-secretinjectie voor credentials.

Hoe importeer ik meerdere omgevingsvariabelen?

Gebruik dockup env import met een bestand in .env-stijl en het exacte servicetarget. Gebruik de optie import --secret alleen wanneer alle geïmporteerde waarden secrets zijn.

Wat moet ik doen als een secret in een log wordt blootgesteld?

Trek de secret onmiddellijk in of roteer deze, werk de Dockup-secret bij, deploy opnieuw, onderzoek de toegangslogs en herstel het proces waardoor de openbaarmaking kon plaatsvinden.