OpenVPN профил в Git: какво да изрежете преди подаване

Профилите служат на две цели наведнъж: записват настройките за свързване и носят работещ набор от идентификационни данни. Разширението на файла не ви казва нищо за това кой от двата държите. Прочетете съдържанието, преди да решите, че то принадлежи на хранилище.

Стъпките по-долу предполагат, че клиентски шаблон се обмисля за контрол на версиите. Изпълнете ги по ред и спрете, преди да подадете нещо, което не можете да отмените.

Прочетете файла, който ще добавите в индекса

Започнете с действителните байтове, защото профил, който препраща към отделни файлове, изглежда много различно от такъв, който ги вгражда. Потърсете маркерите на PEM блок и вградените тагове с имена ca, cert, key, tls-auth и tls-crypt, и същото претърсване ще ви покаже и двата случая. Криптиран частен ключ все още се брои за чувствителен материал, а споделен ключ tls-auth или tls-crypt е идентификационни данни, дори да не е самоличност на потребител. Приложете същия преглед към всичко, добавено в индекса заедно с профила, включително архиви и инсталационни скриптове, които препращат към файл с идентификационни данни.

След това гледайте подготвения набор, а не работното дърво. git diff --cached показва какво всъщност ще съдържа подаването и това е единствената версия, която има значение за това решение.

Решете какво е позволено да разпространява хранилището

Шаблонът може да носи споделените, прегледани настройки и именувани заместители за всичко, което човек получава при записване. Това, което не може да носи, е използваема самоличност, защото хранилището се разпространява до всеки, който може да го чете, включително автоматизацията. Частното хранилище стеснява аудиторията, без да променя въпроса дали всеки читател е упълномощен за тези идентификационни данни.

Правилото за игнориране предотвратява бъдещи добавяния и не прави нищо за вече записаното. Тази асиметрия си заслужава да бъде осмислена преди първото подаване, а не след десетото. Имената и адресите на инфраструктурата са отделна преценка: те не са тайни за удостоверяване, но могат да разкрият повече, отколкото екипът възнамерява да публикува. Вземете това решение изрично, вместо да подреждате всеки ред в парола или публично.

Ако материалът вече е в историята

Премахването на реда в ново подаване оставя старата версия непокътната за всеки, който я изтегли. Отнасяйте се към излагането като към реално: определете вида на идентификационните данни, след това намерете органа, който може да ги анулира. Клиентският сертификат се отменя и списъкът за отменяне се генерира наново; споделеният ключ за контролния канал се заменя на сървъра и на всеки клиент, който го използва.

Двете имат много различен радиус на въздействие и планът трябва да посочи кой от тях изпълнявате, преди да започнете. Намерете подаването, което е внесло материала, с търсене от типа на git log --all -S 'BEGIN PRIVATE KEY', за да е известен обхватът на почистването, а не предположен. Клонинг на колега или разклонение може вече да държи стария обект, затова отменянето идва първо, а почистването второ.

Почиствайте само след ограничаване

Пренаписването на историята променя всяко подаване след редактираното, затова първо е нужно съгласие от собственика на хранилището и хората, които работят в него. Принудителното изтласкване не е поправка; то е координационно събитие със собствен риск от връщане назад. Планирайте го, направете резервно копие и кажете на екипа кога ще се случи.

След това проверете текущото дърво и останалата история, вместо да се доверявате на обобщението на инструмента.

Пазете резултата като два артефакта: шаблона, който е безопасен за споделяне, и описа на идентификационните данни, издадени чрез процеса на записване. Нито един от тях не изисква използваема самоличност да живее в хранилището.

Това разделяне е истинското решение и то оцелява следващия човек, който поиска да подаде профил.