GitHub Apps: Erst die Aufgabe, dann die Berechtigung

GitHub meldete Enterprise-Installationen für Apps am 23. Oktober als allgemein verfügbar. Die Ankündigung erweitert administrative API-Abdeckung; GHES 3.24 wird als gesonderte künftige Bereitstellung genannt. (GitHub)

Mit einer Aktionsliste beginnen

Automatisierungen wachsen oft um ein persönliches Token herum. Später ist nicht mehr sichtbar, ob das Skript nur einen Bericht liest oder auch Zugriffsregeln ändern darf. Der erste Migrationsschritt ist deshalb eine Liste tatsächlicher Aufgaben. Nicht von bestehenden Token-Rechten auf notwendigen Bedarf schliessen: Breite Rechte können ein historischer Zufall sein.

Die Beispiele legen keine konkreten GitHub-Berechtigungsnamen fest. Diese müssen für den verwendeten Endpunkt und Authentifizierungskontext aus der aktuellen Dokumentation abgeleitet werden. So wird verhindert, dass ein fachlicher Begriff wie «Bericht» versehentlich als Recht zur breiten Administration umgesetzt wird.

Vier Ebenen nicht in einem Häkchen zusammenfassen

GitHub unterscheidet Repository-, Organisations-, Enterprise- und Account-Berechtigungen und empfiehlt den minimal erforderlichen Umfang. Eine App-Zulassung ist deshalb nicht dieselbe Entscheidung wie ein Benutzerzugriff auf beliebige Ressourcen. (GitHub)

Für jede Aktion sind mindestens Ressourcenbereich, Identität und Art der Änderung zu klären. Zusätzlich braucht die Schlüsselverwaltung einen Eigentümer und einen Weg zur Sperrung. Tokens sollten nicht in Code, Protokollen oder Kundenübergaben auftauchen. Das gilt unabhängig davon, ob eine App einen früheren PAT ersetzt.

Was beim Vergleich PAT gegen App geprüft werden sollte

Die allgemeine Verfügbarkeit sagt nichts darüber aus, ob ein bestimmtes Skript unverändert funktioniert. API-Abdeckung, Webhook-Ereignisse, Fehlerbehandlung und das Verhalten beim Entzug eines Zugangs gehören in einen begrenzten Versuch. Für GHES zusätzlich die tatsächlich eingesetzte Serverversion betrachten; eine Cloud-Meldung beweist keine Freigabe des eigenen Servers.

Ein reversibler Lesepilot

1. Eine einzelne lesende Aufgabe mit eng abgegrenzten Ressourcen auswählen.
2. Bisherigen Ablauf und erwartete Datenausgabe festhalten.
3. App-Zugang nach Dokumentation einrichten lassen; Änderungen und Schlüsselübernahme dokumentieren.
4. Alte und neue Ausgabe anhand vorher definierter Kriterien vergleichen, ohne produktive Schreibaktionen auszulösen.
5. Sperrung und Wiederanlauf prüfen und erst danach weitere Aufgaben migrieren.

Eine schreibende Automation benötigt anschliessend eigene Grenzen: erlaubte Übergänge, Freigabe, Wiederholung und Abbruch bei unerwartetem Zustand. Dass Lesen funktioniert hat, ist kein Test für administrative Änderungen. Für eine Agentur gehört ausserdem in die Übergabe, ob die App dem Kunden oder dem betreuenden Team gehört und wer Rechte später ändern darf.

Dieser Beitrag ist ein Planungsmodell, kein Installationsprotokoll. KIURO hat hierfür keine App registriert, keinen PAT ersetzt und keinen Kundenaccount geprüft. Konkrete Laufzeiten von Tokens, Pläne und Gebühren werden vor der Umsetzung in der geltenden Dokumentation geprüft, statt hier eine allgemeine Zahl zu versprechen.