Profili OpenVPN në Git: çfarë të hiqet para commit-it

Profilet shërbejnë për dy qëllime njëkohësisht: regjistrojnë cilësimet e lidhjes dhe mbajnë një grup kredencialesh që funksionon. Zgjatimi i skedarit nuk ju thotë asgjë se cilin prej të dyjave mbani në dorë. Lexoni përmbajtjen përpara se të vendosni që i përket një deoje.

Hapat më poshtë supozojnë se po shqyrtohet një shabllon klienti për kontrollin e versioneve. Ekzekutojini sipas radhës dhe ndaloni përpara se të commit-oni diçka që nuk mund ta revokoni.

Lexoni skedarin që do të vendosni në indeks

Filloni me bajtët realë, sepse një profil që referon skedarë të veçantë duket krejt ndryshe nga ai që i përfshin ata. Kërkoni shenjat e bllokut PEM dhe etiketat e brendshme me emrat ca, cert, key, tls-auth dhe tls-crypt, dhe i njëjti kalim do t'ju tregojë të dyja rastet. Një çelës privat i kriptuar vazhdon të konsiderohet material i ndjeshëm, dhe një çelës i përbashkët tls-auth ose tls-crypt është kredencial edhe pse nuk është identiteti i një përdoruesi. Zbatoni të njëjtën rishikim për gjithçka që vendoset në indeks bashkë me profilin, përfshirë arkivat dhe skriptet e instalimit që referojnë një skedar kredencialesh.

Më pas shikoni grupin e vendosur në indeks dhe jo pemën e punës. git diff --cached tregon se çfarë do të përmbajë vërtet commit-i, dhe ai është i vetmi version që ka rëndësi për këtë vendim.

Vendosni çfarë mund të shpërndajë depoja

Një shabllon mund të mbajë cilësimet e përbashkëta e të rishikuara dhe vendmbajtëse të emërtuara për gjithçka që një person merr në regjistrim. Ajo që nuk mund të mbajë është një identitet i përdorshëm, sepse një depo shpërndahet për të gjithë ata që mund ta lexojnë, përfshirë automatizimin. Një depo private e ngushton audiencën pa ndryshuar pyetjen nëse çdo lexues është i autorizuar për atë kredencial.

Një rregull injorimi parandalon shtesat e ardhshme dhe nuk bën asgjë për atë që është regjistruar tashmë. Kjo asimetri ia vlen të përvetësohet përpara commit-it të parë dhe jo pas të dhjetit. Emrat dhe adresat e infrastrukturës janë një gjykim më vete: nuk janë sekrete vërtetimi, por mund të zbulojnë më shumë sesa synon të publikojë një ekip. Merrni atë vendim në mënyrë të shprehur, në vend që të klasifikoni çdo rresht si fjalëkalim ose publik.

Nëse materiali është tashmë në historik

Heqja e rreshtit në një commit të ri e lë versionin e vjetër të paprekur për këdo që e shkarkon. Trajtoni ekspozimin si të vërtetë: identifikoni llojin e kredencialit, pastaj gjeni autoritetin që mund ta anulojë. Certifikata e klientit revokohet dhe lista e revokimit rigjenerohet; një çelës i përbashkët i kanalit të kontrollit zëvendësohet në server dhe në çdo klient që e përdor.

Të dy kanë rreze shumë të ndryshme ndikimi, dhe plani duhet të thotë se cilin po ekzekutoni përpara se të filloni. Gjeni commit-in që e futi materialin me një kërkim të tipit git log --all -S 'BEGIN PRIVATE KEY', që shtrirja e pastrimit të jetë e njohur dhe jo e hamendësuar. Kloni i një kolegu ose një fork mund ta mbajë tashmë objektin e vjetër, prandaj revokimi vjen i pari dhe pastrimi i dyti.

Pastrojeni vetëm pasi ta kufizoni

Rishkrimi i historikut ndryshon çdo commit pas atij që redaktoni, prandaj fillimisht kërkon miratimin e pronarit të depos dhe të njerëzve që punojnë në të. Një push i detyruar nuk është riparim; është një ngjarje koordinimi me rrezikun e vet të kthimit pas. Planifikojeni, merrni një kopje rezervë dhe njoftoni ekipin se kur do të ndodhë.

Më pas verifikoni pemën aktuale dhe historikun e mbetur në vend që të mbështeteni në përmbledhjen e mjetit.

Mbajeni rezultatin si dy artefakte: shabllonin që është i sigurt për t'u ndarë dhe inventarin e kredencialeve të lëshuara gjatë procesit të regjistrimit. Asnjëri prej tyre nuk kërkon që një identitet i përdorshëm të jetojë në depo.

Kjo ndarje është rregullimi i vërtetë, dhe i mbijeton personit të ardhshëm që do të dojë të commit-ojë një profil.