Eine GitHub App im Enterprise öffnet nicht automatisch den Repository-Code
Ein Skript für Unternehmenseinstellungen hängt manchmal am persönlichen Token eines längst ausgeschiedenen Mitarbeiters. Am 23. Oktober meldete GitHub die allgemeine Verfügbarkeit von Enterprise-Installationen für GitHub Apps. Damit lassen sich weitere Verwaltungsabläufe von klassischen PATs lösen. Eine Installation auf Enterprise-Ebene bedeutet aber keinen Zugriff auf sämtlichen Code.
Was die Enterprise-App verwaltet
Die Neuerungen betreffen unter anderem Repository-Richtlinien, Rulesets, das Lesen von Bypass-Anfragen und IP-Zulassungslisten. Eine Übersicht über Bypass-Anfragen benötigt andere Rechte als das Ändern der Regeln. Für den Einstieg müssen daher nicht sämtliche Schreibrechte aktiviert werden.
Die Enterprise-Installation gewährt ausschließlich Enterprise-Berechtigungen. Zusätzlich angeforderte Organisations- oder Repository-Rechte werden dabei nicht erteilt. Wer Code aus zwei Organisationen lesen möchte, braucht dort separate Installationen und passende Repository-Freigaben. Lesbare Enterprise-Einstellungen bei verweigertem Codezugriff sind deshalb nicht zwingend ein Installationsfehler.
Eine App, mehrere Installationen
Im fiktiven Enterprise acme liegen die Organisationen web und mobile. Wird dieselbe App auf allen drei Konten installiert, entstehen drei Installationen. Der Enterprise-Token ersetzt keinen web-Token; der web-Token gilt nicht für mobile. Die selbst erstellte Grafik zeigt dieses Beispiel, keine echte GitHub-Oberfläche.
Ein Token-Cache sollte deshalb nicht allein den App-Namen als Schlüssel nutzen. Die Installations-ID hilft, Enterprise-Richtlinien und Repository-Aufgaben getrennt zu halten. Das ist ein Implementierungsbeispiel, das die dokumentierte Kontogrenze in die Programmstruktur überträgt.
App-Rechte und Benutzerrechte
Ein Benutzer-Access-Token berücksichtigt die Rechte der App und des Benutzers. Hat die App Schreibrechte, der Benutzer aber nur Leserechte, erweitert das dessen Zugriff nicht. Ein Installation-Access-Token arbeitet dagegen innerhalb der App-Rechte der jeweiligen Installation.
Zur Ausstellung dienen das App-JWT und die Installations-ID. Dokumentiert sind POST /app/installations/INSTALLATION_ID/access_tokens und eine Gültigkeit von einer Stunde. Octokit kann Ausstellung und Erneuerung übernehmen. Kurzlebige Token ersetzen jedoch weder den Schutz des privaten App-Schlüssels noch einen installationsbezogenen Cache.
Vor dem Austausch eines persönlichen Tokens
Kombiniert ein Skript Enterprise-Richtlinien und Codeabfragen mehrerer Organisationen, genügt ein anderer Token-String möglicherweise nicht. Aufgaben, API-Unterstützung und Authentifizierungsart müssen zusammenpassen. Nicht jede Enterprise-GraphQL-Operation unterstützt Apps. Mit einer Leseoperation lassen sich Ergebnisse und Zugriffsgrenzen gut vergleichen.
Die Quellen sind zeitlich nicht ganz synchron: Das Changelog vom 23. Oktober meldet allgemeine Verfügbarkeit, die heute geprüfte Installationsdokumentation nennt noch Public Preview. Hier folgt der Veröffentlichungsstatus der datierten Ankündigung, der Berechtigungsumfang der Dokumentation. Der Gewinn liegt darin, Automatisierung nach Konto und Aufgabe zu gestalten statt die weitreichenden Rechte einer Person zu kopieren.
Quellen und weitere Informationen
GitHub Docs · Enterprise installation