OpenVPN-profil i Git: hva som må fjernes før du committer

Profiler tjener to formål samtidig: de registrerer tilkoblingsinnstillingene, og de bærer et fungerende sett med påloggingsdetaljer. Filendelsen forteller deg ingenting om hvilken av de to du holder i hånden. Les innholdet før du bestemmer at det hører hjemme i et depot.

Trinnene nedenfor forutsetter at en klientmal vurderes for versjonskontroll. Kjør dem i rekkefølge, og stopp før du committer noe du ikke kan tilbakekalle.

Les filen du er i ferd med å indeksere

Start med de faktiske bytene, for en profil som viser til separate filer ser helt annerledes ut enn en som bygger dem inn. Søk etter PEM-blokkmarkørene og de innebygde tagene som heter ca, cert, key, tls-auth og tls-crypt, og samme gjennomgang viser deg begge tilfellene. En kryptert privatnøkkel regnes fortsatt som sensitivt materiale, og en delt tls-auth- eller tls-crypt-nøkkel er en påloggingsdetalj selv om den ikke er en brukers identitet. Bruk samme gjennomgang på alt som indekseres sammen med profilen, inkludert arkiver og oppsettskript som viser til en påloggingsfil.

Se deretter på det indekserte settet i stedet for arbeidstreet. git diff --cached viser hva commiten faktisk vil inneholde, og det er den eneste versjonen som betyr noe for denne avgjørelsen.

Avgjør hva depotet kan distribuere

En mal kan bære de delte, gjennomgåtte innstillingene og navngitte plassholdere for alt en person mottar ved registrering. Det den ikke kan bære, er en brukbar identitet, fordi et depot distribueres til alle som kan lese det, automatisering inkludert. Et privat depot snevrer inn publikum uten å endre spørsmålet om hver leser er autorisert for den påloggingsdetaljen.

En ignoreringsregel hindrer fremtidige tillegg og gjør ingenting med det som allerede er registrert. Den asymmetrien er verdt å internalisere før den første commiten og ikke etter den tiende. Navn og adresser til infrastruktur er en egen vurdering: de er ikke autentiseringshemmeligheter, men de kan avsløre mer enn et team har tenkt å publisere. Ta den avgjørelsen eksplisitt i stedet for å sortere hver linje i passord eller offentlig.

Hvis materialet allerede er i historikken

Å fjerne linjen i en ny commit lar den gamle versjonen være intakt for alle som henter den. Behandle eksponeringen som reell: identifiser typen påloggingsdetalj, og finn deretter myndigheten som kan ugyldiggjøre den. Et klientsertifikat tilbakekalles og tilbakekallingslisten genereres på nytt; en delt nøkkel for kontrollkanalen erstattes på serveren og på hver klient som bruker den.

De to har svært ulikt skadeomfang, og planen bør angi hvilken du utfører før du begynner. Finn commiten som innførte materialet med et søk av typen git log --all -S 'BEGIN PRIVATE KEY', slik at omfanget av opprydningen er kjent og ikke gjettet. En kollegas klon eller en fork kan allerede ha det gamle objektet, og derfor kommer tilbakekallingen først og opprydningen etterpå.

Rydd bare etter at det er begrenset

Omskriving av historikken endrer hver commit etter den du redigerer, så den trenger først enighet fra depotets eier og menneskene som arbeider i det. En tvunget push er ikke en reparasjon; det er en koordineringshendelse med sin egen risiko for tilbakerulling. Planlegg den, ta en sikkerhetskopi, og fortell teamet når den skjer.

Etterpå bør du verifisere det gjeldende treet og den gjenværende historikken i stedet for å stole på verktøyets oppsummering.

Ta vare på resultatet som to artefakter: malen som er trygg å dele, og oversikten over påloggingsdetaljer som er utstedt gjennom registreringsprosessen. Ingen av dem krever at en brukbar identitet bor i depotet.

Den delingen er den egentlige løsningen, og den overlever den neste personen som vil committe en profil.