Mit Schutzmechanismen für die Workflowausführung können Sie eine Allowlist definieren, mit der Sie festlegen können, wer GitHub ActionsWorkflows auslösen kann und durch welche Ereignisse sie ausgeführt werden dürfen. Weitere Informationen finden Sie unter Informationen zu den Actions-Richtlinien.
Hinweis
GitHub hat eine Standardrichtlinie hinzugefügt, die das pull_request_target Ereignis in öffentlichen Repositorys blockiert. Diese Richtlinie tritt am 2. Dezember 2026 in Kraft. Siehe Sichere Verwendung von pull_request_target.
Vorbereiten des Hinzufügens von Schutzmaßnahmen
Ähnlich wie Regelsätze greifen Schutzmechanismen für Workflow-Ausführungen zusammen mit anderen Schutzmechanismen im selben Repository, in derselben Organisation oder im selben Unternehmen.
Anstatt eine große Richtlinie pro Konto zu erstellen, empfiehlt es sich, mehrere klar definierte Richtlinien und Layering-Schutzmaßnahmen auf Kontoebenen zu erstellen. Unternehmensbesitzer können Schutzmaßnahmen auf Unternehmensebene für umfassende, nicht verhandelbare Richtlinien erstellen. Organisationsbesitzer und Repositoryadministratoren können diese Einschränkungen dann hinzufügen.
Denken Sie bei jeder Richtlinie, die Sie definieren, an Folgendes:
-
Auf welche Organisationen oder Repositorys Ihr Schutz ausgerichtet ist. Beispielsweise benötigen Open Source Repositorys möglicherweise strengere Einschränkungen für die Auslösung von Workflows. Sie können Repositorys nach Faktoren wie Sichtbarkeit, Bereitstellungsstatus oder benutzerdefinierte Eigenschaft ausrichten.
- Der Bereitstellungsstatus linked artifacts pagestammt aus der Organisation. Wenn dies ein wichtiger Faktor ist, stellen Sie sicher, dass Sie Bereitstellungsdatensätze hochladen, wenn ein Artefakt bereitgestellt wird. Siehe Informationen zu verknüpften Artefakten.
- Informationen zum Erstellen und Zuweisen von benutzerdefinierten Eigenschaften finden Sie unter Verwalten von benutzerdefinierten Eigenschaften für Repositorys in Ihrer Organisation.
-
Welche Workflows geschützt werden. Beispielsweise benötigen Workflows, die Produktionscode bereitstellen, möglicherweise ein bestimmtes Schutzniveau, aber weniger sensible Automatisierungen benötigen möglicherweise nicht das gleiche Schutzniveau. Sie können Richtlinien auf bestimmte Workflowpfade oder erforderliche Workflows festlegen.
-
Wer sollte diese Workflows in den Repositorys ausführen können, auf die Sie abzielen. Dies kann Benutzer mit einer bestimmten Rolle, ausgewählten Bot-Konten oder einem bestimmten Team sein. Erwägen Sie, diese Benutzer in einer Organisation oder einem Unternehmensteam zu gruppieren, damit sie problemlos kontaktiert und über mehrere Regelgruppen verwiesen werden können. Weitere Informationen findest du unter Erstellen eines Organisationsteams oder Erstellen von Unternehmensteams.
Erstellen einer Workflowausführungsrichtlinie
Erstellen Sie zunächst eine neue Aktionsrichtlinie für die Kontoebene, an der Sie arbeiten.
In einem Repository oder einer Organisation:
- Klicken Sie auf die Registerkarte Einstellungen.
- Klicken Sie in der linken Randleiste unter "Aktionen" auf "Richtlinien".
In einem Unternehmen:
- Klicken Sie auf die Registerkarte "Richtlinien ".
- Klicken Sie in der linken Randleiste auf "Aktionen" und dann auf "Richtlinien".
Tipp
Informationen zum programmgesteuerten Verwalten von Richtlinien finden Sie unter REST-API-Endpunkte für GitHub Actions-Richtlinien.
Konfigurieren der Richtlinie
Erstellen Sie als Nächstes eine neue Richtlinie.
- Wählen Sie einen Namen für die Richtlinie aus.
- Wählen Sie einen Erzwingungsstatus aus. Wenn Sie Auswerten (nur GitHub Enterprise Cloud) auswählen, können Sie in den Richtlinieneinblicken nachverfolgen, wann Benutzer von der Einschränkung betroffen wären.
- Richten Sie Ihre gewünschten Workflows, Organisationen oder Repositorys an.
- Konfigurieren Sie die folgenden Workflowausführungsschutze.
Einschränken von Akteuren
Standardmäßig kann jeder Benutzer mit Schreibzugriff auf ein Repository Workflows auslösen. Mit Akteurregeln können Sie trennen, wer Code beiträgt und wer Ihre CI ausführt, sodass Sie einem Mitwirkenden Schreibzugriff gewähren können, ohne ihm die Berechtigung zu erteilen, Workflows auszuführen.
Nur die zulässigen Akteure können die angegebenen Workflows im zielbezogenen Repository ausführen. Wenn Sie Ereignisse auch einschränken, können diese Benutzer nur Workflows mit den zulässigen Ereignissen auslösen. Nicht zulässige Akteure können die angegebenen Workflows überhaupt nicht ausführen.
GitHub Features sind für die integrierten Prozesse, auf GitHub Actions denen sie ausgeführt werden, von diesen Einschränkungen ausgenommen. Wenn Sie jedoch Workflows erstellt haben, die unter der Identität ausgeführt werden müssen, die einer mit GitHub verknüpften Funktion zugeordnet ist, wie dependabot[bot], dann muss diese Identität als berechtigter Akteur hinzugefügt werden.
Einschränken von Ereignissen
Ereignisregeln steuern, welche Ereignisse zulässig sind, wie push, pull_request, pull_request_target und workflow_dispatch.
Sperrdatei erfordern
Der Require lockfile-Schutz blockiert Ausführungen von gezielten Workflows, die nicht in die Sperrdatei des Repositorys integriert sind. Auf diese Weise führen die gezielt ausgewählten Workflows geprüften, vorhersehbaren Code aus, anstelle dessen, worauf ein Tag oder Branch zur Laufzeit verweist. Dieser Schutz und Sperrdateien im Allgemeinen decken nur Aktionen ab, die auf der Schritt-Ebene aufgerufen werden (jobs.<job_id>.steps[*].uses). Sie decken keine wiederverwendbaren Workflows ab, die auf Jobebene (jobs.<job_id>.uses) aufgerufen werden. Wenn ein aufgerufener wiederverwendbarer Workflow nicht in der Sperrdatei seines eigenen Repositorys aufgenommen ist, blockiert dieser Schutz die Ausführung des aufrufenden Workflows. Siehe Sperrdateien für Workflow-Abhängigkeiten.
Generieren und überprüfen Sie Sperrdateien in den Repositorys, auf die Sie abzielen, bevor Sie diesen Schutz auf "Aktiv" festlegen. Andernfalls werden Sie Workflowausführungen in Repositorys blockieren, die nicht bereit sind. Eine gestaffelte Einführung finden Sie unter Erzwingen von Lockfiles für Abhängigkeiten von Aktionen.
Sie können die separate Richtlinie Aktionen müssen an eine Commit-SHA voller Länge angeheftet werden bei der Einführung von Lockfiles aktiviert lassen. Eine Sperrdatei erfüllt die SHA-Pinning-Anforderung für Workflows, für die eine Sperrdatei eingerichtet wurde.
Beide Richtlinien sind unabhängige Prüfungen, und eine Workflowausführung muss beide bestehen, wenn beide aktiviert sind:
- Ein Workflow, der sich in der Sperrdatei befindet, erfüllt beide Richtlinien, ohne dass SHAs in der Workflowdatei erforderlich sind.
- Ein Workflow, der sich nicht im Lockfile befindet und bei dem
uses:-Referenzen an eine vollständige Commit-SHA angeheftet sind, besteht die SHA-Pinning-Prüfung, wird jedoch durch Require lockfile blockiert. - Ein Workflow, der sich nicht in der Sperrdatei befindet, mit
uses:Verweisen auf ein Tag oder eine Verzweigung, wird durch beide Richtlinien blockiert.
Richtlinien auswerten
Sie können Richtlinieneinblicke anzeigen, um Workflow-Ausführungen zu sehen, die blockiert wurden (bei aktiven Richtlinien) oder blockiert worden wären (bei „Auswerten“-Richtlinien). Dies ist eine gute Möglichkeit, zu überprüfen, ob Richtlinien wie beabsichtigt funktionieren und keine unnötigen Reibungsverluste verursachen.
Um Einblicke anzuzeigen, klicken Sie auf die Seite " Richtlinieneinblicke ". Sie finden dies direkt unter der Seite „GitHub Actions-Richtlinien“ in der Seitenleiste Ihres Repositorys, Ihrer Organisation oder Ihres Unternehmens.