OpenVPN-profil a Gitben: mit távolítsunk el a commit előtt

A profilok egyszerre két célt szolgálnak: rögzítik a kapcsolat beállításait, és működő hitelesítőadat-köteget hordoznak. A fájlkiterjesztés semmit nem árul el arról, melyiket tartja a kezében. Olvassa el a tartalmat, mielőtt eldönti, hogy egy tárolóba tartozik.

Az alábbi lépések feltételezik, hogy egy klienssablon verziókezelésre kerül szóba. Hajtsa végre őket sorrendben, és álljon meg, mielőtt olyat commitol, amit nem tud visszavonni.

Olvassa el az indexelni kívánt fájlt

Kezdje a tényleges bájtokkal, mert a külön fájlokra hivatkozó profil egészen másképp néz ki, mint az, amelyik beágyazza őket. Keresse a PEM-blokkjelölőket és a ca, cert, key, tls-auth és tls-crypt nevű beágyazott címkéket, és ugyanez az átvizsgálás mindkét esetet megmutatja. A titkosított privát kulcs továbbra is érzékeny anyagnak számít, a megosztott tls-auth vagy tls-crypt kulcs pedig hitelesítő adat akkor is, ha nem egy felhasználó identitása. Ugyanezt a vizsgálatot alkalmazza mindenre, ami a profillal együtt az indexbe kerül, beleértve a hitelesítőadat-fájlra hivatkozó archívumokat és telepítőszkripteket.

Utána az indexelt halmazt nézze, ne a munkafát. A git diff --cached megmutatja, mit fog valójában tartalmazni a commit, és ez az egyetlen verzió, amely e döntés szempontjából számít.

Döntse el, mit terjeszthet a tároló

Egy sablon hordozhatja a közös, átvizsgált beállításokat és a megnevezett helyőrzőket mindenhez, amit az ember a regisztrációnál kap. Amit viszont nem hordozhat, az a használható identitás, mert a tároló mindenkinek kiosztódik, aki olvasni tudja, az automatizálást is beleértve. A magán tároló szűkíti a közönséget, de nem változtatja meg azt a kérdést, hogy minden olvasó jogosult-e erre a hitelesítő adatra.

A mellőzési szabály megakadályozza a jövőbeli hozzáadásokat, és semmit nem tesz azzal, ami már rögzítve van. Ezt az aszimmetriát érdemes az első commit előtt interiorizálni, nem a tizedik után. Az infrastruktúra nevei és címei külön megítélés tárgyát képezik: nem hitelesítési titkok, de többet fedhetnek fel annál, mint amit egy csapat közzétenni szándékozik. Hozza meg ezt a döntést kifejezetten, ahelyett hogy minden sort jelszó vagy nyilvános kategóriába sorolna.

Ha az anyag már az előzményekben van

A sor eltávolítása egy új commitban érintetlenül hagyja a régi verziót mindenkinek, aki letölti. Kezelje a kitettséget valósként: azonosítsa a hitelesítő adat típusát, majd keresse meg a hatóságot, amely érvényteleníteni tudja. Az ügyféltanúsítvány visszavonásra kerül, és a visszavonási lista újragenerálódik; a megosztott vezérlőcsatorna-kulcsot kicserélik a kiszolgálón és minden ügyfélen, amely használja.

A kettő hatósugara nagyon különbözik, és a tervnek a kezdés előtt ki kell mondania, melyiket hajtja végre. Keresse meg a commitot, amely behozta az anyagot, egy git log --all -S 'BEGIN PRIVATE KEY' típusú kereséssel, hogy a tisztítás hatóköre ismert legyen, ne találgatott. Egy kolléga klónja vagy egy elágazás már birtokolhatja a régi objektumot, ezért a visszavonás jön előbb, a tisztítás pedig utána.

Csak a körülhatárolás után tisztítson

Az előzmények átírása minden commitot megváltoztat, amely a szerkesztett után következik, ezért előbb a tároló tulajdonosának és az abban dolgozó embereknek az egyetértése szükséges. A kényszerített push nem javítás; ez egy koordinációs esemény a maga visszaállítási kockázatával. Ütemezze be, készítsen biztonsági mentést, és mondja meg a csapatnak, mikor történik meg.

Utána ellenőrizze a jelenlegi fát és a fennmaradó előzményeket, ahelyett hogy az eszköz összefoglalójában bízna.

Őrizze meg az eredményt két összetevőként: a biztonságosan megosztható sablont és a regisztrációs folyamat során kiadott hitelesítő adatok leltárát. Egyik sem igényli, hogy használható identitás éljen a tárolóban.

Ez a szétválasztás az igazi megoldás, és túléli azt a következő embert, aki commitolni akar egy profilt.