Jedes Repository, das automatisch gebaut, getestet oder ausgerollt wird, braucht einen Zugang, hinter dem kein Mensch sitzt. Zwei Mechanismen tauchen dabei in fast jeder GitHub-Umgebung auf: der Deploy Key und die GitHub App. Oft wird der eine oder der andere aus Gewohnheit gewählt, nicht weil er zur Aufgabe passt. Das rächt sich später, wenn niemand mehr weiß, welcher Schlüssel wohin reicht und wer ihn abschalten darf.
Was ein Deploy Key ist und wo er passt
Ein Deploy Key ist ein SSH-Schlüsselpaar, das an ein einzelnes Repository gebunden ist. Der öffentliche Teil liegt in den Repo-Einstellungen, den privaten Teil hält das System, das damit klont oder pusht. Standardmäßig gibt der Schlüssel nur Lesezugriff, mit einem Haken auch Schreibzugriff. Der Reiz liegt in der Einfachheit: kein Dienst dazwischen, keine App-Registrierung, ein Schlüssel für ein Repo.
Genau diese Einfachheit ist auch die Grenze. Ein Deploy Key kennt nur zwei Stufen, lesen oder schreiben, und er kennt nur das eine Repo. Sobald ein zweites Repository denselben Zugang braucht, wird der Schlüssel kopiert oder es entsteht ein zweiter. Ein Ablaufdatum gibt es nicht. Wer den Schlüssel angelegt hat und ob er noch gebraucht wird, steht nirgends. Für einen klar abgegrenzten Fall, etwa ein Deploy-Ziel, das genau ein Repo lesen muss, ist ein Deploy Key sauber. Als allgemeiner Maschinenzugang skaliert er nicht.
Was eine GitHub App anders macht
Eine GitHub App ist keine Person und kein einzelner Schlüssel, sondern eine registrierte Identität mit fein einstellbaren Rechten. Sie wird auf ausgewählte Repositories installiert und bekommt genau die Berechtigungen, die sie braucht, etwa nur auf Pull Requests oder nur auf Checks. Statt eines dauerhaften Schlüssels stellt sie kurzlebige Zugriffstoken aus, die nach einer Stunde ablaufen. Jede Aktion der App ist im Audit-Log als solche erkennbar.
Der Aufwand ist höher. Eine App muss registriert, mit einem privaten Schlüssel versehen und installiert werden, und das Ausstellen der Token ist ein eigener Schritt. Dafür bekommt man drei Dinge, die dem Deploy Key fehlen: eng geschnittene Rechte statt lesen oder schreiben, Token mit Ablauf statt eines statischen Schlüssels, und eine klare Zuordnung im Log statt eines anonymen Zugriffs.
Die Unterschiede, die im Betrieb zählen
Drei Achsen trennen die beiden Zugänge in der Praxis. Reichweite: der Deploy Key hängt an einem Repo und kann nur lesen oder schreiben, die App bekommt pro Berechtigung genau die Stufe, die passt, über mehrere Repos hinweg. Lebensdauer: der Schlüssel gilt, bis ihn jemand entfernt, das App-Token läuft von selbst ab und ein kompromittiertes Token ist nach kurzer Zeit wertlos. Nachvollziehbarkeit: ein Zugriff per Deploy Key erscheint im Log ohne klaren Absender, eine App-Aktion trägt den Namen der App.
Diese Unterschiede fallen nicht auf, solange alles läuft. Sie fallen auf, wenn ein Schlüssel abhandenkommt, wenn geprüft wird wer wann was verändert hat, oder wenn beim Aufräumen niemand sagen kann, wofür ein bestimmter Deploy Key eigentlich da ist.
Eine einfache Entscheidungsregel
Für den seltenen, klar umrissenen Einzelfall, ein Automatismus, der genau ein Repository lesen muss und sonst nichts, ist ein Deploy Key mit Lesezugriff vertretbar. Für alles andere, was regelmäßig läuft, über mehrere Repos greift oder Schreibrechte braucht, ist die GitHub App der bessere Standard. Statische Deploy Keys mit Schreibrecht über viele Repositories sind das Muster, das man vermeiden will.
Der erste Schritt ist immer dasselbe, das man auch bei Service-Accounts und Bot-Tokens macht: hinschauen, was es gibt. Wie viele Deploy Keys existieren, welche haben Schreibrecht, welcher gehört zu welchem Zweck. Erst wenn diese Liste steht, lohnt die Umstellung auf App-basierte Zugänge. Ohne Inventar ersetzt man nur einen unübersichtlichen Zustand durch einen anderen.
Wir helfen kleinen Softwarehäusern, ihre Zugriffe, Nachweise und Freigaben in der Build- und Deploy-Kette so zu ordnen, dass am Ende nachvollziehbar bleibt, wer worauf zugreift und warum. Wer den eigenen Bestand an Maschinenzugängen einmal sauber sortieren will, erreicht uns unter mm@mhm-dl.de.
Dein Blog zum Thema digitales Business 