Organisieren des Git-Zugriffs pro Kunde mit 1Password SSH Agent

Als Berater müssen wir mit mehreren Berechtigungsnachweisen jonglieren, auch mit denen von Xebia. Aber wir sind auch bei den Kunden, bei denen wir für unsere Aufträge eingestellt werden, onboarded. Ich habe bereits darüber gebloggt, wie ich meine Browser-Sitzungen für verschiedene Kunden trenne. Dadurch habe ich die Möglichkeit, relevante Lesezeichen für meinen Auftrag zu haben. In diesem Blog werde ich weiter erläutern, wie ich meinen Git-Zugang organisiere und nach Kunden trenne.

Passwortverwaltung

Da ich mit verschiedenen Kunden zusammenarbeite, speichere ich alle meine Anmeldedaten in einem Passwortmanager. Ich verwende 1Password, und 1Password hat eine großartige Funktion namens SSH Agent. Mit dieser Funktion können Sie Ihre privaten SSH-Schlüssel in 1Password speichern und sie verwenden, wenn Sie Code über SSH auf ein entferntes Repository ziehen oder übertragen.

Ich erstelle einen SSH-Schlüssel pro Kunde in meinem 1Password-Tresor. Sobald er erstellt ist, konfiguriere ich den öffentlichen Schlüssel im Repository-System des Kunden. (Beispiel: GitHub/GitLab/BitBucket) Ich lege sowohl einen Authentifizierungs- als auch einen Signierschlüssel fest, so dass ich denselben Schlüssel zweimal hochlade.

Ich erstelle auch eine Datei ~/.ssh/my-customer.pub, die den öffentlichen Schlüssel enthält. Diese Datei weist SSH an, welche Identität zu verwenden ist. Da wir auch einen Signierschlüssel hochgeladen haben, füge ich den öffentlichen Schlüssel zur Datei ~/.git/allowed_signers hinzu.

joris.conijn@my-customer.com ssh-ed25519 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Der einzige Nachteil dabei ist, dass der Schlüssel in Ihrem Haupttresor gespeichert werden muss. Ich erstelle immer kundenspezifische Tresore, und der 1Password-Agent kann nur den Haupttresor verwenden.

Weitere Informationen über 1Password-Agenten und wie Sie sie mit GitHub konfigurieren.

Git Konfiguration

Als nächstes folgt die Git-Konfiguration. Dieser Abschnitt besteht aus drei Teilen. Die ersten beiden Teile müssen Sie pro Kunde einrichten. Den anderen Teil müssen Sie nur einmal einrichten.

Zunächst erstellen wir die Git-Konfiguration, die für diesen Kunden verwendet wird. Ich erstelle eine Datei pro Kunde an folgendem Ort: ~/.git/gitconfig-my-customer. Diese Datei hat den folgenden Inhalt:

[user]
    name = Joris Conijn
    email = joris.conijn@my-customer.com
    signingkey = ssh-ed25519 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[gpg]
  format = ssh
[gpg "ssh"]
  program = "/Applications/1Password.app/Contents/MacOS/op-ssh-sign"
[commit]
  gpgsign = true

Die Benutzerdefinition in dieser Datei wird für die Übertragung des Codes verwendet. In diesem Beispiel ist der Benutzer Joris Conijn, und die E-Mail-Adresse lautet . Damit stellen Sie sicher, dass Sie Ihren Code mit der in der Umgebung des Kunden bekannten Entität festschreiben.

Verwenden Sie Ihren eigenen öffentlichen Schlüssel als Signierschlüssel und stellen Sie sicher, dass der 1Password-Pfad auch zu Ihrem System passt. Als Nächstes müssen Sie für jeden Kunden in der Datei ~/.gitconfig Folgendes festlegen:

[includeIf "gitdir:~/workspace/my-customer/"]
    path = ~/.git/gitconfig-my-customer
[url "git@my-customer:my-org/“]
        insteadOf = "git@github.com:my-org/"

Ich muss hier ein paar Dinge erklären. Der erste Teil stellt sicher, dass jedes Git-Repository im Pfad ~/workspace/my-customer/ die in ~/.git/gitconfig-my-customer definierte Konfiguration verwendet.

Im zweiten Teil wird git@github.com:my-org/my-repo.git in git@my-customer:my-org/my-repo.git umgewandelt. Das ist der eigentliche Clou: Die verwendete Domain ist keine gültige Domain. Es handelt sich lediglich um den Namen des Kunden, der noch nicht zu den Servern von github.com aufgelöst wird.

Die einmalig erforderliche Einrichtung besteht darin, die Datei ~/.git/allowed_signers für die Verwendung zu konfigurieren. Sie können dies tun, indem Sie den folgenden Abschnitt in die Datei ~/.gitconfig einfügen:

[gpg "ssh"]
    allowedSignersFile = ~/.git/allowed_signers

Damit konfigurieren Sie die Liste der erlaubten Unterzeichner in Git, damit das Git-Cli-Tooling gültige Signaturen anzeigt.

SSH-Konfiguration

Wir sind fast fertig. Als nächstes müssen wir die SSH-Konfiguration selbst vornehmen. Wir müssen nun die ~/.ssh/config file aktualisieren:

Host my-customer
    HostName github.com
    User git
    IdentityFile ~/.ssh/my-customer.pub
    IdentitiesOnly yes

Was wir hier tun, ist Folgendes. Wir definieren einen Host namens my-customer und überschreiben den Hostnamen mit github.com. Damit stellen wir sicher, dass die GitHub-Server wieder verwendet werden, und verweisen auf unsere kundenspezifische Konfiguration. Der Hauptgrund für diesen virtuellen Hostnamen ist, dass Sie SSH-Konfigurationen nur auf Hostnamen definieren können, nicht auf URI-Pfade.

Fazit

Die Verwaltung mehrerer Kundenumgebungen als Berater kann leicht unübersichtlich werden, wenn sich Anmeldedaten und Git-Konfigurationen überschneiden. Mit dem SSH-Agenten von 1Password und einer strukturierten Git- und SSH-Einrichtung können Sie Ihre Projekte sicher isolieren und gleichzeitig einen reibungslosen Ablauf für die Entwickler gewährleisten. Dieser Ansatz gewährleistet eine professionelle Trennung, klare Commit-Historien und einen mühelosen Wechsel zwischen Kundenkontexten.

Foto von Myburgh Roux