En ny udvikler bliver ansat, eller en konsulent starter, og det første,
udvikleren skal bruge, er den .env-fil, der får projektet til at køre. Filen er
som regel en blanding af harmløse indstillinger og de mest følsomme
værdier, teamet har, og derfor ender den så tit i en direkte besked
eller som vedhæftet fil i en e-mail med emnet ”config”.
For at levere en konfigurationsfil sikkert til en udvikler skal du se den som to ting: indstillinger, der kan sendes hvordan som helst, og hemmeligheder, der sendes én gang gennem en kanal, som ikke gemmer kopier. Denne guide viser, hvordan du deler filen i to, hvordan du sender den hemmelige halvdel, og hvad du skal sige til udvikleren, så filen forbliver sikker, når den er nået frem.
Læs filen, som om hver linje var offentlig
Åbn filen, og sorter hver linje i en af to grupper.
- Indstillinger: logniveauer, porte, feature flags, endpoints uden for produktion, offentlige klient-id'er. De hører hjemme i repositoriet som en eksempelfil og kan sendes, som du vil.
- Hemmeligheder: databaseadgangskoder, API-nøgler, signeringsnøgler,
private nøgler, OAuth client secrets og alt andet, der giver adgang.
Søg efter
PASSWORD,SECRET,TOKEN,KEYogPRIVATE, og læs derefter resten, for en forbindelsesstreng med adgangskoden indbygget afslører sig ikke selv.
Spørg derefter, hvad udvikleren skal lave. Lokal udvikling mod staging kræver staging-værdierne. Det kræver ikke produktionsnøgler, og det kræver ikke betalingsudbyderens live-nøgle, bare fordi filen tilfældigvis indeholder en.
Hold hemmeligheder ude af den committede fil
Den committede .env.example dokumenterer hver variabel med en
pladsholder. De rigtige værdier indsættes ved kørsel fra miljøet, en
secrets manager eller platformens eget lager til hemmeligheder. Med det
mønster er det kun de hemmelige værdier, du skal levere, og udviklerens
lokale kopi er det eneste sted, hvor de findes samlet.
# .env.example (committed)
DATABASE_URL=postgres://app:CHANGE_ME@staging-db.internal:5432/app
STRIPE_SECRET_KEY=sk_test_CHANGE_ME
SESSION_SECRET=CHANGE_ME
LOG_LEVEL=debug
Tilføj .env til .gitignore, før nogen har en rigtig, og overvej en
pre-commit hook som gitleaks, så et utilsigtet commit fejler med det
samme.
Giv udvikleren egne loginoplysninger, hvor du kan
En overdragelse er også en anledning til at holde op med at dele. Hvis databasen understøtter individuelle brugere, så opret en til udvikleren med de tilladelser, arbejdet kræver, og en udløbsdato. Hvis API'et tilbyder begrænsede nøgler, så udsted en i udviklerens navn. Guiden om databaselogin til konsulenter gennemgår det mønster. Loginoplysninger, der er lavet til én person, kan fjernes for én person.
Sådan leverer du de hemmelige værdier
To metoder virker, og ingen af dem efterlader filen i en besked.
Indsæt de hemmelige linjer i et engangslink. Åbn værktøjet til
hemmelige links, indsæt kun de
linjer, der indeholder hemmeligheder, og opret linket. Teksten krypteres
i din browser, før den gemmes, den gemte kopi destrueres, første gang
linket åbnes, og linket udløber efter en time, 24 timer eller syv dage,
hvis ingen åbner det. Uden konto er der plads til 10.000 tegn, hvilket
rækker til de fleste .env-filer flere gange.
Vedhæft hele filen til et hemmeligt link. Fra en LinkPilot-konto, hvor du er logget ind, kan du vedhæfte op til tre filer på hver 9 MB til en hemmelighed. Hver fil krypteres i din browser med en nøgle, der er afledt af hemmelighedens egen nøgle, så serveren aldrig har den ukrypterede fil, og den vedhæftede fil slettes efter den ene download. Det er den bedste metode, når filen skal komme frem byte for byte, for eksempel en JSON-fil til en servicekonto eller et keystore.
Uanset metode:
- Bekræft udviklerens identitet gennem kanalen fra ansættelsen eller kontrakten, ikke via den adresse, der bad om filen.
- Sæt udløbet til det tidsrum, udvikleren faktisk vil bruge. En time, hvis udvikleren sidder og venter, en dag, hvis udvikleren er i en anden tidszone.
- Sæt grænsen for visninger til én.
- Tilføj en adgangssætning med en Pro-konto til produktionsværdier, og send den via en anden kanal.
- Send linket med en kort note om, hvad det er, og hvor filen hører hjemme. Send de ikke-hemmelige indstillinger for sig, eller henvis til eksempelfilen i repositoriet.
En invitation til en boks er den bedste vej, når udvikleren er fastansat, og teamet allerede bruger en secrets manager med adgang pr. udvikler. Brug engangslinket i tiden, før det er sat op, og til dem, der aldrig kommer ind i boksen.
Fortæl udvikleren, hvor filen hører hjemme
En ren levering kan stadig ende galt, hvis filen havner i en delt mappe. Send disse punkter sammen med forbindelsesoplysningerne:
- Gem den som
.envi projektets rodmappe og ingen andre steder. Tjek, at.gitignoredækker den, før det første commit. - Indsæt ikke værdier i tickets eller chat for at spørge, om de er rigtige. Meld en manglende eller ugyldig variabel med navnet alene, så udsteder afsenderen en ny værdi.
- Værdierne skiftes ved afgang. Når samarbejdet slutter, bliver værdierne i filen skiftet. Sig det fra starten, så ingen bliver overrasket.
Bekræft, og ryd derefter op
Bed udvikleren bekræfte filnavnet, miljøet og en ikke-hemmelig markør, for eksempel en versionskommentar i første linje. Hvis et engangslink viser, at det blev åbnet, før udvikleren nåede det, så betragt alle værdier i det som afsløret, og skift dem.
Når overdragelsen er færdig, så tilbagekald alle links, der aldrig blev åbnet, fjern alle midlertidige kopier, du har lavet, og noter, hvem der fik hvilket miljøs værdier og hvornår. Den note er revisionssporet. Selve filen bør kun findes på den maskine, der har brug for den.