Ein GitHub-Actions-Secret ist nicht automatisch überall sichtbar, wo ein Workflow läuft. Die Sichtbarkeit hängt davon ab, auf welcher Ebene du es anlegst und über welchen Trigger der Workflow gestartet wird. Das hier ist der Blick auf diese Zugriffsebenen, nicht auf die Frage, wie lange ein Secret gültig bleiben sollte oder wie es überhaupt in ein Repository gerät. Die Rotation von Pipeline-Secrets behandelt der Artikel vom 14.07., wie du Secrets findest, die versehentlich im Code gelandet sind, der vom 09.06.
Repository-Secrets: die breiteste Stufe
Ein Repository-Secret legst du unter Settings, Security, Secrets and variables, Actions an. Um eines zu erstellen, brauchst du in einem Organisations-Repository Schreibzugriff, in einem persönlichen Repository musst du Collaborator sein. Jeder Workflow-Job in diesem Repository kann per secrets.SecretName darauf zugreifen, unabhängig davon, welcher Branch oder welche Umgebung gerade läuft. Das ist die Stufe mit dem größten Radius. Ein Secret hier ist für alles im Repository erreichbar, was Workflows ausführen darf.
Environment-Secrets: Zugriff erst nach Freigabe
Ein Environment-Secret bindest du an eine konkrete Umgebung, zum Beispiel eine Produktionsumgebung. Laut GitHub-Dokumentation sind diese Secrets nur für Workflow-Jobs verfügbar, die diese Umgebung referenzieren. Anlegen darfst du sie als Repository-Owner in einem persönlichen Repository beziehungsweise mit Admin-Zugriff in einem Organisations-Repository.
Der eigentliche Unterschied zu Repository-Secrets sind die Protection Rules, die du der Umgebung zuweisen kannst. Required Reviewers erlaubt bis zu sechs Personen oder Teams als Genehmiger, es reicht laut Dokumentation die Zustimmung von einem einzigen der hinterlegten Reviewer, damit der Job weiterläuft, optional lässt sich verhindern, dass jemand den eigenen Lauf freigibt. Wait Timer setzt eine Wartezeit in Minuten, bevor der Job überhaupt starten darf. Deployment Branches and Tags legt fest, welche Branches oder Tags in diese Umgebung deployen dürfen, über Namensmuster konfigurierbar.
Administratoren können diese Regeln standardmäßig umgehen, das lässt sich aber abschalten. Der Job bekommt das Secret erst ausgeliefert, wenn diese Regeln durchlaufen sind, nicht schon beim Start des Workflows.
Organization-Secrets: eine Repository-Liste als Filter
Ein Organization-Secret legt ausschließlich ein Owner der Organisation an, unter Organization, Settings, Security, Secrets and variables, Actions. Beim Anlegen wählst du eine Zugriffspolitik: „all repositories“, „only private repositories“ oder „a specified list of repositories“. Diese Liste ist der eigentliche Scoping-Mechanismus auf Organisationsebene. Ein Secret hier ist nicht automatisch für jedes Repository der Organisation sichtbar, sondern nur für die, die in der Liste stehen. Für private Repositories auf einem GitHub-Free-Plan gilt laut Dokumentation eine zusätzliche Einschränkung, sie haben keinen Zugriff auf Organization-Secrets.
Fork-PRs: pull_request bringt keine Secrets mit
Hier wird die Scoping-Logik praktisch relevant, sobald ein Pull Request aus einem Fork kommt. Ein Workflow, der über den Standard-Trigger pull_request läuft, bekommt bei einer Fork-PR keinen Zugriff auf die konfigurierten Secrets des Ziel-Repositories. Das ist kein Sonderfall, sondern das dokumentierte Standardverhalten von GitHub Actions. Zusätzlich erhält der automatisch bereitgestellte GITHUB_TOKEN in diesem Fall von Haus aus nur minimale Berechtigungen. GitHub empfiehlt in der eigenen Dokumentation, die Standardberechtigung für den GITHUB_TOKEN auf Lesezugriff zu begrenzen. Das betrifft ausschließlich den automatisch bereitgestellten GITHUB_TOKEN innerhalb eines Workflow-Laufs. Die Scopes und Berechtigungsmodelle für Personal Access Tokens behandelt der Artikel vom 21.09. gesondert.
Das ist ausdrücklich ein anderer Mechanismus als der, den der Artikel zur Runner-Sicherheit vom 09.07. behandelt. Dort ging es um den Runner selbst als privilegierten Host und darum, was ein Fork-PR-Workflow auf dieser Maschine anrichten kann. Hier geht es um etwas, das davorliegt. GitHub liefert den Secrets-Kontext für einen Fork-PR-Workflow schlicht gar nicht erst aus. Fehlender Maschinenzugriff und fehlender Secrets-Zugriff sind zwei getrennte Schutzebenen, keine wechselseitig austauschbaren.
pull_request_target: die Ausnahme mit eigenem Risiko
Es gibt einen Trigger, der diese Schutzebene bewusst aufhebt: pull_request_target. Ein Workflow, der darüber läuft, bekommt laut GitHub-Dokumentation vollen Zugriff auf Secrets und potenziell Schreibrechte auf das Repository, weil er im Kontext des Ziel-Repositories ausgeführt wird, nicht im Kontext des Forks. GitHub warnt in der eigenen Dokumentation ausdrücklich, dass Workflows mit diesem Trigger keinen nicht vertrauenswürdigen Code auschecken dürfen, weder aus Fork-Pull-Requests noch aus Repositories außerhalb der eigenen Kontrolle. Diese Workflows teilen sich laut Dokumentation denselben Cache wie andere privilegierte Trigger. Wo es nicht zwingend nötig ist, empfiehlt GitHub, pull_request_target zu vermeiden und stattdessen workflow_run für die Trennung von Rechten zwischen Workflows zu verwenden.
Wenn du also in einem Fork-PR-Workflow Secrets erwartest und keine bekommst, ist das erst einmal kein Fehler in deiner Pipeline-Konfiguration. Es ist die Grenze, die GitHub an dieser Stelle bewusst zieht. Die Frage ist eher, ob ein Prozess, der auf Fork-PRs mit Secrets reagieren soll, wirklich über pull_request_target laufen muss, oder ob eine zweistufige Konstruktion mit workflow_run genügt.
Diese Trennung zwischen Repository-, Environment- und Organization-Ebene, kombiniert mit dem Verhalten bei Fork-PRs, ist aus der Arbeit an auditierbaren Lieferketten eine der Stellen, an denen sich am schnellsten zeigt, ob eine Pipeline-Konfiguration tatsächlich durchdacht ist oder nur so lange funktioniert, wie niemand von außen einen Pull Request schickt.
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es richtet sich nach der Lage und läuft über drei Felder: Implementation (Delivery/Nachweis modulweise in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit bei KI-gestützten Build- und Deployment-Schritten), Maintenance (laufender Betrieb der Nachweise). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst.
Kontakt: mm@mhm-dl.de
Hinterlasse einen Kommentar