Zusammenfassung

  • GitHub Actions kann einen workflow_run starten, wenn ein anderer Workflow angefordert oder abgeschlossen wird; GitHub dokumentiert, dass der nachgelagerte Workflow Geheimnisse und Schreib-Tokens haben kann, die dem vorgelagerten fehlten.
  • Diese Verknüpfung ist kein Vertrauensurteil über ein Artefakt: Schlussbedingung, Branch-Filter, Checkout, Auswahl und Behandlung des Artefakts sowie effektive Privilegien bleiben getrennte Entscheidungen.
  • Eine belastbare Aussage verbindet den vorgelagerten Run und seine Revision, Trigger-Konfiguration und ausgewertete Bedingungen des nachgelagerten Workflows, genaues Artefakt und Checkout, Privilegkontext, nachgelagerte Entscheidung und eine zeitlich begrenzte Zielbeobachtung.

Die Aussage, ein Veröffentlichungsworkflow sei « nach der Validierung gelaufen », kann eine Architektur beschreiben, aber keine vollständige Beweiskette. GitHub Actions erlaubt einem Workflow, auf das Ereignis workflow_run eines anderen Workflows zu hören, wenn dieser angefordert wird oder endet. GitHub weist zudem darauf hin, dass der ausgelöste Workflow auf Geheimnisse und Schreib-Tokens zugreifen kann, obwohl der vorherige Workflow dies nicht konnte. Die Trennung kann sinnvoll sein: ein weniger privilegierter Eingangsschritt erzeugt einen Kandidaten, ein stärker kontrollierter Folgeschritt entscheidet über dessen Umgang. Sie schafft aber zugleich eine Privileggrenze. Der Name des vorgelagerten Runs sagt nicht, was diese Grenze überschritten hat.

Zuerst sind Abschluss und Annahme auseinanderzuhalten. GitHub dokumentiert, dass ein workflow_run unabhängig vom Ergebnis des vorherigen Workflows ausgeführt wird, sofern der nachgelagerte Workflow nicht eine ausdrückliche Bedingung wie github.event.workflow_run.conclusion == 'success' enthält. Ein abgeschlossener vorgelagerter Run beweist also weder erfolgreiche Prüfungen noch, dass ein nachgelagerter Job die erwartete Schlussbedingung auswertete. Ein Workflow-Name in einem Ereignis ist weder die Revision der zuhörenden Workflow-Datei noch der Inhalt des empfangenen Ereignisses noch der Ausdruck, der den privilegierten Schritt freigab.

Auch Branch-Filter sind begrenzt. GitHub beschreibt, dass sich workflow_run-Branch-Filter auf den Branch des auslösenden Workflows beziehen und dass Ein- und Ausschlussmuster einer Reihenfolge folgen. Ein deklarierter Wert in branches kann eine Richtlinienabsicht zeigen. Er belegt nicht, dass ein Artefakt vom erwarteten Commit stammt, dass der nachgelagerte Checkout dieselbe Revision auflöste oder dass die Formel « der Release-Branch hat bestanden » tatsächlich den geprüften Ref bezeichnet. Soll diese Aussage später überprüfbar sein, müssen Kennung des vorgelagerten Runs, Ereignisaktion, Head-Branch und SHA, Workflow-Identität und Wiederholungskontext zusammen erhalten bleiben.

Danach kommt das Artefakt. GitHubs Ereignisdokumentation zeigt, dass ein nachgelagerter Workflow Artefakte abrufen kann, die dem auslösenden Run zugeordnet sind. Das ist ein Zugriffsweg, kein Qualitätszertifikat. Ein Artefakt kann korrekt einem Run zugeordnet sein und dennoch der falsche logische Eingang für eine spätere Aktion sein. Der Workflow kann einen anderen Namen wählen, eine Menge statt eines Objekts laden, in einer anderen Umgebung entpacken, einen anderen Checkout verwenden oder das Artefakt einem Befehl übergeben, den die vorgelagerte Validierung nie bewertet hat. Der relevante Nachweis lautet nicht nur « Artefakt verfügbar ».

Er verbindet vorgelagerten Run, Namen oder Kennung, Größe und Digest soweit vorhanden, Abrufzeit, Ref und aufgelöstes SHA des nachgelagerten Checkouts, das konsumierende Programm und die Isolations- oder Nichtausführungsbedingungen der Behandlung.

Die GitHub-Referenz zur sicheren Nutzung erklärt, warum diese Präzision nötig ist. Sie warnt, dass workflow_run gefährlich werden kann, wenn ein privilegierter Workflow nicht vertrauenswürdigen Pull-Request-Inhalt auscheckt; Geheimnisse, Schreibrechte und gemeinsam genutzte Caches können dann verstärken, was der nachgelagerte Workflow akzeptiert. Die Warnung benennt kein bestimmtes Repository und kein bestimmtes Artefakt. Sie beschreibt eine Struktur: « Der vorgelagerte Workflow war erfolgreich » zeigt weder, was der privilegierte Folgeschritt akzeptierte, noch was er damit tun durfte.

Der Trigger ist auch kein Beleg für eine Wirkung am Ziel. Selbst ein richtig ausgewähltes Artefakt kann nur zur Inspektion dienen. Ein nachgelagerter Befehl kann an einer weiteren Berechtigungsgrenze scheitern, vor einem Zielaufruf enden, auf eine andere Ressource wirken oder enden, obwohl eine spätere Zielbeobachtung einen anderen Betriebszustand zeigt. Umgekehrt kann ein negatives vorgelagertes Ergebnis im Ereignis stehen, während eine nachgelagerte Bedingung jede privilegierte Aktion verhindert. Ereignis, Bedingung, Artefaktbehandlung, Befehlsentscheidung und beobachteter Zustand sind verschiedene Punkte.

Die praktische Antwort ist ein begrenzter nachgelagerter Nachweis. Zu bewahren sind Name und Kennung des vorgelagerten Workflows, Ereignisaktion, Head-Branch und SHA, Schlussfolgerung, Versuch oder Wiederholung sowie ein stabiler Verweis auf seine Definition. Zu bewahren sind außerdem die Revision der nachgelagerten Definition, der workflow_run-Selektor, Branch-Filter und das Ergebnis der Bedingung, die den folgenreichen Job zuließ oder blockierte. Checkout-Spezifikationen und aufgelöste SHAs gehören dazu. Für jedes verwendete Artefakt sind vorgelagerte Zuordnung, Name oder Kennung, verfügbarer Digest, Abrufkontext und Behandlungspfad festzuhalten. Der effektive Kontext von GITHUB_TOKEN-Rechten, Geheimnisverfügbarkeit und einschlägigen Cache- oder Umgebungsgrenzen sollte ohne Preisgabe sensibler Werte erhalten bleiben. Schließlich ist das Ergebnis des Folgevorgangs mit einer separat zeitlich bestimmten Zielbeobachtung zu verbinden. Geheimnisse können geschützt werden; nie erfasste Verknüpfungen lassen sich später nicht herstellen.

Diese Disziplin behauptet nicht, die gesamte Pipeline sei « vertrauenswürdig ». Sie sagt, was das Ereignis verbunden hat, was der nachgelagerte Workflow entschied, was er konsumierte, welche Privilegien er hatte und was beobachtet wurde. Ein workflow_run kann eine nützliche Kontrollgrenze sein. Er darf nicht zu einem stillschweigenden Zertifikat für Artefakt, privilegierte Entscheidung und Wirkung werden, die er selbst nicht aufgezeichnet hat.

Quellen

  1. GitHub Docs — Events that trigger workflows
  2. GitHub Docs — Secure use reference
  3. GitHub Docs — Triggering a workflow