Der Build scheitert beim Zugriff auf ein privates Paketregister oder eine interne API?
Wenn GitHub Actions macOS larger runners direkten Intranet-Zugriff oder eine statische IP für Firewall-Regeln benötigen, wählen Sie sie nicht ungeprüft: Prüfen Sie zuerst die dokumentierten Grenzen und bewerten Sie danach einen selbst verwalteten Mac mit nachgewiesenem Netzwerkpfad.

Dieser Leitfaden ist für IT-Verantwortliche, die den Zugriff auf private Repositories, Paketregister und interne Dienste absichern müssen.
Plattformteams erhalten Kriterien, um Aufgaben zwischen gehosteten und selbst verwalteten Macs aufzuteilen.
Verantwortliche für CI-Sicherheit und Beschaffung können Netzwerksteuerung, Betriebsaufwand und Kapazitätsmodell gegeneinander abwägen.

GitHub Actions macOS larger runners im Unternehmensnetz einordnen

Behandeln Sie „Runner ist erreichbar“ und „Runner darf auf den benötigten Dienst zugreifen“ als getrennte Fragen. Nach der GitHub-Dokumentation zu gehosteten Runnern bieten macOS larger runners derzeit weder statische IP-Adressen noch Azure private networking. Leiten Sie deshalb keine Netzwerkfähigkeit von einem anderen Betriebssystem oder Runner-Typ ab.

Für die Entscheidung brauchen Sie keine allgemeine Runner-Bewertung, sondern einen Beleg pro Build-Abhängigkeit:

  • Prüfen Sie Workflow-Dateien, Skripte und Abhängigkeitsdefinitionen. Erfassen Sie, welche Hostnamen und Dienste der Build tatsächlich kontaktiert.
  • Trennen Sie öffentlich erreichbare Ressourcen von Diensten, die zusätzlich Organisationsanmeldung, eine private Route oder eine Firewall-Ausnahme benötigen.
  • Vergleichen Sie die erwarteten Verbindungen mit Build-Protokollen und Netzwerk- beziehungsweise Zugriffsprotokollen. Ein erfolgreicher Build allein belegt nicht, dass die vorgesehenen Kontrollen greifen.

Können macOS larger runners ein privates Paketregister erreichen? Nur wenn der konkrete Netzwerkpfad und die erforderliche Authentifizierung für diesen Runner verfügbar sind. Prüfen Sie beides mit einem echten Workflow. Ein gespeichertes Zugangstoken ersetzt keine fehlende Route zum privaten Host.

Die Dokumentation zur Verwaltung größerer Runner hilft bei der Verwaltung dieser Runner. Sie ist jedoch kein Nachweis, dass eine bestimmte private Abhängigkeit aus Ihrer Build-Umgebung erreichbar ist. Für die Abnahme zählen der tatsächlich verwendete Runner, die Zieladresse, die Authentifizierung und ein nachvollziehbarer Zugriffsnachweis.

Bei ausschließlich öffentlichen Build-Abhängigkeiten gehostet starten

Wenn Quellcode, Pakete und Build-Dienste ohne direkte Verbindung zum Unternehmensnetz erreichbar sind, können Sie einen gehosteten macOS Runner als Kandidaten prüfen. „Öffentlich erreichbar“ bedeutet dabei nicht automatisch „ohne Berechtigung“: Ein Dienst kann über das öffentliche Internet erreichbar sein und trotzdem eine Anmeldung oder eng begrenzte Workflow-Identität verlangen.

Gehen Sie zunächst die Build-Kette durch:

  • Erfassen Sie Quellcode- und Untermodulzugriffe, Paketquellen, Artefakt-Downloads, Lizenzprüfungen und Veröffentlichungsziele.
  • Ordnen Sie jedem Zugriff einen Zweck und eine Authentifizierung zu. Halten Sie fest, welche Berechtigung ein Workflow tatsächlich braucht.
  • Führen Sie den Workflow mit dem vorgesehenen macOS larger runner aus. Sichern Sie die verwendete Workflow-Konfiguration, relevante Build-Ausgaben und die Dienstprotokolle.

Wann ist ein gehosteter Runner für iOS-Builds vertretbar? Wenn alle benötigten Ziele erreichbar sind und Ihre Sicherheitsrichtlinien den Zugriffsweg erlauben. Das muss sich am tatsächlichen Release-Ablauf zeigen, einschließlich Signierung oder Veröffentlichung, falls diese Schritte dazugehören. Ein erfolgreicher Kompilierungslauf reicht nicht, wenn ein späterer Schritt auf ein internes Geheimnis oder einen privaten Dienst angewiesen ist.

Vorteile dieses Wegs sind der geringere Aufwand für den Betrieb eigener Build-Hosts und ein klar abgegrenzter Test der gehosteten Umgebung. Der Nachteil: Sie dürfen nicht voraussetzen, dass die Umgebung eine feste ausgehende Adresse oder eine direkte Verbindung in Ihr internes Netz bereitstellt. Prüfen Sie diese Eigenschaften gegen die Sicherheitsanforderungen, nicht gegen eine Annahme aus der Konfiguration eines anderen Runner-Typs.

Private Abhängigkeiten mit einer konkreten Zugriffskette prüfen

Bei privaten Paketregistern, Artefaktspeichern, internen APIs oder Geheimnisdiensten müssen Sie die Verbindung vom Workflow bis zum Ziel modellieren. Notieren Sie für jeden Dienst, ob der Zugriff eingehend oder ausgehend initiiert wird, welche Identität verwendet wird und wo Verbindungen gefiltert oder protokolliert werden.

Das verhindert typische Fehlschlüsse:

  • Ein gültiges Token kann einen fehlenden Netzwerkpfad nicht reparieren.
  • Eine erfolgreiche Verbindung zu einem API-Gateway beweist nicht, dass andere interne Ziele erreichbar sind.
  • Eine in allgemeinen GitHub-Anleitungen beschriebene Methode ist nicht automatisch für macOS larger runners freigegeben.

Lässt sich die interne API über ein Gateway oder eine Netzwerküberlagerung anbinden? Möglich ist das nur, wenn der konkrete Ansatz zum Zielsystem, zur Runner-Umgebung und zu Ihren Sicherheitsvorgaben passt. Die GitHub-Anleitung für OIDC-Authentifizierung an einem API-Gateway beschreibt einen Identitätsweg. Die Anleitung für WireGuard als Netzwerküberlagerung beschreibt einen anderen Ansatz. Behandeln Sie beide zunächst als zu prüfende Architektur, nicht als zugesicherte Funktion für Ihren konkreten macOS Runner.

Legen Sie vor einem Pilot fest, was als Nachweis gilt: Der Workflow muss den benötigten Dienst unter der vorgesehenen Identität erreichen; der Dienst muss den Zugriff in seinen Protokollen erkennen; und ein nicht erlaubter Zugriff muss erwartungsgemäß scheitern. Verifizieren Sie außerdem, welche Secrets verfügbar sind und ob sie auf den notwendigen Job begrenzt werden können. Falls die offizielle Dokumentation den Ziel-Runner nicht eindeutig einschließt oder der Test nicht unter realen Workflow-Bedingungen möglich ist, kennzeichnen Sie den Ansatz als offen.

Die Dokumentation zu Azure private networking für gehostete Runner ist für den Geltungsbereich besonders wichtig: Sie dürfen diese Option nicht mit direktem Intranet-Zugriff auf macOS larger runners gleichsetzen. Die offizielle Dokumentation zu macOS nennt Azure private networking als nicht verfügbar. Eine für andere Runner beschriebene Funktion darf diese Grenze nicht stillschweigend ersetzen.

Bei einer statischen IP die Firewall-Anforderung zuerst klären

Eine IP-Allowlist ist nur dann eine brauchbare Kontrolle, wenn sie die vorgesehene Verbindung tatsächlich identifiziert und die Adresseigenschaft des Clients dazu passt. Ermitteln Sie daher, was Ihre Firewall verlangt: eine feste ausgehende Quelladresse, eine eingehende Freigabe, eine bestimmte Dienstidentität oder eine Kombination davon.

Unterstützen GitHub Actions macOS larger runners statische IP-Allowlists? Nach der offiziellen Runner-Referenz stellen macOS larger runners derzeit keine statischen IP-Adressen bereit. Wenn eine feste Quelladresse eine harte Voraussetzung ist, planen Sie den Build nicht auf Basis einer solchen Adresse. Prüfen Sie stattdessen einen selbst verwalteten Mac im vorgesehenen Unternehmensnetz oder eine Alternative, die Ihr Sicherheitsteam ausdrücklich genehmigt und praktisch getestet hat.

Unterscheiden Sie dabei drei Dinge:

  • Eine statische Quelladresse ist eine Netzwerkeigenschaft. Sie beantwortet nicht, welcher Workflow oder welche Person auf den Dienst zugreift.
  • Eine erlaubte IP kann Verbindungen begrenzen, beweist aber nicht, dass auf dem zugelassenen Host keine fremden oder unerwarteten Workloads laufen.
  • Eine Netzwerkverbindung ist keine Host-Isolation. Sie ersetzt weder Rechtebegrenzung noch Schutz von Signaturmaterial oder die Kontrolle nicht vertrauenswürdiger Pull Requests.

Prüfen Sie mit dem Firewall-Team, ob eine andere, bereits freigegebene Identitäts- oder Vermittlungslösung die Richtlinie erfüllt. Halten Sie fest, welche Zielsysteme sie abdeckt und welche Protokolle zur Prüfung verfügbar sind. Wenn die Richtlinie zwingend eine feste Quelladresse verlangt und keine bestätigte Alternative vorliegt, ist der gehostete macOS Runner für diesen Zugriff zunächst kein freigegebener Pfad.

Selbst verwaltete Macs nach dem tatsächlichen Netzwerkpfad auswählen

Ein selbst verwalteter Mac kann für private Abhängigkeiten passen, wenn seine Platzierung und Netzwerkkonfiguration den erforderlichen Zugriff ermöglichen. Die Registrierung als Runner stellt diesen Zugriff nicht automatisch her. Entscheidend sind Host-Standort, Routing, Namensauflösung, Firewall-Regeln und die Identität, die der Build beim Zieldienst verwendet.

Prüfen Sie den Runner deshalb in der Umgebung, in der er später tatsächlich arbeiten soll:

  • Testen Sie jeden erforderlichen Hostnamen und Dienstport aus einem Workflow, nicht nur aus einer interaktiven Administrationssitzung.
  • Verifizieren Sie Anmeldung und Berechtigungen für private Repositories, Paketregister, interne APIs und Geheimnisdienste.
  • Sorgen Sie dafür, dass fehlgeschlagene Verbindungen in Job-Ausgaben oder Dienstprotokollen erkennbar sind. Ein stiller Timeout erschwert sowohl den Betrieb als auch die Sicherheitsprüfung.

Die Dokumentation zu selbst verwalteten Runnern beschreibt die erforderlichen Kommunikationsbeziehungen zwischen Runner und GitHub. Diese ausgehende Kommunikation ist von der Verbindung in Ihr internes Netz zu unterscheiden. Ihr eigenes Netzteam muss beide Richtungen und die jeweiligen Regeln bewerten.

Der Vorteil liegt in der Möglichkeit, den Host in eine passend geplante Netzwerkzone zu setzen und seine Betriebskontrollen an die Unternehmensrichtlinien anzupassen. Dem stehen laufende Aufgaben gegenüber: macOS- und Xcode-Pflege, Verfügbarkeit, Berechtigungsverwaltung, Überwachung sowie Schutz gespeicherter Zugangsdaten. Ein selbst verwalteter Runner ist nicht automatisch isoliert. Besonders bei nicht vertrauenswürdigen Workflows müssen Sie prüfen, ob Jobs auf einen Host gelangen könnten, der Zugang zu internen Diensten oder Signaturmaterial hat.

Wenn Sie Hardware beschaffen, klären Sie außerdem vorab, wer Standort, Netzwerk, Wartung und Wiederherstellung verantwortet. Die Bestelloptionen für Mac mini können Sie in die Beschaffungsprüfung einbeziehen; sie belegen für sich genommen weder eine bestimmte Netzwerkanbindung noch eine bestimmte Runner-Konfiguration.

Hybride Pipelines nach Netz- und Berechtigungsgrenzen aufteilen

Nicht jeder Schritt eines iOS- oder macOS-Builds muss denselben Netzwerkzugriff haben. Sie können öffentlich ausführbare Build- und Testaufgaben getrennt von Schritten bewerten, die auf private Dienste oder besonders geschützte Ressourcen zugreifen. Eine solche Aufteilung ist aber nur tragfähig, wenn Übergaben und Berechtigungen sauber definiert sind.

Legen Sie vor der Umsetzung fest:

  • Welche Aufgabe läuft auf welchem Runner und warum?
  • Welche Artefakte werden zwischen Aufgaben übergeben, und wie wird ihre Herkunft geprüft?
  • Welche Identität darf auf private Abhängigkeiten, Signaturmaterial und Veröffentlichungsziele zugreifen?
  • Welche Protokolle belegen, dass ein Job nur auf die freigegebenen Dienste zugegriffen hat?

Testen Sie den vollständigen Weg mit einer realen Workflow-Konfiguration. Ein isolierter Verbindungstest beweist nicht, dass Aufgabenrouting, Artefaktübergabe und Signierung zusammen funktionieren. Auch ein gebautes Artefakt ist kein ausreichender Abnahmenachweis, wenn Sie nicht prüfen können, welcher Job es erstellt hat und welche Berechtigungen dieser Job besaß.

Die Vorteile einer Aufteilung sind eine präzisere Zuordnung von Netzwerkzugriffen und die Möglichkeit, unterschiedliche Aufgaben passend zu ihren Abhängigkeiten zu betreiben. Nachteile entstehen durch zusätzliche Übergaben, mehr Konfigurationsstellen und die Pflicht, Berechtigungsgrenzen über den gesamten Ablauf hinweg zu erhalten. Wenn Sie diese Übergänge nicht zuverlässig prüfen und protokollieren können, halten Sie die Pipeline zunächst auf einem kontrollierbaren Pfad, statt eine nur theoretisch getrennte Architektur freizugeben.

Die Abnahme als ausführbare Prüfliste durchführen

Verwenden Sie die folgende Liste für einen Pilot und für die anschließende Freigabe. Markieren Sie Punkte erst dann als erledigt, wenn Sie den Nachweis im tatsächlichen Workflow oder in den zugehörigen Zugriffsprotokollen abgelegt haben.

  • [ ] Erfassen Sie alle Build-Abhängigkeiten aus Workflow-Dateien, Skripten und Paketdefinitionen.
  • [ ] Kennzeichnen Sie für jedes Ziel, ob es öffentlich erreichbar, organisationsautorisiert oder nur über das Unternehmensnetz erreichbar ist.
  • [ ] Notieren Sie für jeden Zugriff Initiator, Ziel, Authentifizierung, Firewall-Bedingung und erwartetes Protokoll.
  • [ ] Prüfen Sie die offizielle Runner-Dokumentation auf genau den verwendeten Runner-Typ. Übertragen Sie keine Netzwerkfunktion von Linux- oder Windows-Runnern auf macOS.
  • [ ] Führen Sie den realen Build auf dem vorgesehenen Runner aus und sichern Sie Workflow-Konfiguration, relevante Ausgaben und Dienstprotokolle.
  • [ ] Testen Sie erlaubte und nicht erlaubte Zugriffe. Stellen Sie sicher, dass ein Fehlschlag sichtbar ist und nicht durch einen alternativen, ungeprüften Pfad verdeckt wird.
  • [ ] Prüfen Sie bei selbst verwalteten Macs Wartung, Zugangsdaten, Host-Rechte und die Behandlung nicht vertrauenswürdiger Workflows.
  • [ ] Dokumentieren Sie offene Punkte ausdrücklich. Geben Sie keinen Netzwerkpfad frei, solange die notwendige Route oder der Nachweis der Zugriffskontrolle nicht bestätigt ist.

Ihre Entscheidung lässt sich danach auf die tatsächliche Abhängigkeit zurückführen:

  • Sind alle benötigten Ressourcen öffentlich erreichbar und stimmen die Zugriffsrechte, kann ein gehosteter macOS Runner im Pilot geprüft werden.
  • Muss ein Build direkt auf private Dienste zugreifen, wählen Sie einen Runner nur dann, wenn die Route und die Zugriffssteuerung für genau diesen Runner nachgewiesen sind.
  • Ist eine statische IP eine zwingende Firewall-Voraussetzung, planen Sie bei macOS larger runners nicht mit einer verfügbaren festen Adresse.
  • Funktioniert ein Gateway oder eine Netzwerküberlagerung nur unter noch ungeprüften Annahmen, bleibt es ein offener Prüfpunkt und keine freigegebene Architektur.
  • Lassen sich öffentliche und private Aufgaben trennen, geben Sie die Aufteilung erst frei, wenn Artefaktübergabe, Identität und Veröffentlichungsrechte getestet sind.

GitHub Actions macOS larger runners können für Builds mit passenden, erreichbaren Abhängigkeiten in Frage kommen. Sie sind jedoch keine Standardantwort auf private Netzwerkpfade oder feste IP-Allowlists. Selbst verwaltete Macs bieten ebenfalls keine automatische Sicherheit: Sie bringen eigene Betriebs-, Wartungs- und Berechtigungsrisiken mit.

Wenn Ihr aktueller Weg an einer festen IP, manueller Hostpflege oder einer unklaren Aufgabenverteilung scheitert, ist ein Mac-Mietmodell eine weitere Ressourcenkategorie, aber kein Ersatz für die Netzwerkabnahme. Für einen zeitlich begrenzten Test können Sie MACCOME als mögliche Mac-Ressource prüfen und vorab schriftlich klären, welche Zugangswege, Bereitstellung und Einschränkungen für Ihren konkreten Workflow gelten. Beginnen Sie mit der MACCOME-Übersicht und geben Sie die Umgebung erst frei, wenn Ihre Tests den erforderlichen Pfad bestätigt haben.