Grundlegende Github-Informationen

Reading time: 16 minutes

Grundstruktur

Die grundlegende Github-Umgebungsstruktur eines großen Unternehmens besteht darin, ein Unternehmen zu besitzen, das mehrere Organisationen besitzt, und jede von ihnen kann mehrere Repositories und mehrere Teams enthalten. Kleinere Unternehmen besitzen möglicherweise nur eine Organisation und keine Unternehmen.

Aus der Sicht eines Benutzers kann ein Benutzer ein Mitglied von verschiedenen Unternehmen und Organisationen sein. Innerhalb dieser kann der Benutzer verschiedene Rollen in Unternehmen, Organisationen und Repositories haben.

Darüber hinaus kann ein Benutzer Teil verschiedener Teams mit unterschiedlichen Rollen in Unternehmen, Organisationen oder Repositories sein.

Und schließlich können Repositories spezielle Schutzmechanismen haben.

Berechtigungen

Unternehmensrollen

• Unternehmensinhaber: Personen mit dieser Rolle können Administratoren verwalten, Organisationen innerhalb des Unternehmens verwalten, Unternehmenseinstellungen verwalten, Richtlinien über Organisationen hinweg durchsetzen. Sie können jedoch nicht auf die Einstellungen oder Inhalte der Organisation zugreifen, es sei denn, sie werden zu einem Organisationsinhaber ernannt oder erhalten direkten Zugriff auf ein von der Organisation besessenes Repository.
• Unternehmensmitglieder: Mitglieder von Organisationen, die Ihrem Unternehmen gehören, sind ebenfalls automatisch Mitglieder des Unternehmens.

Organisationsrollen

In einer Organisation können Benutzer verschiedene Rollen haben:

• Organisationsinhaber: Organisationsinhaber haben vollständigen administrativen Zugriff auf Ihre Organisation. Diese Rolle sollte begrenzt sein, jedoch nicht auf weniger als zwei Personen in Ihrer Organisation.
• Organisationsmitglieder: Die Standard-Nicht-Administrationsrolle für Personen in einer Organisation ist das Organisationsmitglied. Standardmäßig haben Organisationsmitglieder eine Reihe von Berechtigungen.
• Abrechnungsmanager: Abrechnungsmanager sind Benutzer, die die Abrechnungseinstellungen für Ihre Organisation verwalten können, wie z. B. Zahlungsinformationen.
• Sicherheitsmanager: Es ist eine Rolle, die Organisationsinhaber einem Team in einer Organisation zuweisen können. Wenn sie angewendet wird, gibt sie jedem Mitglied des Teams Berechtigungen, um Sicherheitswarnungen und -einstellungen in Ihrer Organisation zu verwalten sowie Lesezugriff auf alle Repositories in der Organisation zu haben.
• Wenn Ihre Organisation ein Sicherheitsteam hat, können Sie die Rolle des Sicherheitsmanagers verwenden, um den Mitgliedern des Teams den minimalen Zugriff zu gewähren, den sie für die Organisation benötigen.
• Github App-Manager: Um zusätzlichen Benutzern zu ermöglichen, GitHub-Apps zu verwalten, die einer Organisation gehören, kann ein Inhaber ihnen Berechtigungen als GitHub App-Manager gewähren.
• Externe Mitarbeiter: Ein externer Mitarbeiter ist eine Person, die Zugriff auf eines oder mehrere Repositories der Organisation hat, aber nicht ausdrücklich Mitglied der Organisation ist.

Sie können die Berechtigungen dieser Rollen in dieser Tabelle vergleichen: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Mitgliederberechtigungen

In https://github.com/organizations/<org_name>/settings/member_privileges können Sie die Berechtigungen sehen, die Benutzer nur durch ihre Mitgliedschaft in der Organisation haben.

Die hier konfigurierten Einstellungen geben die folgenden Berechtigungen für Mitglieder der Organisation an:

• Admin, Autor, Leser oder keine Berechtigung für alle Repos der Organisation.
• Ob Mitglieder private, interne oder öffentliche Repositories erstellen können.
• Ob das Forken von Repositories möglich ist.
• Ob externe Mitarbeiter eingeladen werden können.
• Ob öffentliche oder private Seiten veröffentlicht werden können.
• Die Berechtigungen, die Administratoren über die Repositories haben.
• Ob Mitglieder neue Teams erstellen können.

Repository-Rollen

Standardmäßig werden Repository-Rollen erstellt:

• Lesen: Empfohlen für Nicht-Code-Beitragsleistende, die Ihr Projekt ansehen oder diskutieren möchten.
• Triage: Empfohlen für Beitragsleistende, die Probleme und Pull-Requests proaktiv verwalten müssen, ohne Schreibzugriff zu haben.
• Schreiben: Empfohlen für Beitragsleistende, die aktiv zu Ihrem Projekt beitragen.
• Verwalten: Empfohlen für Projektmanager, die das Repository verwalten müssen, ohne Zugriff auf sensible oder destruktive Aktionen zu haben.
• Admin: Empfohlen für Personen, die vollständigen Zugriff auf das Projekt benötigen, einschließlich sensibler und destruktiver Aktionen wie das Verwalten von Sicherheit oder das Löschen eines Repositories.

Sie können die Berechtigungen jeder Rolle in dieser Tabelle vergleichen: https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

Sie können auch Ihre eigenen Rollen erstellen in https://github.com/organizations/<org_name>/settings/roles.

Teams

Sie können die in einer Organisation erstellten Teams auflisten in https://github.com/orgs/<org_name>/teams. Beachten Sie, dass Sie, um die Teams zu sehen, die Kinder anderer Teams sind, auf jedes übergeordnete Team zugreifen müssen.

Benutzer

Die Benutzer einer Organisation können in https://github.com/orgs/<org_name>/people aufgelistet werden.

In den Informationen zu jedem Benutzer können Sie die Teams sehen, in denen der Benutzer Mitglied ist, und die Repos, auf die der Benutzer Zugriff hat.

Github-Authentifizierung

Github bietet verschiedene Möglichkeiten, sich bei Ihrem Konto zu authentifizieren und Aktionen in Ihrem Namen auszuführen.

Webzugang

Durch den Zugriff auf github.com können Sie sich mit Ihrem Benutzernamen und Passwort (und möglicherweise einer 2FA) anmelden.

SSH-Schlüssel

Sie können Ihr Konto mit einem oder mehreren öffentlichen Schlüsseln konfigurieren, die es dem zugehörigen privaten Schlüssel ermöglichen, Aktionen in Ihrem Namen auszuführen. https://github.com/settings/keys

GPG-Schlüssel

Sie können den Benutzer mit diesen Schlüsseln nicht impersonifizieren, aber wenn Sie ihn nicht verwenden, könnte es möglich sein, dass Sie entdeckt werden, weil Sie Commits ohne eine Signatur senden. Erfahren Sie mehr über vigilante Modus hier.

Persönliche Zugriffstoken

Sie können persönliche Zugriffstoken generieren, um einer Anwendung Zugriff auf Ihr Konto zu gewähren. Bei der Erstellung eines persönlichen Zugriffstokens muss der Benutzer die Berechtigungen angeben, die das Token haben wird. https://github.com/settings/tokens

Oauth-Anwendungen

Oauth-Anwendungen können Sie um Berechtigungen bitten, um auf Teile Ihrer Github-Informationen zuzugreifen oder Sie zu impersonifizieren, um einige Aktionen auszuführen. Ein häufiges Beispiel für diese Funktionalität ist die Anmeldung mit Github-Schaltfläche, die Sie möglicherweise auf einigen Plattformen finden.

• Sie können Ihre eigenen Oauth-Anwendungen in https://github.com/settings/developers erstellen.
• Sie können alle Oauth-Anwendungen sehen, die Zugriff auf Ihr Konto haben in https://github.com/settings/applications.
• Sie können die Scopes sehen, die Oauth-Apps anfordern können in https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps.
• Sie können den Zugriff von Drittanwendungen in einer Organisation in https://github.com/organizations/<org_name>/settings/oauth_application_policy sehen.

Einige Sicherheitsempfehlungen:

• Eine OAuth-App sollte immer als der authentifizierte GitHub-Benutzer über das gesamte GitHub hinweg agieren (zum Beispiel, wenn Benutzerbenachrichtigungen bereitgestellt werden) und nur Zugriff auf die angegebenen Scopes haben.
• Eine OAuth-App kann als Identitätsanbieter verwendet werden, indem eine "Anmeldung mit GitHub" für den authentifizierten Benutzer aktiviert wird.
• Bauen Sie keine OAuth-App, wenn Sie möchten, dass Ihre Anwendung auf ein einzelnes Repository zugreift. Mit dem repo OAuth-Scope können OAuth-Apps auf allen** Repositories des authentifizierten Benutzers zugreifen**.
• Bauen Sie keine OAuth-App, um als Anwendung für Ihr Team oder Unternehmen zu agieren. OAuth-Apps authentifizieren sich als einzelner Benutzer, sodass, wenn eine Person eine OAuth-App für ein Unternehmen erstellt, und dann das Unternehmen verlässt, niemand sonst Zugriff darauf hat.
• Mehr dazu hier.

Github-Anwendungen

Github-Anwendungen können um Berechtigungen bitten, um auf Ihre Github-Informationen zuzugreifen oder Sie zu impersonifizieren, um spezifische Aktionen über spezifische Ressourcen auszuführen. In Github-Apps müssen Sie die Repositories angeben, auf die die App Zugriff haben wird.

• Um eine GitHub-App zu installieren, müssen Sie Organisationsinhaber oder über Administratorberechtigungen in einem Repository verfügen.
• Die GitHub-App sollte mit einem persönlichen Konto oder einer Organisation verbunden sein.
• Sie können Ihre eigene Github-Anwendung in https://github.com/settings/apps erstellen.
• Sie können alle Github-Anwendungen sehen, die Zugriff auf Ihr Konto haben in https://github.com/settings/apps/authorizations.
• Dies sind die API-Endpunkte für Github-Anwendungen https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Je nach den Berechtigungen der App kann sie auf einige von ihnen zugreifen.
• Sie können installierte Apps in einer Organisation in https://github.com/organizations/<org_name>/settings/installations sehen.

Einige Sicherheitsempfehlungen:

• Eine GitHub-App sollte unabhängig von einem Benutzer handeln (es sei denn, die App verwendet ein User-to-Server Token). Um die Sicherheit von User-to-Server-Zugriffstoken zu erhöhen, können Sie Zugriffstoken verwenden, die nach 8 Stunden ablaufen, und ein Refresh-Token, das gegen ein neues Zugriffstoken eingetauscht werden kann. Weitere Informationen finden Sie unter "Aktualisieren von User-to-Server-Zugriffstoken."
• Stellen Sie sicher, dass die GitHub-App mit spezifischen Repositories integriert ist.
• Die GitHub-App sollte mit einem persönlichen Konto oder einer Organisation verbunden sein.
• Erwarten Sie nicht, dass die GitHub-App alles weiß und tut, was ein Benutzer kann.
• Verwenden Sie keine GitHub-App, wenn Sie nur einen "Login mit GitHub"-Dienst benötigen. Aber eine GitHub-App kann einen Benutzeridentifikationsfluss verwenden, um Benutzer anzumelden und andere Dinge zu tun.
• Bauen Sie keine GitHub-App, wenn Sie nur als GitHub-Benutzer agieren und alles tun möchten, was dieser Benutzer tun kann.
• Wenn Sie Ihre App mit GitHub Actions verwenden und Workflow-Dateien ändern möchten, müssen Sie sich im Namen des Benutzers mit einem OAuth-Token authentifizieren, das den workflow-Scope enthält. Der Benutzer muss über Administrator- oder Schreibberechtigungen für das Repository verfügen, das die Workflow-Datei enthält. Weitere Informationen finden Sie unter "Verstehen der Scopes für OAuth-Apps."
• Mehr dazu hier.

Github Actions

Dies ist kein Weg, um sich bei Github zu authentifizieren, aber eine bösartige Github Action könnte unbefugten Zugriff auf Github erhalten und je nach den Berechtigungen, die der Action gegeben wurden, könnten mehrere verschiedene Angriffe durchgeführt werden. Siehe unten für weitere Informationen.

Git-Aktionen

Git-Aktionen ermöglichen es, die Ausführung von Code zu automatisieren, wenn ein Ereignis eintritt. In der Regel ist der ausgeführte Code irgendwie mit dem Code des Repositories verbunden (vielleicht einen Docker-Container bauen oder überprüfen, ob der PR keine Geheimnisse enthält).

Konfiguration

In https://github.com/organizations/<org_name>/settings/actions ist es möglich, die Konfiguration der Github-Aktionen für die Organisation zu überprüfen.

Es ist möglich, die Verwendung von Github-Aktionen vollständig zu verbieten, alle Github-Aktionen zuzulassen oder nur bestimmte Aktionen zuzulassen.

Es ist auch möglich zu konfigurieren, wer die Genehmigung benötigt, um eine Github-Aktion auszuführen und die Berechtigungen des GITHUB_TOKEN einer Github-Aktion, wenn sie ausgeführt wird.

Git-Geheimnisse

Github-Aktionen benötigen normalerweise eine Art von Geheimnissen, um mit Github oder Drittanbieteranwendungen zu interagieren. Um zu vermeiden, sie im Klartext im Repo zu speichern, erlaubt Github, sie als Geheimnisse zu speichern.

Diese Geheimnisse können für das Repo oder für die gesamte Organisation konfiguriert werden. Dann, damit die Aktion auf das Geheimnis zugreifen kann, müssen Sie es wie folgt deklarieren:

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}

Beispiel mit Bash

steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

Sobald sie im Repo oder in den Organisationen konfiguriert sind, werden die Benutzer von Github nicht mehr darauf zugreifen können, sie können sie nur ändern.

Daher ist der einzige Weg, Github-Geheimnisse zu stehlen, Zugriff auf die Maschine zu haben, die die Github Action ausführt (in diesem Szenario können Sie nur auf die für die Action deklarierten Geheimnisse zugreifen).

Git-Umgebungen

Github ermöglicht es, Umgebungen zu erstellen, in denen Sie Geheimnisse speichern können. Dann können Sie der Github Action Zugriff auf die Geheimnisse innerhalb der Umgebung gewähren, indem Sie etwas wie Folgendes verwenden:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

Sie können eine Umgebung so konfigurieren, dass sie von allen Branches (Standard), nur von geschützten Branches oder bestimmten Branches, die darauf zugreifen können, zugänglich ist.
Es kann auch eine Anzahl erforderlicher Überprüfungen festgelegt werden, bevor eine Aktion unter Verwendung einer Umgebung ausgeführt wird, oder es kann einige Zeit gewartet werden, bevor die Bereitstellungen fortgesetzt werden.

Git Action Runner

Eine Github-Aktion kann innerhalb der Github-Umgebung ausgeführt oder in einer drittanbieter Infrastruktur, die vom Benutzer konfiguriert wurde, ausgeführt werden.

Mehrere Organisationen erlauben es, Github-Aktionen in einer drittanbieter Infrastruktur auszuführen, da dies in der Regel günstiger ist.

Sie können die selbst gehosteten Runner einer Organisation unter https://github.com/organizations/<org_name>/settings/actions/runners auflisten.

Der Weg, um herauszufinden, welche Github-Aktionen in nicht-Github-Infrastrukturen ausgeführt werden, besteht darin, nach runs-on: self-hosted in der Github-Aktionskonfigurations-yaml zu suchen.

Es ist nicht möglich, eine Github-Aktion einer Organisation innerhalb einer selbst gehosteten Box einer anderen Organisation auszuführen, da ein einzigartiges Token für den Runner generiert wird, wenn er konfiguriert wird, um zu wissen, zu welcher Organisation der Runner gehört.

Wenn der benutzerdefinierte Github Runner auf einer Maschine innerhalb von AWS oder GCP konfiguriert ist, könnte die Aktion Zugriff auf den Metadaten-Endpunkt haben und das Token des Dienstkontos stehlen, mit dem die Maschine betrieben wird.

Git Action Kompromittierung

Wenn alle Aktionen (oder eine bösartige Aktion) erlaubt sind, könnte ein Benutzer eine Github-Aktion verwenden, die bösartig ist und den Container kompromittiert, in dem sie ausgeführt wird.

Branch-Schutz

Branch-Schutzmaßnahmen sind so konzipiert, dass sie nicht die vollständige Kontrolle über ein Repository an die Benutzer geben. Das Ziel ist es, mehrere Schutzmethoden zu implementieren, bevor man in einem bestimmten Branch Code schreiben kann.

Die Branch-Schutzmaßnahmen eines Repositories finden Sie unter https://github.com/<orgname>/<reponame>/settings/branches.

Verschiedene Schutzmaßnahmen können auf einen Branch (wie auf master) angewendet werden:

• Sie können eine PR vor dem Mergen verlangen (so dass Sie Code nicht direkt über den Branch mergen können). Wenn dies ausgewählt ist, können verschiedene andere Schutzmaßnahmen in Kraft treten:
• Eine Anzahl von Genehmigungen verlangen. Es ist sehr üblich, 1 oder 2 weitere Personen zu verlangen, die Ihre PR genehmigen, damit ein einzelner Benutzer nicht in der Lage ist, Code direkt zu mergen.
• Genehmigungen zurückweisen, wenn neue Commits gepusht werden. Andernfalls könnte ein Benutzer legitimen Code genehmigen und dann bösartigen Code hinzufügen und mergen.
• Überprüfungen von Code-Eigentümern verlangen. Mindestens 1 Code-Eigentümer des Repos muss die PR genehmigen (so dass "zufällige" Benutzer dies nicht genehmigen können).
• Einschränken, wer Pull-Request-Überprüfungen zurückweisen kann. Sie können Personen oder Teams angeben, die berechtigt sind, Pull-Request-Überprüfungen zurückzuweisen.
• Bestimmten Akteuren erlauben, die Anforderungen an Pull-Requests zu umgehen. Diese Benutzer können vorherige Einschränkungen umgehen.
• Statusprüfungen verlangen, die vor dem Mergen bestehen müssen. Einige Prüfungen müssen bestehen, bevor der Commit gemergt werden kann (wie eine Github-Aktion, die überprüft, dass es kein Klartextgeheimnis gibt).
• Gespräche vor dem Mergen lösen. Alle Kommentare zum Code müssen gelöst werden, bevor die PR gemergt werden kann.
• Signierte Commits verlangen. Die Commits müssen signiert sein.
• Lineare Historie verlangen. Verhindern, dass Merge-Commits in übereinstimmende Branches gepusht werden.
• Administratoren einbeziehen. Wenn dies nicht festgelegt ist, können Administratoren die Einschränkungen umgehen.
• Einschränken, wer in übereinstimmende Branches pushen kann. Einschränken, wer einen PR senden kann.

Referenzen

• https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization
• https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprisehttps://docs.github.com/en/enterprise-server
• https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github
• https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards
• https://docs.github.com/en/actions/security-guides/encrypted-secrets