Sind selbst gehostete Mac Runner für GitHub Actions sicher? Isolations-Checkliste 2026

Ein privates Repository ist kein automatischer Vertrauensnachweis. Entscheidend ist, wer Workflows ändern kann, wer einen Lauf auslöst, welche Pull Requests verarbeitet werden und welche Geheimnisse der Job erreicht. Ein selbst gehosteter Runner arbeitet auf einem dauerhaften Host. Schadcode kann deshalb nicht nur das aktuelle Arbeitsverzeichnis lesen, sondern auch Benutzerkonfigurationen, Prozesse, lokale Schlüssel oder erreichbare Netzwerkdienste untersuchen.

GitHub weist ausdrücklich auf die Risiken selbst gehosteter Runner hin. Die Sicherheitswarnung beschreibt, dass ein Runner durch nicht vertrauenswürdigen Code kompromittiert werden kann und dass eine solche Kompromittierung über den einzelnen Job hinaus bestehen kann. Für diese Grenze ist die offizielle Anleitung zur sicheren Nutzung von GitHub Actions die maßgebliche Referenz.

Prüfen Sie vor der Freigabe:

• Wer darf Workflow-Dateien ändern?
• Wer darf einen Workflow manuell starten?
• Welche externen Mitwirkenden dürfen Pull Requests öffnen?
• Werden Pull-Request-Workflows aus Forks ausgeführt?
• Wer genehmigt Produktionsumgebungen?
• Welche Repositorys und Organisationen dürfen den Runner verwenden?
• Welche Personen können Runner registrieren, entfernen oder Gruppen ändern?

Die Entscheidung darf nicht vom Status „Online“ abhängen. Online bedeutet, dass der Runner kommunizieren kann. Es bedeutet nicht, dass der Host sauber, unverändert oder für ein anderes Repository geeignet ist.

Runner Groups bilden die erste organisatorische Grenze. Ermitteln Sie, ob der Runner auf Repository-, Organisations- oder Unternehmensebene registriert ist. Danach prüfen Sie, welche Repositorys auf diese Gruppe zugreifen dürfen. Eine zu weit geöffnete Standardgruppe kann dazu führen, dass ein neuer oder bisher unkritischer Workflow denselben Mac erreicht.

Tags helfen bei der Auswahl, sind aber keine ausreichende Sicherheitsgrenze. Ein Label wie macos-arm64 beschreibt die gewünschte Plattform. Es beweist nicht, dass nur ein bestimmtes Repository den Knoten verwenden darf. Die GitHub-Dokumentation zu Runner Groups und die Dokumentation zur Auswahl eines Runners für einen Job sollten bei jeder Änderung der Zuordnung erneut geprüft werden.

Die Abnahme braucht zwei Gegenproben:

Ergänzen Sie diese Prüfung um die Workflow-Ereignisse. pull_request, manuelle Auslösung und Wiederholung eines fehlgeschlagenen Jobs können unterschiedliche Rechtepfade erzeugen. Die Repository-Allowlist, der Workflow-Kontext und die Runner Group müssen gemeinsam eine Entscheidung erzwingen. Wenn nur ein Tag den Zielknoten bestimmt, ist die Grenze zu schwach.

Nicht jedes Geheimnis hat denselben Wert. Ein kurzlebiger Build-Token, ein Bereitstellungsschlüssel, eine Apple-Signaturidentität und eine Produktionsfreigabe benötigen unterschiedliche Kontrollen. Legen Sie diese Materialien nicht dauerhaft in ein gemeinsames Benutzerprofil und nicht auf denselben Runner.

Prüfen Sie beim GITHUB_TOKEN die tatsächlich benötigten Berechtigungen. Ein Build benötigt normalerweise keinen Schreibzugriff auf jedes Repositoryobjekt. Setzen Sie Rechte so eng wie möglich und testen Sie anschließend, dass ein absichtlich nicht benötigter Vorgang abgewiesen wird. Für produktive Abläufe sollten Umgebungen, Freigaben und Geheimnisse getrennt vom normalen Build definiert werden. Die GitHub-Dokumentation zu Umgebungen und Bereitstellungsfreigaben beschreibt diese Kontrollpunkte.

Die Umgebungsgenehmigung löst jedoch kein Hostproblem. Wenn ein nicht vertrauenswürdiger Job bereits Code auf dem Mac ausführen darf, kann er unter Umständen lokale Daten und Prozesse untersuchen. Eine spätere Genehmigung verhindert nicht automatisch, dass der Host vorher verändert wurde.

Für Apple-Signaturen ist die Benutzer- und Keychain-Grenze entscheidend. Prüfen Sie, unter welchem macOS-Konto der Runner-Dienst läuft, welche Keychain geöffnet werden kann und ob Zertifikate oder private Schlüssel in Logs, Exportdateien oder temporären Verzeichnissen auftauchen. Apples Technische Notiz zu Code-Signing-Zertifikaten ist die Referenz für die Eigenschaften und den Umgang mit diesem Signaturmaterial.

Entscheidung: gemeinsamer Build- oder separater Signatur-Runner

• Wenn der Knoten fremde Pull Requests verarbeitet, wählen Sie keinen Signatur-Runner.
• Wenn der Knoten nicht automatisch sauber zurückgesetzt werden kann, wählen Sie keinen dauerhaften Produktionsknoten.
• Wenn derselbe Account sowohl Build-Skripte als auch Signaturmaterial lesen kann, trennen Sie die Jobs und Konten.
• Wenn eine Veröffentlichung eine manuelle Freigabe benötigt, muss der Signaturjob auf einem eigenen, nicht gemeinsam genutzten Runner liegen.
• Wenn die Organisation diese Trennung nicht nachweisen kann, bleibt der Mac auf nicht signierte Builds beschränkt.

Für einen ausführlicheren technischen Vergleich können Sie die Anleitung zur Trennung von Remote-Mac-CI-Signaturzertifikaten als Ausgangspunkt für Ihre interne Architekturprüfung verwenden.

Ein rm -rf auf dem Checkout-Verzeichnis beweist keine Bereinigung. Xcode erzeugt zusätzliche Artefakte. Dazu gehören abgeleitete Daten, Archive, Testberichte und Cache-Dateien. Build-Skripte können außerdem temporäre Dateien, Shell-Profile, LaunchAgents oder Hintergrundprozesse hinterlassen.

Die Prüfung sollte deshalb auf dem macOS-Host stattfinden, nicht nur in der Workflow-Ausgabe. Suchen Sie nach:

• Arbeitskopien und versteckten Dateien außerhalb des erwarteten Pfads
• DerivedData, Archiven und Testlogs
• Prozessen, die nach Jobende weiterlaufen
• Änderungen an Shell-Profilen und Benutzerkonfigurationen
• neuen LaunchAgents oder LaunchDaemons
• Keychain-Einträgen und Exportdateien
• geänderten Firewall-, Proxy- oder Netzwerkprofilen
• Authentifizierungsdaten in Logs und Cache-Verzeichnissen

Führen Sie die Prüfung zuerst mit einem absichtlich markierten Testartefakt durch. Legen Sie eine harmlose Kennung in einer temporären Datei ab, starten Sie den Job, bereinigen Sie den Arbeitsbereich und suchen Sie anschließend nach dieser Kennung im Benutzerverzeichnis, in Logs und in Prozessen. Wiederholen Sie den Test nach einem Neustart. Ein positives Ergebnis zeigt eine Lücke; ein negatives Ergebnis beweist nur, dass der Testfall nicht gefunden wurde.

Die GitHub-Hinweise zu kompromittierten Runnern sind für diese Bewertung wichtig: Bei einem kompromittierten Host muss die Organisation davon ausgehen, dass dort erreichbare Daten und Geheimnisse betroffen sein können.

Für einen langfristig betriebenen Mac gilt daher:

1. Job beenden und Runner aus der Aufgabenverteilung nehmen.
2. Aktive Prozesse, Netzwerkverbindungen und Änderungen sichern.
3. Betroffene Tokens, Schlüssel und Zertifikate sperren oder ersetzen.
4. Runner-Registrierung und Repository-Zugriff prüfen.
5. Knoten neu aufbauen oder einer manuellen Sicherheitsprüfung zuführen.
6. Erst nach dokumentierter Freigabe wieder sensible Jobs zulassen.

Eine Checkliste für Mac-Runner-Arbeitsbereich und Knotenwiederherstellung kann dabei als interne Abnahmestruktur dienen. Verwenden Sie dort nur die Schritte, die zu Ihrem tatsächlichen Bereitstellungsmodell passen.

Ein Mac Runner ist nicht nur ein CI-Prozess. Er ist ein Host mit Netzwerkzugriff. Ermitteln Sie deshalb, welche internen Dienste, Paketquellen, Artefaktspeicher, Signaturdienste und Verwaltungsnetze erreichbar sind. Fragen Sie für jeden Zugriff: Wird er für diesen Job wirklich benötigt?

Erstellen Sie anschließend eine Positiv- und Negativliste. Die Positivliste enthält etwa den Quellcode-Server, den vorgesehenen Paketspiegel und den Artefaktspeicher. Die Negativliste enthält Verwaltungsoberflächen, Datenbanken, Produktionsschnittstellen und andere Runner, die der Job nicht erreichen darf.

Vermeiden Sie Root-Rechte im normalen Build. Wenn ein Schritt sie technisch benötigt, isolieren Sie ihn als eigenen Job mit eigener Freigabe. Ein vollständiger Festplattenzugriff oder ein uneingeschränkter Internetzugang darf keine stillschweigende Standardeinstellung sein.

Auch die Kommunikation des Runners muss zur Architektur passen. Die offizielle Dokumentation zu selbst gehosteten Runnern beschreibt die technische Grundlage der Runner-Kommunikation. Daraus folgt aber keine Zusicherung, dass Ihr lokales Netzwerk oder Ihr Host nach einem kompromittierten Job sicher bleibt.

Eine produktionsfähige Abnahme besteht aus Tests. Prüfen Sie mindestens diese vier Pfade:

1. Ein niedrig privilegierter Build wird ausgeführt und beendet.
2. Ein kontrollierter Signaturjob wird nur nach der vorgesehenen Freigabe gestartet.
3. Ein Test hinterlässt absichtlich harmlose Rückstände, die erkannt und entfernt werden müssen.
4. Der Mac wird neu gestartet, danach werden Runner-Dienst, Benutzerkonto, Routing und Arbeitsfähigkeit geprüft.

Dokumentieren Sie für jeden Test den erwarteten Zustand, das beobachtete Ergebnis und die verantwortliche Freigabe. Prüfen Sie außerdem, wie Tokens und Zertifikate gewechselt werden, wie ein Runner aus einer Gruppe entfernt wird und wie ein Ersatzknoten in den Betrieb kommt.

Wählen Sie nicht nach Bequemlichkeit, sondern nach der schlimmsten Aufgabe, die der Knoten ausführen darf.

• Niedrig privilegierter gemeinsamer Build-Runner: geeignet, wenn keine produktiven Schlüssel erreichbar sind, Repositorys kontrolliert werden und Rückstände zuverlässig erkannt werden.
• Separater Veröffentlichungs-Runner: geeignet für Signatur, Notarisierung und Produktion, wenn Runner Group, Konto, Keychain, Netzwerk und Freigabe getrennt sind.
• Einmalig aufgebauter Runner: geeignet, wenn Jobs aus wechselnden oder nur teilweise vertrauenswürdigen Quellen geprüft werden müssen. Der Host muss nach dem Lauf ersetzt oder sicher zurückgesetzt werden.

Wenn ein gemeinsam genutzter Mac weder automatisch neu aufgebaut noch zuverlässig bereinigt werden kann, dürfen dort keine sensiblen Signatur- oder Veröffentlichungsaufgaben laufen. Bei häufigen Kontaminationsbefunden ist eine betreute oder vollständig ersetzbare Ausführungsumgebung die bessere Entscheidung als weitere Regeln auf demselben Host.

Darf ein selbst gehosteter Runner in einem öffentlichen Repository laufen?

Für öffentlichen Code und nicht vertrauenswürdige Pull Requests sollte kein dauerhaft betriebener Mac Runner verwendet werden. Ein Workflow kann den Host verändern und Spuren hinterlassen. Wenn eine Prüfung unvermeidbar ist, verwenden Sie einen isolierten, niedrig privilegierten und nach dem Lauf ersetzbaren Knoten. Signaturmaterial, interne Netzwerke und Produktionszugänge müssen vollständig außerhalb dieses Pfads bleiben.

Wie verhindern wir, dass mehrere Projekte denselben Mac Runner auslesen?

Eine gemeinsame Maschine ist nur vertretbar, wenn Repository-Zugriff, Runner Group, Workflow-Bedingungen, Benutzerkonto und Arbeitsbereich gemeinsam begrenzt sind. Tags allein reichen nicht. Für sensible Projekte sind getrennte Runner Groups und getrennte Konten besser. Wenn der Host nicht zuverlässig bereinigt oder neu aufgebaut werden kann, sollten Projekte keinen gemeinsamen Produktionsknoten verwenden.

Auf welchen Runner gehören Zertifikate für Xcode CI?

Apple-Signaturidentitäten und produktive Berechtigungen gehören auf einen gesonderten Veröffentlichungs-Runner. Der normale Build-Runner sollte nur bauen und testen. Der Signaturjob muss durch eine eigene Umgebung, eine manuelle Freigabe und ein enges Repository- sowie Netzwerkprofil geschützt werden. Eine Umgebungsfreigabe macht einen bereits kompromittierten Host jedoch nicht wieder vertrauenswürdig.

Was muss nach einem Mac-Runner-Job gelöscht oder geprüft werden?

Prüfen Sie nicht nur den Checkout-Ordner. Entfernt oder kontrolliert werden müssen auch temporäre Dateien, DerivedData, Logs, Benutzerkonfigurationen, Keychain-Spuren, Prozesse, LaunchAgents und Änderungen an System- oder Netzwerkprofilen. Ein Neustart ist ein Test, aber kein Beweis für Sauberkeit. Bei ungeklärten Resten muss die Aufgabenverteilung sofort gestoppt werden.

Woran erkennen wir, dass ein langfristig laufender self-hosted runner kontaminiert ist?

Warnzeichen sind unbekannte Prozesse, veränderte Shell-Profile, neue LaunchAgents, unerwartete Netzwerkverbindungen, veränderte Arbeitsbereiche, unbekannte Zertifikate oder Logs mit Geheimnissen. Der Status „Online“ sagt nur etwas über die Verbindung zum Dienst aus. Bei einem solchen Befund sichern Sie die Belege, sperren Token und Signaturzugänge, stoppen den Runner und bauen den Knoten neu auf oder prüfen ihn manuell.

Ein dauerhaft geteilter Mac ist gegenüber einer strikt getrennten Ausführung oft günstiger im Betrieb, bringt aber drei reale Nachteile mit: Rückstände können über Jobs hinweg bestehen bleiben, ein kompromittierter Prozess kann erreichbare Netzwerkziele untersuchen, und die Wiederherstellung ist bei nicht ersetzbaren Hosts langsam sowie schwer beweisbar. Das gilt besonders, wenn gleichzeitig Quellcode, macOS Keychain und Produktionszugänge auf demselben Benutzerkonto liegen.

Wenn Sie zunächst eine isolierte Testumgebung für nicht produktive Xcode-Builds benötigen, kann MESHLAUNCH einen gemieteten Remote-Mac als kontrollierten Prüfpunkt ergänzen. Entscheidend ist nicht die bloße Erreichbarkeit, sondern ob Sie separates Konto, Neustart, Runner-Routing und den tatsächlichen Rücksetzprozess vor der Übernahme von Signatur- oder Veröffentlichungsaufgaben nachweisen können. Beginnen Sie mit einem ungefährlichen Repository und übertragen Sie sensible Jobs erst nach bestandener Abnahme.