OpenVPN-Profil in Git: Was vor dem Commit entfernt werden muss

Profile dienen zwei Zwecken zugleich: Sie halten Verbindungseinstellungen fest und tragen ein funktionierendes Bündel von Anmeldedaten. Die Dateiendung verrät Ihnen nichts darüber, welches der beiden Sie in der Hand halten. Lesen Sie den Inhalt, bevor Sie entscheiden, dass er in ein Repository gehört.

Die folgenden Schritte gehen davon aus, dass eine Client-Vorlage für die Versionsverwaltung erwogen wird. Führen Sie sie der Reihe nach aus und halten Sie an, bevor Sie etwas committen, das Sie nicht widerrufen können.

Lesen Sie die Datei, die Sie bereitstellen wollen

Beginnen Sie bei den tatsächlichen Bytes, denn ein Profil, das auf separate Dateien verweist, sieht ganz anders aus als eines, das sie einbettet. Suchen Sie nach den PEM-Blockmarkierungen und nach den eingebetteten Tags mit den Namen ca, cert, key, tls-auth und tls-crypt, und derselbe Durchgang zeigt Ihnen beide Fälle. Ein verschlüsselter privater Schlüssel zählt weiterhin als sensibles Material, und ein gemeinsamer tls-auth- oder tls-crypt-Schlüssel ist ein Anmeldedatum, auch wenn er nicht die Identität eines Nutzers ist. Wenden Sie dieselbe Prüfung auf alles an, was zusammen mit dem Profil bereitgestellt wird, einschließlich Archiven und Einrichtungsskripten, die auf eine Anmeldedatendatei verweisen.

Betrachten Sie dann den bereitgestellten Satz statt des Arbeitsbaums. git diff --cached zeigt, was der Commit tatsächlich enthalten wird, und das ist die einzige Version, die für diese Entscheidung zählt.

Entscheiden Sie, was das Repository verteilen darf

Eine Vorlage kann die gemeinsamen, geprüften Einstellungen und benannte Platzhalter für alles tragen, was eine Person bei der Anmeldung erhält. Was sie nicht tragen kann, ist eine nutzbare Identität, denn ein Repository verteilt an alle, die es lesen können, Automatisierung eingeschlossen. Ein privates Repository verkleinert den Kreis, ohne die Frage zu ändern, ob jeder Leser für dieses Anmeldedatum berechtigt ist.

Eine Ignorierregel verhindert künftige Ergänzungen und tut nichts gegen das, was bereits aufgezeichnet ist. Diese Asymmetrie sollte man vor dem ersten Commit verinnerlichen und nicht nach dem zehnten. Infrastrukturnamen und Adressen sind eine eigene Abwägung: Sie sind keine Authentifizierungsgeheimnisse, können aber mehr offenlegen, als ein Team veröffentlichen will. Treffen Sie diese Entscheidung ausdrücklich, statt jede Zeile in Passwort oder öffentlich einzusortieren.

Wenn das Material bereits in der Historie steht

Das Entfernen der Zeile in einem neuen Commit lässt die alte Version für jeden unversehrt, der sie abruft. Behandeln Sie die Offenlegung als real: Bestimmen Sie die Art des Anmeldedatums und finden Sie dann die Stelle, die es ungültig machen kann. Ein Client-Zertifikat wird widerrufen und die Widerrufsliste neu erzeugt; ein gemeinsamer Schlüssel des Steuerkanals wird auf dem Server und auf jedem Client ersetzt, der ihn nutzt.

Beide haben sehr unterschiedliche Wirkungsradien, und der Plan sollte vor Beginn benennen, welchen Sie ausführen. Finden Sie den Commit, der das Material eingeführt hat, mit einer Suche der Art git log --all -S 'BEGIN PRIVATE KEY', damit der Umfang der Bereinigung bekannt und nicht geraten ist. Ein Klon eines Kollegen oder ein Fork kann das alte Objekt bereits halten, deshalb kommt der Widerruf zuerst und die Bereinigung danach.

Aufräumen erst nach der Eindämmung

Das Umschreiben der Historie ändert jeden Commit nach dem, den Sie bearbeiten, braucht also zuerst die Zustimmung des Repository-Eigentümers und der Menschen, die darin arbeiten. Ein erzwungener Push ist keine Reparatur; er ist ein Koordinationsereignis mit eigenem Rückabwicklungsrisiko. Planen Sie ihn, legen Sie eine Sicherung an und sagen Sie dem Team, wann er stattfindet.

Prüfen Sie danach den aktuellen Baum und die verbleibende Historie, statt der Zusammenfassung des Werkzeugs zu vertrauen.

Halten Sie das Ergebnis als zwei Artefakte fest: die Vorlage, die sicher geteilt werden kann, und das Verzeichnis der Anmeldedaten, die über den Anmeldeprozess ausgegeben wurden. Keines von beiden verlangt, dass eine nutzbare Identität im Repository lebt.

Diese Trennung ist die eigentliche Lösung, und sie überdauert die nächste Person, die ein Profil committen will.