Variabile de mediu și secrete în Dockup

Variabilele de mediu și secretele fac legătura dintre codul aplicației și configurația de producție, însă au cerințe diferite privind divulgarea și ciclul de viață. Un URL public de bază pentru API poate fi afișat în siguranță în loguri; o parolă de bază de date sau o cheie de semnare, nu. Dockup reprezintă explicit această distincție și maschează valorile secrete stocate în rezultatele comenzilor de citire.

Modificările de configurație necesită și un redeployment. Setarea unei valori noi actualizează configurația dorită a serviciului, însă procesul care rulează deja păstrează mediul primit la pornire.

Care este diferența dintre o variabilă și un secret?

Ambele valori ajung în procesul aplicației sub formă de date de mediu, însă modul lor de gestionare operațională diferă.

Tip	Exemplu	Poate apărea în rezultatele comenzilor de citire?	Gestionare recomandată
Variabilă simplă	NODE_ENV=production	Da	Configurație ușor de verificat
Variabilă simplă	PUBLIC_API_URL=https://...	Da	Poate fi inclusă în dockup.yaml
Secret	DATABASE_URL=postgres://...	Nicio valoare stocată	Comandă pentru secrete sau CI store
Secret	JWT_SIGNING_KEY=...	Nicio valoare stocată	Rotește și restricționează
Secret	DOCKUP_TOKEN=...	Nu o stoca niciodată ca configurație a aplicației decât dacă este necesar	Autentificare la nivel de proces

Marchează o valoare ca secret atunci când divulgarea ei ar permite accesul, impersonarea, decriptarea, semnarea sau deplasarea laterală. „Frontend-ul o conține deja” indică faptul că valoarea este configurație publică, nu secret.

Nu include secrete în controlul versiunilor, dockup.yaml, rezultatele exemplificate, capturi de ecran, prompturi pentru agenți sau descrieri de issue-uri. Un placeholder redactat este mai sigur decât un token care pare realist, deoarece exemplele copiate tind să devină practici de producție.

Cum setezi și inspectezi configurația mediului?

Listează cheile curente pentru o țintă exactă:

dockup env list -s production/api --json

Răspunsul include fiecare cheie, indică dacă este secretă și afișează valoarea doar atunci când aceasta nu este protejată.

Setează o variabilă obișnuită:

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

Setează un secret din mediul shell-ului curent:

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

Elimină o valoare învechită:

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

Importă în bloc un fișier în stil .env:

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

Folosește --secret la import doar atunci când fiecare valoare importată trebuie tratată ca secret. Fișierele mixte sunt mai greu de verificat și încurajează adesea fie clasificarea excesivă a configurației inofensive, fie clasificarea insuficientă a credentialelor. Separă-le atunci când este posibil.

Lista exactă a comenzilor este menținută în referința CLI Dockup.

De ce este necesar un redeployment după modificarea configurației?

Variabilele de mediu sunt citite la pornirea procesului. Actualizarea configurației platformei nu modifică memoria unui proces Node.js, Python, Go sau a altui proces care rulează deja. Serviciul trebuie să pornească un container nou cu noul mediu.

Secvența corectă este:

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

dockup deploy production/api --wait --json

--wait face ca al doilea pas să poată fi verificat. Timeout-ul implicit este de 900 de secunde, codul de ieșire 0 indică succesul, iar erorile returnează o valoare diferită de zero împreună cu coduri structurate.

Procesul blue-green fără downtime al Dockup pornește versiunea nouă, aplică verificarea de health și abia apoi redirecționează traficul. Astfel, containerul curent nu este repornit pe loc cu o configurație neverificată.

Dacă rotirea unui secret modifică atât producătorul, cât și consumatorul, planifică compatibilitatea. Rotirea parolei bazei de date înainte ca aplicația să primească noua valoare poate provoca o întrerupere. Folosește o perioadă de suprapunere, suport pentru două chei sau o modificare ordonată atunci când sistemul extern permite acest lucru.

Mecanismele de deployment sunt explicate în deployment-uri fără downtime.

Cum reduce mascarea secretelor riscurile asociate agenților?

Agenții de coding rezumă frecvent rezultatele comenzilor. Un tool care returnează secretele stocate transformă o solicitare inofensivă de tipul „arată configurația curentă” într-o expunere de credentiale.

Dockup maschează valorile secrete. Agentul poate vedea că DATABASE_URL există și este marcată drept secretă, însă nu poate citi stringul de conexiune stocat. Valoarea poate fi înlocuită atunci când utilizatorul furnizează una nouă printr-un mediu securizat.

Acest lucru permite o instrucțiune mai sigură:

Confirmă că există cheile secrete necesare, dar nu le afișa niciodată valorile. Dacă o valoare trebuie modificată, citește-o doar din mediul procesului și returnează numele cheii, nu secretul.

Mascarea secretelor ar trebui să se extindă și la diagnosticare. Evită:

printenv

într-o transcriere a agentului, chiar dacă comanda PRO exec poate rula comenzi one-shot în containere. Preferă o verificare țintită la nivelul aplicației, care raportează prezența, categoria de lungime sau succesul conexiunii fără să divulge valoarea.

Ghidul măsurilor de protecție pentru agenții AI în producție tratează împreună limitele prompturilor și ale tool-urilor.

Cum ar trebui rotite și auditate secretele?

Rotirea este o modificare controlată în producție, nu o editare de text. Folosește această secvență:

1. Creează sau obține credentialul nou în sistemul care îl gestionează.
2. Stochează-l în mediul aprobat pentru CI sau operatori.
3. Setează noul secret în Dockup fără să-l afișezi.
4. Fă deployment cu --wait.
5. Verifică starea de sănătate și comportamentul aplicației.
6. Revocă credentialul vechi după ce versiunea nouă este activă.
7. Verifică audit log-ul Dockup.
8. Înregistrează data rotirii și responsabilul, fără a înregistra valoarea.

dockup audit --writes --json

Dovezile de audit ar trebui să arate că configurația s-a modificat și că a urmat un deployment. Nu ar trebui să conțină valoarea secretului.

Pentru credentialele bazei de date, ia în considerare connection pool-urile. Conexiunile existente pot rămâne autentificate după rotire, în timp ce conexiunile noi folosesc parola nouă. Verificarea ar trebui să includă o conexiune nouă, nu doar request-uri deservite de un pool vechi.

Pentru cheile API cu permisiuni, capturează valoarea generată în siguranță în momentul creării. Stocheaz-o imediat în sistemul de secrete aprobat, limitează-o la permisiunile necesare și rotește-o fără a o reproduce în output-ul deployment-ului.

Ce politică de configurare previne drift-ul?

Definește ce valori aparțin fiecărei surse:

Sursă	Conținut adecvat
Codul din repository	Valori implicite care nu depind de mediu
dockup.yaml	Configurație de deployment simplă, ușor de verificat
Variabilele secrete Dockup	Credentiale de runtime
CI secret store	Tokenul de deployment și valorile injectate pentru rotire
Output-ul bazei de date gestionate	Date de conexiune transmise serviciului consumator
.env local	Valori exclusiv pentru dezvoltatori, excluse din Git

Aplicarea dockup.yaml este aditivă în mod implicit. Valorile simple de mediu care nu se află în fișier rămân până când se folosește explicit --prune, iar secretele nu sunt eliminate niciodată prin această cale. Consultă configurația ca cod cu dockup.yaml înainte de a adopta curățarea manifestului.

Folosește nume de chei consecvente între medii, dar nu presupune că valorile sunt interschimbabile. O cheie de staging nu ar trebui să ofere acces la producție. Deployment-urile de preview dintr-un proiect cu networking privat primesc un utilizator de bază de date read-only creat automat pentru acces la datele de producție; în mod implicit, nu ar trebui să moștenească credentiale de write.

Răspunsul la incidente pentru un secret divulgat

Dacă un secret apare într-o transcriere, într-un log, într-un commit sau într-o captură de ecran, mascarea lui ulterioară nu este suficientă. Consideră-l compromis:

1. Revocă-l sau rotește-l în sistemul sursă.
2. Actualizează secretul din Dockup.
3. Fă redeploy și verifică.
4. Elimină materialul expus acolo unde este posibil.
5. Caută semne de utilizare abuzivă în logurile de audit și de acces.
6. Documentează cauza și modificarea preventivă.

Rescrierea istoricului Git poate reduce șansele de descoperire ulterioară, dar nu poate demonstra că un credential copiat a dispărut. Revocarea este acțiunea decisivă.

Checklist pentru verificarea mediului

Înaintea fiecărui release în producție, verifică existența cheilor necesare, marcarea cheilor secrete ca secrete, faptul că niciun secret nu este inclus în commit-uri, corespondența valorilor simple cu mediul vizat și includerea unui redeployment în aceeași modificare verificată. Apoi verifică statusul și uptime-ul:

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

Monitorizarea rulează în fiecare minut și include timpul de răspuns p95. Chiar și un deployment de configurație reușit ar trebui urmărit pentru a identifica regresii de runtime.

Pentru crearea serviciilor și configurarea inițială, urmează De la repository Git la producție.

Validează configurația fără să o divulgi

Aplicațiile ar trebui să eșueze clar atunci când lipsește o cheie necesară, însă diagnosticarea nu trebuie să afișeze valoarea. O verificare la pornire poate raporta o listă precum missing: ["DATABASE_URL"] sau invalid format: ["PUBLIC_URL"], apoi poate ieși cu un cod diferit de zero.

Pentru o valoare opțională, definește fallback-ul în cod și documentează dacă acesta este sigur în producție. Valorile implicite silențioase de dezvoltare — host-uri locale de baze de date, moduri de depanare, CORS permisiv sau credentiale de test — nu ar trebui activate doar pentru că lipsește o cheie de producție.

Această validare face ca variabilele de mediu și secretele să fie observabile fără a transforma logurile într-un inventar de credentiale.

Gestionează deliberat mai multe servicii și credentialele partajate

Copierea aceluiași secret în mai multe servicii creează o dependență de rotire. Preferă credentiale specifice fiecărui serviciu atunci când sistemul extern le acceptă. Un token compromis al unui worker nu ar trebui să ofere același nivel de acces ca API-ul public.

Atunci când o valoare partajată este inevitabilă, menține o listă cu responsabilul și consumatorii. Rotește toate serviciile într-o fereastră coordonată și verifică conexiunile noi după fiecare redeploy. Nu solicita unui agent să „găsească fiecare serviciu care probabil folosește această cheie” pe baza asemănării numelor; folosește un inventar explicit și dovezi de audit.

Networking-ul privat poate reduce expunerea traficului către baza de date, însă nu elimină necesitatea credentialelor. Hostname-urile interne controlează ruta; autentificarea controlează cine poate utiliza baza de date.

Începe cu un deployment verificabil

Clasifică fiecare cheie înainte de a o seta, verifică faptul că citirile secretelor sunt mascate și include redeployment-ul necesar în aceeași modificare verificată.

Începe gratuit pe app.dockup.ai. Planul Free costă 0 $ pe lună, include un credit inițial de 10 $ și oferă suport pentru un workspace, trei baze de date și trei deployment-uri.

Întrebări frecvente

Returnează Dockup valorile secrete stocate?

Nu. Valorile secrete sunt mascate în rezultatele comenzilor de citire. Cheile și marcajele pentru secrete rămân vizibile, astfel încât operatorii să poată verifica existența configurației necesare.

De ce trebuie să fac redeploy după modificarea unei variabile de mediu?

Procesul care rulează a primit mediul la pornire. Un deployment nou creează un container nou cu valorile actualizate și îl verifică prin health gate.

Pot include secrete în dockup.yaml?

Nu. Folosește dockup.yaml pentru configurație simplă, ușor de verificat, iar pentru credentiale folosește comenzile pentru secrete de mediu sau injectarea secretelor prin CI.

Cum import mai multe variabile de mediu?

Folosește dockup env import cu un fișier în stil .env și ținta exactă a serviciului. Folosește opțiunea import --secret numai atunci când toate valorile importate sunt secrete.

Ce ar trebui să fac dacă un secret este expus într-un log?

Revocă-l sau rotește-l imediat, actualizează secretul din Dockup, fă redeploy, investighează logurile de acces și remediază procesul care a permis divulgarea.