GitHub Zugriffstoken erklärt

Es herrscht viel Verwirrung darüber, was GitHub (Zugangs-)Token sind und wie Sie sie für die Automatisierung von Dingen innerhalb von GitHub verwenden sollten. Es gibt drei Haupttypen von Token:

1. Persönliche Zugangstoken (PATs)
2. Die Umgebungsvariable GITHUB_TOKEN (Erläuterung hier)
3. Ein aus einer GitHub-App erstelltes Zugriffstoken (Erklärung hier)

Sie können diese Token verwenden, um sich bei GitHub zu authentifizieren und Aktionen durchzuführen, wie das Klonen von Repositories, API-Aufrufe usw.

Foto von James Sutton auf Unsplash

1. Persönliche Zugangstoken (PATs)

Diese Art von Token ist oft das erste, was die Leute verwenden, wenn sie Dinge automatisieren wollen. Das gilt auch für verschiedene CI/CD-Systeme wie Azure DevOps, die ich bereits verwendet habe. A Persönliches Zugangstoken wird auf ein Benutzerkonto eingefärbt und kann so eingestellt werden, dass sie automatisch abläuft. Heutzutage werden sie mit dem Präfix ghp so dass die Geheimscanner können sie leichter aufspüren.

Mit dem PAT können Sie alles tun, was das Benutzerkonto, das sie erstellt hat, tun kann (solange es die entsprechenden Bereiche dafür erhält):

• Repositories erstellen
• Ausgaben erstellen
• Pull-Anfragen erstellen
• Sicherheitswarnungen lesen
• usw.

Die Nachteile von Personal Access Tokens

Dieser Token kann tatsächlich tun anything der Benutzer tun kann, aber für anything auf die der Benutzer Zugriff hat! Wenn der Benutzer Zugriff auf Repos, Organisationen oder Unternehmen hat, die über interne/private Repos verfügen, hat der PAT Zugriff auf diese! Das Einzige, was Sie tun können, ist, den Umfang einzuschränken, aber nicht auf Organisationen oder Repos. (Hinweis: Dies ist für die Zukunft geplant. Straßenkarte und sehr notwendig).

Aus diesem Grund stellt die Verwendung eines PAT ein großes Sicherheitsrisiko dar. Geben Sie sie nicht an beliebige Personen aus Aktion in Ihren Arbeitsabläufen: Wenn sie das PAT irgendwo speichern, können sie alle Ihre privaten Repos lesen (und mehr!). Ich empfehle Ihnen, von der Verwendung von PATs abzusehen, wenn Sie es vermeiden können.

Außerdem sind sie mit einem Benutzer verknüpft. Wenn dieser Benutzer das Unternehmen verlässt (und das Benutzerkonto deaktiviert wird), funktionieren alle Automatisierungen, die sein PAT verwenden, nicht mehr!

Hinweis: Der einzige triftige Grund für die Verwendung des GitHub-Tokens ist der Zugriff auf Dinge in der API von der Unternehmensebene aus, falls Sie Dinge wie die Erstellung von Benutzern automatisieren müssen, was Sie mit SCIM als beste Praxis. Die meisten dieser Gründe sind also nach wie vor nicht stichhaltig.

2. Die Umgebungsvariable GITHUB_TOKEN

Die GITHUB_TOKEN ist eine Umgebungsvariable, die Sie in Ihren Arbeitsabläufen verwenden können, indem Sie sie dort einfügen, wo Sie sie benötigen: $. Das Token wird automatisch generiert und nirgendwo gespeichert. Es ist ein Token, das nur für die Dauer des Workflows gültig ist, für den es erstellt wurde. Standardmäßig hat es Lese- und Schreibzugriff auf das Repository, für das der Workflow ausgeführt wird. Das bedeutet, dass Sie dieses Token nicht für ein anderes Repository verwenden können. Sie können es für Dinge wie das Anlegen von Problemen, das Erstellen von Pull Requests oder das Kommentieren von Problemen verwenden. Je nach Kontext kann es weniger Berechtigungen erhalten, z. B. bei einem Pull Request, der von einer Abspaltung stammt, hat es nur lesen Zugriff auf das Repository.

Sie können ihm auch einen bestimmten Geltungsbereich zuweisen, indem Sie diesen innerhalb des Workflows festlegen:

permissions:
  contents: read
  pull-requests: write

Auf diese Weise kann das Token z.B. nicht für die Erstellung eines Problems verwendet werden. Selbst wenn also die von Ihnen verwendete Aktion versucht, ein Problem zu erstellen, hat das Token nicht die entsprechenden Berechtigungen und wird daher fehlschlagen.

Wenn Sie mehr über den GITHUB_TOKEN erfahren möchten, habe ich in diesem kurzen Video erklärt, wie er verwendet wird und wie man seine Möglichkeiten einschränken kann.

3. Ein von einer GitHub App erstelltes Zugriffstoken

Sie können eine GitHub App verwenden, um sehr spezifischen Zugriff auf ein oder mehrere Repositories zu erhalten. Ich verwende dies zum Beispiel, um (viele) Jenkins-Verbindungen einzurichten: Jedes Team bei meinem Kunden hat seine eigene Reihe von Jenkins-Jobs, die ausgelöst werden sollen, wenn jemand einen neuen Commit in sein GitHub-Repository einstellt. Indem ich jedem Team seine eigene GitHub App zur Verfügung stelle, kann ich den Zugriff der App auf die Repos beschränken, die für sie relevant sind (indem ich die App nur auf ihren Repositories installiere und nicht auf allen Repos in der Organisation). Da dieses Token an die Installation der App gebunden ist, nennen wir es ein Installations-Token.

Hinweis: Auf github.com können Sie nur 100 Apps pro Organisation erstellen. Auf GitHub Enterprise Server gilt diese Einschränkung nicht.

Mit einer GitHub App erhalten Sie eine AppId und einen privaten Schlüssel im PEM-Format. Sie können eine GitHub App auf einer Website und installieren Sie es dann auf den Repositories (oder Organisationen), für die Sie es verwenden möchten. Mit der AppId und dem privaten Schlüssel können Sie dann ein Zugriffstoken erstellen, das für den Zugriff auf die Repositories verwendet werden kann.

Es gibt mehrere Möglichkeiten, den Token zu erhalten, je nachdem, wo Sie ihn verwenden möchten:

• Normale Shell-Skripte
• Verwenden Sie eine Aktion
• Verwenden Sie eine Bibliothek (kann als Erweiterung in die GitHub CLI aufgenommen werden)

Hinweis: Dieser Token ist nur 1 Stunde lang gültig. Danach müssen Sie ihn aktualisieren, sonst werden Ihre Anrufe fehlschlagen.

Wenn Sie wissen möchten, wie Sie eine GitHub App erstellen und diese dann z.B. in einem GitHub-Workflow verwenden, sehen Sie sich mein Video dazu hier an:

Abrufen eines Zugriffstokens für eine App mit Shell-Skripten

1. Holen Sie sich die AppId und den privaten Schlüssel aus der von Ihnen erstellten GitHub App
2. Erzeugen Sie ein signiertes JWT-Token mit der AppId und dem privaten Schlüssel
3. Holen Sie sich mit dem JWT-Token die Installationen der App (Sie benötigen die Installations-ID, um das Token zu erstellen)
4. Erstellen Sie ein Token für die Installation
5. Verwenden Sie das Token für den Zugriff auf die Repositories

Abrufen eines Zugriffstokens für eine App mit einer Aktion in einem Workflow

Ein Zugriffstoken für eine App mit einer Bibliothek erhalten

Hinweis: Für die Installation als Erweiterung in der CLI benötigen Sie zunächst eine authentifizierte CLI-Sitzung, so dass dies für Automatisierungszwecke nicht hilfreich ist.

Der Nachteil der Verwendung von GitHub Apps

• Nur 100 Anwendungen" pro Organisation auf github.com (also öffentliche Repos oder GitHub Enterprise Cloud: GHEC).
• Nur minimale Möglichkeiten, die Einrichtung der Apps selbst zu automatisieren: Sie können ein Manifest verwenden, um sie zu erstellen, aber die Installation auf Repositories (selbst auf denen, die Sie besitzen) ist mit einer API nicht möglich.
• Wenig bis gar keine Unterstützung für externe Tools: die meisten von ihnen benötigen den Token und können diesen nicht aus der AppId und dem privaten Schlüssel generieren, so dass Sie dies selbst tun müssen (und beachten Sie den Ablauf von 1 Stunde!).

Einige Dinge, für die ich GitHub Apps verwendet habe:

• Installieren und Konfigurieren von selbst gehosteten Runnern.
• Konfigurieren des Zugriffs von Jenkins-Pipelines auf GitHub-Repos.
• Überall innerhalb von Arbeitsabläufen: Ich mag den begrenzten Zugriff, den die App hat, und möchte nichts an meine PAT weitergeben, da sie viel zu viel Zugriff hat!