Verwalten von Runnern
In diesem Abschnitt untersuchen Sie die verschiedenen Tools und Strategien, die Ihnen in GitHub Enterprise Cloud und GitHub Enterprise Server zur Verfügung stehen, um die Verwendung von GitHub Actions Runners in Ihrem Unternehmen zu verwalten.
Wählen Sie einen geeigneten Runner für Ihre Workload
Zwei Arten von Runnern können GitHub Actions-Workflows ausführen: Von GitHub-gehostete Runner oder selbst gehostete Runner.
Hinweis
Von GitHub gehostete Runner sind nur für Enterprise Cloud verfügbar. Wenn Sie über eine Enterprise Server-Instanz verfügen, gilt dieser Abschnitt nicht für Sie.
Von GitHub gehostete Runner bieten eine schnellere und einfachere Möglichkeit zum Ausführen Ihrer Workflows, während selbstgehostete Runner eine hochgradig konfigurierbare Möglichkeit zum Ausführen von Workflows in Ihrer eigenen benutzerdefinierten Umgebung sind. Wenn Sie beispielsweise eine Erlaubnisliste für IP-Adressen für Ihre Organisation benötigen oder eine spezielle Hardwarekonfiguration einsetzen müssen, um Ihre Workflows auszuführen, verwenden Sie einen selbstgehosteten Runner.
In der folgenden Tabelle werden von GitHub gehostete Runner und selbstgehostete Runner verglichen. Verwenden Sie sie, um den geeigneten Runner für Ihre Workload auszuwählen.
| Von GitHub gehostete Runner | Selbstgehostete Runner |
|---|---|
| Erhalten automatischer Updates für das Betriebssystem, vorinstallierte Pakete und Tools und die selbstgehostete Runneranwendung. | Erhalten automatischer Updates nur für die selbstgehostete Runneranwendung. Sie sind für die Aktualisierung des Betriebssystems und der übrigen Software verantwortlich. |
| Von GitHub verwaltet und gewartet. | Kann Clouddienste oder lokale Computer verwenden, für die du bereits bezahlst. Können außerdem an die Hardware, das Betriebssystem, die Software und Sicherheitsanforderungen angepasst werden. |
| Bereitstellen einer sauberen Instanz für jede Auftragsausführung. | Benötigen keine saubere Instanz für jede Auftragsausführung. |
| Verwenden Sie die kostenlosen Minuten Ihres GitHub-Tarifs. Danach werden Minutentarife angewendet, sobald die kostenlosen Minuten überschritten sind. | Können kostenlos mit GitHub Actions verwendet werden, aber Sie tragen die Kosten für die Wartung Ihrer Runnercomputer. |
Verwalten von Runnern für das Unternehmen
Das Verwalten von Runnern für das Unternehmen umfasst das Konfigurieren und Sichern von GitHub-gehosteten und selbst gehosteten Runnern, um effiziente und sichere CI/CD-Workflows sicherzustellen. Diese Verwaltung umfasst das Einrichten von IP-Zulassungslisten zum Steuern des Zugriffs, zur Verbesserung der Sicherheit durch Einschränken des Läuferzugriffs auf bestimmte IP-Adressen und die Sicherstellung der Einhaltung von Organisationsrichtlinien. Die ordnungsgemäße Konfiguration von IP-Zulassungslisten für von GitHub gehostete und selbst gehostete Läufer ist entscheidend für die Aufrechterhaltung sicherer und zuverlässiger Interaktionen zwischen internen Anwendungen und GitHub Actions-Runnern. Regelmäßige Updates und Überprüfungen dieser Konfigurationen sind erforderlich, um sich an Änderungen in IP-Adressbereichen anzupassen und optimale Sicherheit zu gewährleisten.
Konfigurieren von IP-Positivlisten auf von GitHub gehosteten und selbstgehosteten Runnern
Durch das Konfigurieren von IP-Zulassungslisten können Sie den Zugriff auf Läufer steuern, indem sie auf bestimmte IP-Adressen beschränkt werden. Diese Konfiguration verbessert die Sicherheit, indem nicht autorisierter Zugriff verhindert wird, aber möglicherweise weitere Netzwerkkonfigurationen erforderlich sind.
| Von GitHub gehostete Runner | Selbstgehostete Runner |
|---|---|
| Von GitHub gehostete Läufer verwenden dynamische IP-Adressen, wodurch es schwierig ist, präzise IP-Zulassungslisten zu konfigurieren. | Verwenden Sie statische oder kontrollierte IPs, sodass präzise IP-Zulassungslisten oder IP-basierte Zugriffssteuerung möglich sind. |
| Organisationen müssen die veröffentlichten IP-Bereiche von GitHub zulassen. | Kann hinter Firewalls oder VPNs für zusätzliche Sicherheit platziert werden. |
| Von GitHub gehostete Runner können mithilfe der Sicherheitsrichtlinien für Unternehmen von GitHub eingeschränkt werden. | Erfordert eine explizite Konfiguration für die Kommunikation mit externen Diensten, wodurch die Sicherheit verbessert wird. |
Liste zulässiger IP-Adressen
Eine zulässige IP-Liste ist ein Sicherheitsfeature, das den Zugriff auf Dienste oder Ressourcen basierend auf vordefinierten IP-Adressen einschränkt. Wenn Organisationen eine IP-Zulassungsliste konfigurieren, können sie:
- Verbessern sie die Sicherheit: Verhindern Sie nicht autorisierten Zugriff, indem Sie nur vertrauenswürdige IP-Adressen zulassen.
- Steuern des Netzwerkdatenverkehrs: Beschränken Sie eingehende und ausgehende Anforderungen auf bekannte und überprüfte IPs.
- Verbessern der Compliance: Stellen Sie die Einhaltung gesetzlicher Vorschriften sicher, indem Sie den Zugriff auf autorisierte Netzwerke einschränken.
| Von GitHub gehostete Runner | Selbstgehostete Runner |
|---|---|
| Organisationen müssen die veröffentlichten IP-Bereiche von GitHub zulassen, die sich in regelmäßigen Abständen ändern. | Administratoren können bestimmte IP-Adressen definieren, die auf die Läufer zugreifen dürfen. |
| GitHub-Runner können über die Sicherheitseinstellungen von GitHub konfiguriert werden. | Selbstgehostete Runner funktionieren gut mit Firewalls, VPNs oder Cloud-Sicherheitsgruppen. |
Konfigurieren von IP-Zulassungslisten für interne Anwendungen für die Interaktion mit GitHub-Hosted Runners
Um IP-Zulassungslisten für interne Anwendungen und Systeme für die Interaktion mit von GitHub gehosteten Läufern zu konfigurieren, können Sie sich auf die folgende offizielle GitHub-Dokumentation beziehen:
1. Grundlegendes zu den IP-Adressbereichen von GitHub
Von GitHub gehostete Ausführungsprozesse arbeiten innerhalb bestimmter IP-Adressbereiche. Um sicherzustellen, dass Ihre internen Anwendungen mit diesen Läufern kommunizieren können, müssen Sie diese IP-Bereiche über Ihre Firewall zulassen. GitHub stellt einen Meta-API-Endpunkt https://api.github.com/meta bereit, der alle aktuellen IP-Adressbereiche auflistet, die von GitHub-Diensten verwendet werden, einschließlich IP-Bereiche für Aktionsläufer. Eine regelmäßige Aktualisierung Ihrer Zulassungslisten basierend auf diesen Informationen ist unerlässlich, da sich IP-Bereiche ändern können.
2. Konfigurieren Sie Ihre Firewall
a) Abrufen der IP-Bereiche von GitHub:
- Verwenden Sie den Meta-API-Endpunkt, um die neuesten IP-Adressbereiche abzurufen, die von GitHub Actions runners verwendet werden.
b. Aktualisieren von Firewallregeln:
- Fügen Sie Ihrer Firewall Regeln hinzu, um eingehenden und ausgehenden Datenverkehr zu und aus diesen IP-Bereichen zuzulassen. Diese Konfiguration stellt sicher, dass Ihre internen Systeme ohne Konnektivitätsprobleme mit den von GitHub bereitgestellten Runner interagieren können.
3. Erwägen Sie die Verwendung selbstgehosteter Runner
Wenn die Aufrechterhaltung einer IP-Zulassungsliste für von GitHub gehostete Läufer aufgrund häufiger Änderungen in IP-Bereichen eine Herausforderung darstellt, sollten Sie in Ihrem Netzwerk selbst gehostete Läufer einrichten. Mit diesem Ansatz können Sie eine bessere Kontrolle über die Runner-Umgebung und die Netzwerkkonfigurationen erlangen. Die Verwendung von selbst gehosteten Läufern erfordert jedoch mehr Wartung und Infrastrukturverwaltung.
4. Regelmäßige Überprüfung und Aktualisierung von Positivlisten
Da sich die IP-Adressbereiche von GitHub ändern können, ist es wichtig, die IP-Zulassungslisten Ihrer Firewall regelmäßig zu überprüfen und zu aktualisieren. Durch die Automatisierung dieses Prozesses durch Skripts zum Abrufen von IP-Bereichen aus der Meta-API von GitHub kann sichergestellt werden, dass Ihre Zulassungslisten ohne manuelle Eingriffe aktuell bleiben.
Auswirkungen und potenzielle Missbrauchsvektoren durch das Aktivieren selbstgehosteter Runner in öffentlichen Repositorys
Auswirkungen der Aktivierung selbstgehosteter Runner
Anpassungs- und Leistungsoptimierung
- Eigenständig gehostete Runner ermöglichen die Kontrolle über Hardware, installierte Software und Umgebungseinstellungen.
- Workflows können mit dedizierten Hochleistungscomputern für die Leistung optimiert werden.
Kostenersparnis
- Im Gegensatz zu von GitHub gehosteten Läufern (die eingeschränkte kostenlose Nutzung haben), laufen selbst gehostete Läufer auf Ihrer Infrastruktur und reduzieren Kosteneinschränkungen.
Statuspersistenz
- Selbstgehostete Runner werden nicht wie von GitHub gehostete Runner zwischen Aufträgen zurückgesetzt.
- Ermöglicht das Zwischenspeichern von Abhängigkeiten, das ErneuteVerwenden großer Datasets und die Aufrechterhaltung persistenter Zustände.
Sicherheits- und Wartungsverantwortung
- Sicherheitspatches, Abhängigkeitsupdates und Systemüberwachung werden zur Verantwortung des Runnerbesitzes.
- Fehlkonfigurationen können den Runner externen Bedrohungen aussetzen.
Mögliche Missbrauchsvektoren von selbstgehosteten Runnern
Die Aktivierung selbstgehosteter Runner in öffentlichen Repositorys führt erhebliche Sicherheitsrisiken ein. Da jeder Workflows durch Übermitteln einer Pullanforderung auslösen kann, können Angreifer dieses Feature auf verschiedene Arten ausnutzen:
Willkürliche Codeausführung (RCE) durch böswillige Akteure
- Angreifende können Pull-Anforderungen mit bösartigen Skripts übermitteln, die der selbstgehostete Runner automatisch ausführt.
- Wenn der Läufer erhöhte Rechte hat, erhält der Angreifer vollen Systemzugriff.
Kryptowährungsmining und Ressourcennutzung
- Angreifer können selbstgehostete Runner missbrauchen, um Kryptowährung zu minen, was zu unerwartet hoher Auslastung von CPU und GPU führt.
- Dies erhöht die Betriebskosten und reduziert die Verfügbarkeit für legitime Workflows.
Datenexfiltration und Diebstahl von Anmeldeinformationen
- Wenn geheime Schlüssel (API-Schlüssel, Datenbankanmeldeinformationen, SSH-Schlüssel) auf dem Läufer gespeichert werden, könnten Angreifer sie extrahieren.
- Beispielangriffsvektor: Eine bösartige Pullanforderung könnte gespeicherte Umgebungsvariablen lesen und an einen externen Server senden.
Denial of Service (DoS)-Angriffe
- Angreifer können das Repository mit zahlreichen Pull-Anfragen überfluten, um selbstgehostete Runner zu überlasten.
- Wenn Läufer sich auf einer gemeinsamen Infrastruktur befinden, werden möglicherweise andere kritische Workflows unterbrochen.
Laterale Bewegung & Netzwerkausnutzung
- Wenn sich der selbst gehostete Runner innerhalb eines Unternehmensnetzwerks befindet, könnte sich ein Angreifer Zugang zu internen Systemen verschaffen.
- Könnte zu Datenschutzverletzungen, Ransomware-Angriffen oder dauerhaftem Zugriff auf private Ressourcen führen.
Minderungsstrategien
Um Sicherheitsrisiken zu reduzieren, befolgen Sie die folgenden bewährten Methoden:
- Beschränken Sie selbstgehostete Runner ausschließlich auf private Repositorys.
- Anfordern der Workflowgenehmigung für Pullanforderungen von externen Mitwirkenden
- Führen Sie selbst gehostete Runner in einer sicheren, isolierten Umgebung aus (z. B. Container, virtuelle Maschinen)
- Verwenden von Firewalls und Netzwerkregeln zum Blockieren des nicht autorisierten Zugriffs
- Beschränken des Zugriffs auf vertrauliche geheime Schlüssel und sicheres Speichern von Anmeldeinformationen
- Überwachen und Protokollieren von Läuferaktivitäten zum Erkennen von Anomalien
Auswählen geeigneter Runner zur Unterstützung von Workloads
Grundlegendes zu GitHub-Runnern
GitHub-Aktionen unterstützen zwei Arten von Läufern:
Von GitHub gehostete Runner
- Von GitHub verwaltet, automatisch bereitgestellt und skaliert.
- Umfasst vorinstallierte Software, Tools und Abhängigkeiten für allgemeine Workflows.
- Verfügbar für Windows, Linux und macOS.
- Empfohlen für allgemeine Automatisierung, Open-Source-Projekte und Schnelles Einrichten.
Selbstgehostete Runner
- Vom Benutzer verwaltet und bietet volle Kontrolle über Umgebung und Ressourcen.
- Kann für benutzerdefinierte Hardware, lokale oder Cloudinfrastruktur konfiguriert werden.
- Unterstützt persistente Zustände zwischen Aufträgen und ermöglicht eine bessere Zwischenspeicherung und benutzerdefinierte Abhängigkeiten.
- Empfohlen für private Repositorys, Unternehmensworkloads und leistungsintensive Aufgaben.
Auswählen zwischen von GitHub gehosteten und selbst gehosteten Runnern
Zwei Arten von Runnern können GitHub Actions-Workflows ausführen: Von GitHub-gehostete Runner oder selbst gehostete Runner.
Hinweis
Von GitHub gehostete Runner sind nur für Enterprise Cloud verfügbar. Wenn Sie über eine Enterprise Server-Instanz verfügen, gilt dieser Abschnitt nicht für Sie.
Von GitHub gehostete Runner bieten eine schnellere und einfachere Möglichkeit zum Ausführen Ihrer Workflows, während selbstgehostete Runner eine hochgradig konfigurierbare Möglichkeit zum Ausführen von Workflows in Ihrer eigenen benutzerdefinierten Umgebung sind. Wenn Sie beispielsweise eine Erlaubnisliste für IP-Adressen für Ihre Organisation benötigen oder eine spezielle Hardwarekonfiguration einsetzen müssen, um Ihre Workflows auszuführen, verwenden Sie einen selbstgehosteten Runner.
In der folgenden Tabelle werden von GitHub gehostete Runner und selbstgehostete Runner verglichen. Verwenden Sie sie, um den geeigneten Runner für Ihre Workload auszuwählen.
| Von GitHub gehostete Runner | Selbstgehostete Runner |
|---|---|
| Erhalten automatischer Updates für das Betriebssystem, vorinstallierte Pakete und Tools und die selbstgehostete Runneranwendung. | Erhalten automatischer Updates nur für die selbstgehostete Runneranwendung. Sie sind für die Aktualisierung des Betriebssystems und der übrigen Software verantwortlich. |
| Von GitHub verwaltet und gewartet. | Kann Clouddienste oder lokale Computer verwenden, für die du bereits bezahlst. Können außerdem an die Hardware, das Betriebssystem, die Software und Sicherheitsanforderungen angepasst werden. |
| Bereitstellen einer sauberen Instanz für jede Auftragsausführung. | Benötigen keine saubere Instanz für jede Auftragsausführung. |
| Verwenden Sie die kostenlosen Minuten Ihres GitHub-Tarifs. Danach werden Minutentarife angewendet, sobald die kostenlosen Minuten überschritten sind. | Können kostenlos mit GitHub Actions verwendet werden, aber Sie tragen die Kosten für die Wartung Ihrer Runnercomputer. |
Auswählen des richtigen Betriebssystems für Läufer
1. Linux-Runner (Standard)
- Optimal für die meisten Workloads
- Schnell, kostengünstig und weit unterstützt
- Wird in CI/CD, Skripting, Docker und Automatisierung verwendet
Beispiel:ubuntu-latest,ubuntu-22.04
2. Windows-Runner
- Erforderlich für .NET-, Windows-basierte Software- und GUI-Apps
- Unterstützt PowerShell- und Windows-spezifische Abhängigkeiten
Beispiel:windows-latest,windows-2022
3. macOS-Runner
- macOS-Runner sind für iOS-, macOS-, Xcode- und Apple-spezifische Builds erforderlich.
- Unterstützt Swift-, Objective-C- und macOS-Anwendungen
Beispiel:macos-latest,macos-13
Bewährte Methoden für die Auswahl von Läufern
- Verwenden Sie von GitHub gehostete Runner für generelle Workflows und Automatisierungen.
- Verwenden Sie selbstgehostete Runner für benutzerdefinierte Umgebungen, große Workloads oder sicherheitskritische Anwendungen.
- Wählen Sie Linux-Läufer für die meisten Workloads aufgrund der Leistung und Kosteneffizienz aus.
- Verwenden Sie Windows- oder macOS-Läufer nur, wenn sie aus Kompatibilitätsgründen erforderlich sind.
- Aktualisieren und überwachen Sie selbst gehostete Runner regelmäßig, um Sicherheitsrisiken zu vermeiden.
Vergleich von GitHub-gehosteten und selbst-gehosteten Runnern
GitHub-Aktionen unterstützen zwei Arten von Läufern zum Ausführen von Workflows:
- GitHub-gehostete Runner – Von GitHub verwaltet, automatisch bereitgestellt und mit allgemeinen Entwicklungstools vorkonfiguriert.
- Selbstgehostete Runner – Vom Benutzer verwaltet und ermöglicht vollständige Kontrolle über die Umgebung, Ressourcen und Konfigurationen.
In diesem Abschnitt werden die wichtigsten Unterschiede zwischen GitHub-gehosteten und selbst-gehosteten Runnern hervorgehoben.
Vergleich: Von GitHub gehostete im Vergleich mit Selbstgehosteten Runnern
| Merkmal | Auf GitHub gehosteter Runner | Selbstgehostete Runner |
|---|---|---|
| Einrichtung und Wartung | Kein Setup erforderlich; GitHub verwaltet alles | Der Benutzer muss installieren, konfigurieren und verwalten |
| Skalierbarkeit | Automatische Skalierung dynamisch | Muss hinzugefügte Läufer manuell bereitstellen |
| Sicherheit | Hohe Sicherheit; frische virtuelle Umgebung für jeden Auftrag | Erfordert manuelle Sicherheitshärtung |
| Anpassung | Begrenzt; Nur vorinstallierte Tools | Vollständig anpassbar; Benutzer können alle Abhängigkeiten installieren. |
| Leistung | Standardisierte Computeressourcen | Kann Hochleistungshardware verwenden |
| Statuspersistenz | Wird nach jedem Auftrag zurückgesetzt | Kann Daten zwischen Aufträgen beibehalten |
| Kosten | Kostenlos für öffentliche Repositorys; begrenzte kostenlose Nutzung für private Repositorys | Keine GitHub-Kosten, erfordert aber Infrastrukturinvestitionen |
| Netzwerkzugriff | Kein direkter Zugriff auf interne Netzwerke | Kann auf interne/private Netzwerke zugreifen |
| Anwendungsfall | Am besten geeignet für allgemeine CI/CD-, Automatisierungs- und Open-Source-Projekte | Optimal für Unternehmensumgebungen, sichere Builds und große Workloads |
Wichtige Unterschiede und Überlegungen
1. Einrichtung & Wartung
- GitHub-gehostete Runner erfordern keine Einrichtung; Benutzer können sofort mit der Ausführung von Workflows beginnen.
- Selbst-gehostete Runner benötigen manuelle Installation, Konfiguration, Aktualisierungen und Sicherheitsverwaltung.
2. Sicherheitsrisiken
- Von GitHub gehostete Runner werden in isolierten virtuellen Maschinen ausgeführt, die nach jedem Job zurückgesetzt werden, wodurch Angriffsflächen minimiert werden.
- Selbstgehostete Runner bestehen über mehrere Aufträge fort, sodass ein kompromittierter Runner in mehreren Workflows ausgenutzt werden kann.
3. Überlegungen zu Leistungs- und Kostenkosten
- GitHub-gehostete Runner bieten eine Standardumgebung, weisen jedoch Nutzungsgrenzwerte auf (z. B. kostenlose Minuten pro Monat für private Repositories).
- Selbst gehostete Runner ermöglichen eine bessere Leistungsoptimierung (z. B. auf High-End-Servern), verursachen jedoch Infrastruktur- und Wartungskosten.
4. Netzwerk & Zugriff
- Von GitHub gehostete Läufer können ohne weitere Konfigurationen nicht auf private/interne Ressourcen zugreifen .
- Selbstgehostete Runner können auf interne Systeme zugreifen, was sie ideal für private Repositories, interne Tools und lokale Bereitstellungen macht.
Wann sollte man jeden Runner verwenden?
Verwenden Sie GitHub-gehostete Runner, wenn:
- Sie benötigen eine schnelle und einfache Einrichtung ohne Infrastrukturverwaltung.
- Ihr Workflow erfordert keine benutzerdefinierten Abhängigkeiten über die vorinstallierten Tools hinaus.
- Sie arbeiten an einem Open Source- oder öffentlichen Repository mit kostenlos gehosteten Runnerminuten.
Verwenden Sie selbstgehostete Runner in folgenden Fällen:
- Ihr Workflow erfordert bestimmte Abhängigkeiten, Konfigurationen oder persistente Zustände.
- Sie müssen auf private Netzwerkressourcen zugreifen (z. B. lokale Datenbanken, interne Dienste).
- Für große CI/CD-Pipelines sind Computer mit höherer Leistung erforderlich.