Wie isoliert man externe PRs auf einem GitHub Actions Mac Runner 2026?

Der Beitrag zeigt Maintainerinnen und Maintainer, Sicherheitsteams und Plattformverantwortlichen, wann externe PRs auf selbst gehosteten macOS-Runnern ein Risiko darstellen. Sie erhalten eine Prüflogik für Workflow-Herkunft, Runner-Zugriff, Geheimnisse, Bereinigung und Wiederherstellung.

Geeignet: Isolieren Sie externe PRs konsequent von langfristig betriebenen GitHub Actions Mac Runnern, sobald diese Runner Geheimnisse, Veröffentlichungszugänge oder wiederverwendbare Arbeitszustände erreichen können. Nicht geeignet: Ein selbst gehosteter Mac Runner ist keine passende Standardumgebung für nicht vertrauenswürdigen Code, wenn Sie dessen Zugriff und anschließende Bereinigung nicht verlässlich begrenzen können. In diesem Fall gehört der Test auf eine isolierte Umgebung oder muss blockiert werden.

Dieser Beitrag richtet sich an Maintainer offener Projekte, die über Runner-Zugriff für externe Beiträge entscheiden. Er hilft iOS-Sicherheitsteams, Test-Builds von Signierung und Veröffentlichung zu trennen. Plattformteams erhalten eine prüfbare Grundlage für Runner-Gruppen, Bereinigung und Wiederherstellung.

Die Vertrauensgrenze beginnt beim ausgeführten Workflow-Code

Entscheidend ist nicht allein, wer den Pull Request (PR) erstellt hat. Entscheidend ist, welchen Workflow-Code GitHub Actions ausführt und welche Rechte dieser Code während des Laufs erhält. Ein Test, der Änderungen aus einem externen Beitrag auscheckt oder Skripte daraus startet, führt grundsätzlich Code aus, den das Team nicht vorab kontrolliert hat. GitHub warnt ausdrücklich vor den Risiken, nicht vertrauenswürdige Pull-Request-Inhalte auf selbst gehosteten Runnern auszuführen: Solche Runner können durch einen Job kompromittiert werden und anschließend andere Jobs oder erreichbare Ressourcen gefährden. Die GitHub-Dokumentation zur sicheren Nutzung von Actions beschreibt diese Grenze.

Ein Mac Runner ist dabei nicht automatisch eine frische, kurzlebige virtuelle Maschine. Selbst gehostete Runner können wiederverwendet werden. Arbeitsverzeichnisse, Caches, temporäre Dateien, installierte Werkzeuge und noch laufende Prozesse können daher für nachfolgende Aufgaben relevant sein. Eine erfolgreiche Build-Meldung sagt nichts darüber aus, ob der Knoten anschließend einen sauberen Zustand hat.

Auch der Trigger ist Teil der Sicherheitsprüfung. Bei pull_request kommen Ereignisse von Forks und internen Branches unter unterschiedlichen Vertrauensbedingungen zustande. pull_request_target läuft dagegen im Kontext des Basis-Repositorys und kann dadurch Zugriff auf privilegiertere Ressourcen erhalten. GitHub erklärt, dass dieser Trigger nicht mit ungeprüftem Code aus dem PR kombiniert werden darf; insbesondere darf ein Workflow nicht einfach dessen Inhalt auschecken und ausführen. Die Übersicht zu auslösenden Workflow-Ereignissen und die Sicherheitsanleitung zu pull_request_target grenzen diese Fälle ab.

Können externe PRs auf einem selbst gehosteten Mac Runner laufen? Technisch lässt sich ein solcher Ablauf konfigurieren. Als Standard sollten Sie ihn jedoch ablehnen, wenn der Runner Zugang zu Geheimnissen, internen Netzen, Signiermaterial oder persistenten Daten hat. Eine Freigabe ist erst vertretbar, wenn der Job tatsächlich isoliert ist, nur die nötigen Ressourcen erreicht und sein Zustand nach dem Lauf überprüft wird. Ein vermeintlich harmloser Testjob kann ebenso ausführbaren Code aus dem Beitrag aufrufen wie ein Build-Skript.

Die Tabelle ist eine betriebliche Einstufung, keine automatische Garantie der Plattform. Prüfen Sie bei jedem Eintrag den konkreten Workflow: Trigger, ausgecheckten Commit, aufgerufene Skripte, Token-Rechte und erreichbare Runner. GitHub weist außerdem darauf hin, dass ein für Fork-PRs eingeschränkter Geheimniszugriff nicht alle Risiken eines selbst gehosteten Runners aufhebt. Der Runner selbst und seine Umgebung bleiben Teil der Sicherheitsgrenze.

Der Runner-Zugriff endet nicht beim Label

Ein häufiger Fehler ist, ein Label wie macOS oder ios-build als Zugriffsschutz zu behandeln. Labels helfen bei der Auswahl eines passenden Runners. Sie entscheiden aber nicht, welche Repositorys diesen Runner verwenden dürfen. Ein Workflow kann das richtige Label angeben und trotzdem auf eine zu breit freigegebene Runner-Gruppe treffen.

Prüfen Sie stattdessen die Gruppe und ihre Repository-Zugriffe. GitHub erlaubt bei Runner-Gruppen, festzulegen, welche Repositorys oder Organisationen die Gruppe verwenden dürfen. Die Anleitung zur Verwaltung des Zugriffs auf selbst gehostete Runner beschreibt diese Kontrolle; die Dokumentation zu Runner-Gruppen erklärt ihre Rolle bei der Zuweisung.

Wie begrenzen Sie, welche Repositorys selbst gehostete Runner verwenden können? Öffnen Sie die Einstellungen der Runner-Gruppe auf Organisationsebene und prüfen Sie die ausdrücklich zugelassenen Repositorys. Entfernen Sie breite Freigaben, wenn nur einzelne Projekte den Mac Runner benötigen. Kontrollieren Sie anschließend, ob Workflow-Dateien aus den freigegebenen Repositorys tatsächlich auf die Gruppe routen können. Eine Gruppenfreigabe, die alle Repositorys einer Organisation umfasst, ist nicht automatisch angemessen, nur weil die Organisation intern verwaltet wird.

Für GitHub Actions self-hosted runner security genügt es nicht, nur die YAML-Datei zu lesen. Prüfen Sie die Einstellungen der Runner-Gruppe in der Organisation und die tatsächliche Zuordnung des Repositorys. Kontrollieren Sie auch Änderungen an Workflow-Dateien: Der Quellcode eines PR kann beeinflussen, welche Schritte ein Job ausführt. Dokumentieren Sie deshalb, wer Gruppenfreigaben ändern darf und wer sie regelmäßig überprüft.

Testaufträge und Veröffentlichungen benötigen getrennte Rechte

Ein PR-Test benötigt in der Regel nicht dieselben Berechtigungen wie ein Release. Trotzdem gelangen Signierschlüssel, Veröffentlichungsgeheimnisse und weitreichende Tokens leicht in gemeinsame Workflow-Konfigurationen oder Runner-Umgebungen. Trennen Sie Test und Release nicht nur durch unterschiedliche Job-Namen. Trennen Sie die tatsächlichen Geheimnisse, Berechtigungen und Runner-Ziele.

GitHub erläutert, wie Geheimnisse in Workflows verfügbar gemacht werden und welche Grenzen dabei gelten. Prüfen Sie die offizielle Anleitung zur Verwendung von Geheimnissen. Ein Geheimnis ist nicht dadurch geschützt, dass es im normalen Job-Log nicht sichtbar ist. Unvertrauenswürdiger Code kann versuchen, erreichbare Daten über Ausgaben, Netzwerkzugriffe oder andere Nebenkanäle offenzulegen. Deshalb gilt: Ein PR-Job erhält keine Signier- oder Release-Geheimnisse, nur weil ein Workflow-Schritt sie aktuell nicht ausdrücklich ausgibt.

Wie halten Sie Signiergeheimnisse von PR-Tests fern? Verwenden Sie getrennte Workflows oder Jobs mit unterschiedlichen Berechtigungen und Runner-Zielen. Stellen Sie sicher, dass der Testjob keine Geheimnisse aus dem Release-Kontext referenziert und dass seine Token-Rechte nicht unnötig weit reichen. Binden Sie pull_request_target nicht als Abkürzung ein, um Fork-PRs privilegiert zu bauen. Wenn ein Workflow Informationen aus einem PR benötigt, prüfen Sie sorgfältig, ob und wie der Inhalt sicher verarbeitet wird, ohne ihn als ausführbaren Code im privilegierten Kontext zu starten.

In der Praxis ist auch die Sichtbarkeit von Zugangsdaten zu prüfen: Umgebungsvariablen, Keychain-Einträge, lokale Konfigurationsdateien und Berechtigungen auf dem Runner können einen Zugriff ermöglichen, selbst wenn der Workflow keine offensichtliche Geheimnisreferenz enthält. Eine sichere Trennung muss also an der Runner-Umgebung und am Workflow nachvollziehbar sein. Eine bloße Suche nach Geheimnisnamen in YAML ist kein vollständiger Test für die macOS-CI-Berechtigungen.

Der Runner-Zustand nach dem Job muss überprüfbar sein

Auf einem gemeinsam verwendeten Knoten besteht das Risiko nicht nur aus Dateien im Checkout. Prüfen Sie auch Caches, temporäre Verzeichnisse, heruntergeladene Werkzeuge, Berechtigungen, Keychain-Zustände und Hintergrundprozesse. Welche davon im konkreten Fall relevant sind, hängt davon ab, was Ihre Jobs installieren und ausführen. Eine Konfiguration, die einen Arbeitsordner entfernt, belegt nicht automatisch, dass alle übrigen Zustände verschwinden.

GitHub dokumentiert die Möglichkeit, Skripte vor und nach einem Runner-Job auszuführen. Die Anleitung zu Runner-Skripten vor und nach Jobs kann beim Aufbau einer Bereinigungsroutine helfen. Sie ersetzt aber weder einen Test noch den Nachweis, dass ein abgebrochener Job, ein Prozessabsturz oder ein kompromittierter Job keine verwertbaren Spuren hinterlässt.

Was prüfen Sie nach einem externen Auftrag? Führen Sie einen nicht sensiblen Testjob aus, der typische Build-Schritte simuliert, und kontrollieren Sie danach den realen Runner. Prüfen Sie, ob der Arbeitsbereich entfernt oder zurückgesetzt wurde, temporäre Dateien verschwunden sind, keine unerwarteten Prozesse weiterlaufen und keine Geheimnisse oder Authentifizierungsdaten im Job-Kontext verbleiben. Wiederholen Sie den Test auch für einen abgebrochenen oder fehlgeschlagenen Lauf, wenn Ihre Bereinigungslogik solche Zustände unterschiedlich behandelt.

Bewerten Sie nicht nur den erfolgreichen Standardfall. Runner-Skripte können bei Abbruch, Prozessfehler oder einem Neustart anders wirken als nach einem normalen Job-Ende. Notieren Sie, welche Prüfungen tatsächlich ausgeführt wurden, welche Person das Ergebnis freigibt und wie ein auffälliger Zustand zur Sperrung des Knotens führt. Ein einmaliger sauberer Test ist ein Nachweis für diesen Testlauf, aber keine dauerhafte Sicherheitsgarantie.

Erste Schritte für eine belastbare Prüfung

1. Workflow-Herkunft erfassen. Listen Sie Trigger wie pull_request und pull_request_target auf. Notieren Sie, ob der Job Code aus dem PR auscheckt, Skripte daraus startet oder Artefakte daraus verarbeitet.
2. Runner-Zuordnung nachweisen. Erfassen Sie Runner-Gruppe und Labels für jeden Job. Prüfen Sie in den Organisationseinstellungen, welche Repositorys tatsächlich auf die Gruppe zugreifen dürfen.
3. Berechtigungen reduzieren. Kontrollieren Sie Token-Rechte und alle Geheimnisreferenzen. Entfernen Sie aus externen Testläufen Signier-, Release- und andere nicht benötigte Zugangsdaten.
4. Zustandsgrenzen festlegen. Dokumentieren Sie, welche Arbeitsbereiche, Caches, temporären Dateien und Prozesse nach einem Lauf entfernt oder zurückgesetzt werden müssen.
5. Nicht sensibel testen. Starten Sie einen repräsentativen Testjob ohne echte Geheimnisse. Kontrollieren Sie den Runner nach einem erfolgreichen Lauf und, soweit relevant, nach einem fehlgeschlagenen oder abgebrochenen Lauf.
6. Wiederherstellung festlegen. Bestimmen Sie, wer den Runner bei fehlgeschlagener Bereinigung sperrt, den Zustand untersucht und die Wiederfreigabe dokumentiert.
7. Regelmäßig erneut prüfen. Wiederholen Sie die Prüfung nach Änderungen an Runner-Gruppen, Workflow-Dateien, Bereinigungsskripten oder Zugriffsrechten.

Diese Schritte liefern keinen Zertifizierungsnachweis und ersetzen keine organisationsspezifische Sicherheitsprüfung. Sie machen aber sichtbar, an welchen Stellen ein untrusted Job auf privilegierte Ressourcen treffen könnte. Für Datenschutzfragen rund um gespeicherte Daten und deren Verarbeitung finden Sie ergänzende Angaben in unserer Datenschutzerklärung.

Blockier- und Umleitungsregeln für nicht vertrauenswürdige Jobs

Nutzen Sie die folgende Entscheidungslogik als Abnahmebedingung. „Teilweise erfüllt“ gilt dabei als nicht bestanden, sobald der offene Punkt Zugriff auf Geheimnisse, andere Jobs oder einen gemeinsam genutzten Runner ermöglichen könnte.

• Wenn externe PRs auf eine Gruppe mit Zugriff auf Signierung, Veröffentlichung oder interne Ressourcen laufen können, dann sperren Sie diese Zuordnung und leiten Sie die Tests auf eine isolierte Umgebung um.
• Wenn der Workflow nicht eindeutig erkennen lässt, welchen Commit er ausführt oder ob er Code aus dem PR startet, dann behandeln Sie den Auftrag als nicht vertrauenswürdig und geben den persistenten Mac Runner nicht frei.
• Wenn Geheimnisse oder weitreichende Berechtigungen für einen PR-Test verfügbar sind, dann entfernen Sie sie aus diesem Ausführungspfad, bevor Sie den Test erneut zulassen.
• Wenn Bereinigung oder Prozesskontrolle nach einem Test nicht nachweisbar ist, dann nehmen Sie den Knoten aus dem Pool, untersuchen den Zustand und stellen ihn erst nach dokumentierter Wiederherstellung wieder bereit.
• Wenn Zugriff, Geheimnisse und Bereinigung geprüft und bestanden sind, dann bleibt die Freigabe auf den konkreten Workflow und die freigegebene Runner-Gruppe beschränkt. Übertragen Sie sie nicht automatisch auf andere Repositorys oder Aufgaben.

Die Punkteskala ist ein internes Abnahmemodell für diesen Beitrag, keine GitHub-Bewertung und kein Sicherheitsstandard. Ein niedriger Gesamtwert lässt einen kritischen Fehler nicht verschwinden: Sobald ein nicht bestandener Bereich Zugriff auf Geheimnisse oder gemeinsam genutzte Runner ermöglicht, bleibt der Auftrag blockiert. Entscheidend sind die konkreten Fehlerbedingungen, nicht eine rechnerische Gesamtnote.

Die passende Betriebsform hängt von den Sicherheitsgrenzen ab

Ein langfristig wiederverwendeter Mac Runner kann für kontrollierte Builds sinnvoll sein, ist aber eine schlechte Auffanglösung für beliebigen externen Code. Er bringt wiederverwendbaren Zustand, Verwaltungsaufwand für Bereinigung und Wiederherstellung sowie ein Risiko durch zu breite Runner-Gruppen mit sich. Eine getrennte Ausführungsumgebung reduziert die Kopplung, muss jedoch ebenfalls auf Zugriff, Geheimnisse und Lebenszyklus geprüft werden. Ein eigener physischer Mac kann passen, wenn dauerhaft kontrollierte Last und direkte Geräte- oder Hardwarezugriffe erforderlich sind. Für kurzzeitige Tests kann ein gemieteter Mac wirtschaftlicher sein als ein dauerhaft selbst verwalteter Knoten; daraus folgt jedoch nicht automatisch, dass der Dienst externe PRs isoliert oder temporäre Runner bereitstellt.

Vergleichen Sie vor einer Änderung die tatsächlichen Engpässe: Welche Repositorys dürfen den Knoten erreichen? Welche Daten bleiben nach dem Job zurück? Wer trägt die Verantwortung für Updates, Schlüssel und Wiederherstellung? Wenn Sie eine externe Mac-Umgebung evaluieren, prüfen Sie vorab deren dokumentierte Zugriffsgrenzen und Bereinigungsmöglichkeiten, statt eine Sicherheitsfunktion aus der Verfügbarkeit eines Mac abzuleiten. Informationen zu einem möglichen gemieteten Mac mini in Japan sind ein Ausgangspunkt für die Infrastrukturprüfung, aber kein Beleg für eine bestimmte Runner-Isolation.

Der sinnvollste nächste Schritt ist daher nicht, den bestehenden Runner pauschal abzuschalten oder externe PRs pauschal zuzulassen. Prüfen Sie zuerst die Repository-Freigaben, den Workflow-Kontext, die erreichbaren Geheimnisse und den realen Zustand nach einem Testlauf. Wenn einer dieser Punkte offenbleibt, sollte der nicht vertrauenswürdige Auftrag bis zur Klärung auf eine getrennte Umgebung wechseln. So entscheiden Sie anhand der tatsächlichen Betriebsgrenzen, ob ein selbst verwalteter Mac, eine andere isolierte Umgebung oder ein zeitlich begrenzter Mac-Einsatz zu Ihrem CI-Prozess passt.