Erzwingen von Richtlinien für GitHub Actions in Ihrem Unternehmen

Was sind Richtlinien für GitHub Actions?

Unternehmensrichtlinien steuern die Optionen, die Unternehmensmitgliedern zur Verfügung stehen, wenn sie GitHub Actions verwenden.

Wenn Sie keine Unternehmensrichtlinien erzwingen, haben Organisationsbesitzer und Benutzer mit der Berechtigung zum „Verwalten von Organisationsaktionen-Richtlinien“ die volle Kontrolle über GitHub Actions für ihre Organisationen.

Durchsetzen von Richtlinien

1. Navigieren Sie zu Ihrem Unternehmen. Beispielsweise auf der Seite Unternehmen in GitHub.com.
2. Klicke oben auf der Seite auf Policies.
3. Klicke unter „ Policies“ auf Actions.
4. Klicken Sie nach dem Konfigurieren jeder Richtlinie auf Speichern.

Weitere Informationen zu den einzelnen Abschnitten der Seite „Richtlinien“ finden Sie, wenn Sie weiterlesen.

Richtlinien

Im Abschnitt „Richtlinien“ können Sie steuern, welche Organisationen innerhalb Ihres Unternehmens GitHub Actions verwenden können. Dafür gibt es folgende Optionen:

• Aktiviere GitHub Actions für alle Organisationen
• GitHub Actions für bestimmte Organisationen aktivieren
• GitHub Actions für alle Organisationen deaktivieren

Zugriff auf öffentliche Aktionen und wiederverwendbare Workflows steuern.

Unternehmen möchten häufig den Zugriff auf eine gut getestete Gruppe öffentlicher Aktionen und wiederverwendbare Workflows als Teil der Governance ihrer Lieferkette einschränken. Die richtlinien, die in GitHub verfügbar sind, ermöglichen Ihnen die Steuerung des Zugriffs, ohne die dynamischen Workflows zu blockieren, die von code scanning und GitHub Code Quality verwendet werden.

Du kannst strenge Kontrollen durchsetzen, ohne Ausnahmen oder zusätzliche Konfigurationen für code scanning und GitHub Code Quality zu definieren, indem du die folgenden Optionen verwendest:

•         **Alle Aktionen und wiederverwendbaren Workflows zulassen**: Alle Aktionen oder wiederverwendbaren Workflows können verwendet werden, unabhängig davon, wer sie erstellt hat oder wo sie definiert sind.
  

•         **Unternehmensinterne Aktionen und wiederverwendbare Workflows zulassen**: Nur Aktionen und wiederverwendbare Workflows, die in einem Repository innerhalb des Unternehmens definiert sind, können verwendet werden. Blockiert den gesamten Zugriff auf Aktionen, die von GitHub erstellt wurden, z. B. die Aktion [`actions/checkout`](https://github.com/actions/checkout).
  

• Enterprise-Workflows zulassen und Workflows ohne Enterprise, Aktionen und wiederverwendbare Workflows auswählen: Alle Aktionen oder wiederverwendbaren Workflows, die in einem Repository innerhalb des Unternehmens definiert sind, sowie alle Aktionen oder wiederverwendbaren Workflows, die den von Ihnen vorgegebenen Kriterien entsprechen, können verwendet werden.

•         **All actions must be pinned to a full-length commit SHA to be used**: Alle Aktionen müssen an einen SHA-Commit mit vollständiger Länge angeheftet werden, damit sie verwendet werden können. Dies schließt Aktionen aus deinem Unternehmen sowie Aktionen ein, die von GitHub erstellt wurden. Wiederverwendbare Workflows können weiterhin nach Tag referenziert werden. Weitere Informationen findest du unter [AUTOTITLE](/actions/reference/security/secure-use#using-third-party-actions).
  

Enterprise-Workflows zulassen und Workflows ohne Enterprise, Aktionen und wiederverwendbare Workflows auswählen

Wenn Sie diese Option auswählen, sind Aktionen und wiederverwendbare Workflows innerhalb Ihres Unternehmens zulässig, und Sie haben die folgenden Optionen, um andere Aktionen und wiederverwendbare Workflows zuzulassen:

•         **Aktionen zulassen, die durch GitHub erstellt wurden:** Zugelassen werden alle durch GitHub erstellten Aktionen aus den Organisationen [`actions`](https://github.com/actions) und [`github`](https://github.com/github).
  

•         **Marketplace-Aktionen von verifizierten Erstellern zulassen:** Es werden alle GitHub Marketplace-Aktionen zugelassen, die von verifizierten Erstellern erstellt und mit dem Zeichen <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-verified" aria-label="The verified badge" role="img"><path d="m9.585.52.929.68c.153.112.331.186.518.215l1.138.175a2.678 2.678 0 0 1 2.24 2.24l.174 1.139c.029.187.103.365.215.518l.68.928a2.677 2.677 0 0 1 0 3.17l-.68.928a1.174 1.174 0 0 0-.215.518l-.175 1.138a2.678 2.678 0 0 1-2.241 2.241l-1.138.175a1.17 1.17 0 0 0-.518.215l-.928.68a2.677 2.677 0 0 1-3.17 0l-.928-.68a1.174 1.174 0 0 0-.518-.215L3.83 14.41a2.678 2.678 0 0 1-2.24-2.24l-.175-1.138a1.17 1.17 0 0 0-.215-.518l-.68-.928a2.677 2.677 0 0 1 0-3.17l.68-.928c.112-.153.186-.331.215-.518l.175-1.14a2.678 2.678 0 0 1 2.24-2.24l1.139-.175c.187-.029.365-.103.518-.215l.928-.68a2.677 2.677 0 0 1 3.17 0ZM7.303 1.728l-.927.68a2.67 2.67 0 0 1-1.18.489l-1.137.174a1.179 1.179 0 0 0-.987.987l-.174 1.136a2.677 2.677 0 0 1-.489 1.18l-.68.928a1.18 1.18 0 0 0 0 1.394l.68.927c.256.348.424.753.489 1.18l.174 1.137c.078.509.478.909.987.987l1.136.174a2.67 2.67 0 0 1 1.18.489l.928.68c.414.305.979.305 1.394 0l.927-.68a2.67 2.67 0 0 1 1.18-.489l1.137-.174a1.18 1.18 0 0 0 .987-.987l.174-1.136a2.67 2.67 0 0 1 .489-1.18l.68-.928a1.176 1.176 0 0 0 0-1.394l-.68-.927a2.686 2.686 0 0 1-.489-1.18l-.174-1.137a1.179 1.179 0 0 0-.987-.987l-1.136-.174a2.677 2.677 0 0 1-1.18-.489l-.928-.68a1.176 1.176 0 0 0-1.394 0ZM11.28 6.78l-3.75 3.75a.75.75 0 0 1-1.06 0L4.72 8.78a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L7 8.94l3.22-3.22a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042Z"></path></svg> versehen sind.
  

•         **Allow or block specified actions and reusable workflows:** Lässt Aktionen und wiederverwendbare Workflows zu, die du angibst. Es können einzelne Aktionen und wiederverwendbare Workflows oder ganze Organisationen und Repositorys vorgegeben werden.
  

Bei Vorgeben von Aktionen und wiederverwendbaren Workflows ist die folgende Syntax zu verwenden:

• Um den Zugriff auf bestimmte Tags oder Commit-SHA-Werte einer Aktion oder eines wiederverwendbaren Workflows einzuschränken, verwende dieselbe Syntax, die im Workflow genutzt wird, um die Aktion oder den wiederverwendbaren Workflow auszuwählen.
  • Für eine Aktion ist die Syntax OWNER/REPOSITORY@TAG-OR-SHA. Verwende beispielsweise actions/javascript-action@v1.0.1 zum Auswählen eines Tags oder actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f zum Auswählen eines SHA-Werts.
  • Für einen wiederverwendbaren Workflow ist die Syntax OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA. Beispiel: octo-org/another-repo/.github/workflows/workflow.yml@v1.
• Zum Angeben eines Musters ist ein Platzhalterzeichen, *, zu verwenden.
  • Um alle Aktionen und wiederverwendbaren Workflows in Organisationen zuzulassen, die mit space-org beginnen, ist space-org*/* anzugeben.
  • Um alle Aktionen und wiederverwendbaren Workflows in Repositorys zuzulassen, die mit „octocat“ beginnen, ist */octocat**@* zu verwenden.
• Um mehrere Muster anzugeben, verwende ,, um die Muster zu trennen.
  • Um alle Aktionen und wiederverwendbare Workflows aus den Organisationen octocat und octokit zuzulassen, verwende octocat/*, octokit/*.
• Um bestimmte Muster zu blockieren, verwende das Präfix !.
  • Um alle Aktionen und wiederverwendbare Workflows aus der space-org-Organisation zuzulassen, aber eine bestimmte Aktion wie space-org/action zu blockieren, verwende space-org/*, !space-org/action@*.
  • Standardmäßig sind nur Aktionen und wiederverwendbare Workflows zulässig, die in der Liste angegeben sind. Verwende *, !space-org/action@*, um alle Aktionen und wiederverwendbare Workflows zuzulassen und gleichzeitig bestimmte Aktionen zu blockieren.

Richtlinien beschränken niemals den Zugriff auf lokale Aktionen im Dateisystem des Runners, wo der Pfad uses: mit ./ beginnt.

Runner

Standardmäßig kann jede Person mit Administratorzugriff auf ein Repository einen selbstgehosteten Runner für das Repository hinzufügen. Selbstgehostete Runner sind mit Risiken verbunden:

• Es gibt keine Garantie, dass selbst gehostete Runner auf kurzlebigen, bereinigten virtuellen Computern gehostet werden. Infolgedessen können sie durch nicht vertrauenswürdigen Code in einem Workflow kompromittiert werden.
• Jeder, der das Repository forken und einen Pull Request öffnen kann, kann die selbstgehostete Runner-Umgebung kompromittieren und möglicherweise Zugriff auf Geheimnisse und den GITHUB_TOKEN erhalten, der möglicherweise Schreibzugriff auf das Repository hat.

Im Abschnitt „Runners“ können Sie diese Risiken entschärfen, indem Sie die Verwendung selbstgehosteter Runner auf Repositoryebene deaktivieren.

•         **Für alle Organisationen deaktivieren**: Verhindert die Erstellung von Runnern auf Repositoryebene.
  

•         **In allen Enterprise Managed User (EMU)-Repositorys deaktivieren:**  Verhindert die Erstellung von Runnern für Repositorys, die sich im Besitz von verwaltete Benutzerkonten befinden.
  

Benutzerdefinierte Images

Im Abschnitt "Benutzerdefinierte Bilder" können Sie steuern, welche Organisationen in Ihrem Unternehmen benutzerdefinierte Images mit der folgenden Zugriffsrichtlinie erstellen und verwalten dürfen:

•         **Für alle Organisationen aktivieren**: Alle Organisationen, einschließlich aller in Zukunft erstellten, können benutzerdefinierte Images verwenden oder erstellen.
  

•         **Aktivieren sie für bestimmte Organisationen**: Nur ausgewählte Organisationen können benutzerdefinierte Images verwenden oder erstellen.
  

•         **Für alle Organisationen deaktivieren**: Es kann keine Organisation benutzerdefinierte Bilder verwenden oder erstellen.
  

Aufbewahrungsrichtlinien für benutzerdefinierte Bilder

Sie können definieren, wie lange benutzerdefinierte Bildversionen aufbewahrt werden und wann sie inaktiv werden.

•         **Maximale Versionen pro Bild**: Beschränkt die Anzahl der Versionen jedes Bilds. Wenn dieser Grenzwert überschritten wird, werden die ältesten nicht verwendeten Bildversionen automatisch gelöscht.
  

  * Standard: 20 Versionen * Konfigurierbarer Bereich: 1–100 Versionen

•         **Aufbewahrung nicht verwendeter Versionen**: Löscht Bildversionen, die nicht für eine bestimmte Anzahl von Tagen verwendet wurden. Bildversionen, die einem Läuferpool zugewiesen sind, aber nicht aktiv verwendet werden, werden ebenfalls als nicht verwendet betrachtet.
  

  * Standard: 30 Tage * Konfigurierbarer Bereich: 1 bis 90 Tage

•         **Maximales Versionsalter**: Deaktiviert Bildversionen, die vor der angegebenen Anzahl von Tagen erstellt wurden. Deaktivierte Imageversionen können von Läufern erst verwendet werden, wenn der Richtliniengrenzwert erhöht wird.
  

  * Standard: 60 Tage * Konfigurierbarer Bereich: 7 bis 90 Tage

Artefakt- und Protokollaufbewahrung

Standardmäßig werden von Workflows generierte Artefakte und Protokolldateien 90 Tage lang aufbewahrt. Sie können den Aufbewahrungszeitraum ändern.

• Für öffentliche Repositorys können Sie einen Zeitraum zwischen 1 und 90 Tagen konfigurieren.
• Für private und interne Repositorys können Sie einen Zeitraum zwischen 1 und 400 Tagen konfigurieren.

Änderungen gelten nur für neue Artefakte und Protokolldateien.

Cacheeinstellungen

Sie können maximale Cacheaufbewahrungs- und Größenbeschränkungen konfigurieren, die für ihr gesamtes Unternehmen gelten. Wenn Sie das Limit der "Cache-Größeneviktierung" über die in Ihrem Plan enthaltenen 10 GB erhöhen, fallen zusätzliche Gebühren für den Speicherplatz zum Zwischenspeichern weiterer Daten an.

Standardmäßig:

• Caches werden 7 Tage vor dem automatischen Löschen aufbewahrt.
• Der gesamte Cachespeichergrenzwert beträgt 10 GB pro Repository.

Sie können diese Einstellungen anpassen, um maximale Grenzwerte für die Cacheaufbewahrung und die Cachespeichergröße in Ihrem Unternehmen festzulegen:

•         **Cacheaufbewahrung**: Konfigurieren Sie bis zu 90 Tage für öffentliche Repositorys oder 365 Tage für private und interne Repositorys.
  

•         **Cachegrößengrenzwert für Entfernung**: Konfiguriere bis zu 10.000 GB pro Repository.
  

Die Einstellungen, die Sie auf Unternehmensebene konfigurieren, dienen als maximale Grenzwerte. Organisationsbesitzer können sich für die Konfiguration von Grenzwerten für ihre Organisation entscheiden, aber die auf Unternehmensebene festgelegten Grenzwerte nicht überschreiten. Repositoryadministratoren können sich für die Konfiguration von Grenzwerten für ihre Repositorys entscheiden, aber die auf Organisationsebene festgelegten Grenzwerte nicht überschreiten.

Weitere Informationen zur Cacheräumung finden Sie unter Referenz zum Zwischenspeichern von Abhängigkeiten.

Forkworkflows für Pullanforderungen von externen Mitarbeitenden

Jede Person kann ein öffentliches Repository forken und dann einen Pull Request übermitteln, um Änderungen an den Workflows des Repositorys vorzuschlagen. Um Missbrauch zu verhindern, werden Workflows bei Pull Requests, die von einigen Mitwirkenden erstellt wurden, nicht automatisch ausgeführt.

Sie können konfigurieren, welche Pull Requests vor der Ausführung genehmigt werden müssen.

•         **Erfordern Sie eine Genehmigung für erstmalige Mitwirkende, die neu bei GitHub sind**. Erfordert eine Genehmigung für benutzende Personen, die nie einen Commit an das Repository ausgeführt haben und deren GitHub-Konten neu sind.
  

•         **Genehmigung für erstmalige Mitwirkende erforderlich**. Verlangt eine Genehmigung für Benutzer, die nie einen Commit an das Repository vorgenommen haben.
  

•         **Genehmigung für alle externen Projektmitarbeiter erforderlich**. Verlangt eine Genehmigung für alle Benutzer, die keine Organisationsmitglieder sind.
  

Forkworkflows für Pullanforderungen in privaten Repositorys

Sie können steuern, wie Benutzer Workflows für pull_request-Ereignisse in privaten und internen Repositorys ausführen können.

•         **Ausführen von Workflows aus Fork-Pull Requests**. Benutzer können Workflows aus Fork-Pull Requests ausführen. Standardmäßig verwenden Workflows ein `GITHUB_TOKEN` nur mit Leseberechtigung ohne Zugriff auf Geheimnisse.
  

•         **Senden von Schreibberechtigungen an Workflows von Pull Requests**. Workflows verwenden ein `GITHUB_TOKEN` mit Schreibberechtigung.
  

•         **Geheimnisse an Workflows aus Pull-Anfragen senden**. Alle Geheimnisse sind für den Pull Request verfügbar.
  

•         **Anforderung einer Genehmigung für Fork-Pull-Request-Workflows**. Workflows für Pull Requests von Projektmitarbeitern ohne Schreibberechtigung müssen vor ihrer Ausführung von einer Person mit Schreibberechtigung genehmigt werden.
  

Wenn eine Richtlinie für ein Unternehmen aktiviert ist, kann die Richtlinie in einzelnen Organisationen oder Repositorys selektiv deaktiviert werden. Wenn eine Richtlinie für ein Unternehmen deaktiviert ist, können einzelne Organisationen oder Repositorys sie nicht aktivieren.

Workflowberechtigungen

Im Abschnitt „Workflowberechtigungen“ können Sie die Standardberechtigungen festlegen, die für GITHUB_TOKEN gewährt werden.

•         **Lese- und Schreibberechtigungen:** Die Standardberechtigungen für `GITHUB_TOKEN` hängen davon ab, wann das Unternehmen oder die Organisation erstellt wurde:
  

  * Erstellt am oder nach dem 2. Februar 2023: standardmäßig schreibgeschützter Zugriff für alle Bereiche * Erstellt am oder vor dem 2. Februar 2023: standardmäßig Lese- und Schreibzugriff für alle Bereiche

•         **Lesen von Repositoryinhalten und Paketberechtigungen**: Standardmäßig hat `GITHUB_TOKEN` nur Lesezugriff für die Bereiche `contents` und `packages`. Die Einstellung mit mehr Berechtigungen kann nicht als Standard für einzelne Organisationen oder Repositories ausgewählt werden.
  

Jeder mit Schreibzugriff auf ein Repository kann dennoch die dem GITHUB_TOKEN erteilten Berechtigungen für einen bestimmten Workflow ändern, indem er den permissions-Schlüssel in der Workflowdatei bearbeitet.

          **GitHub-Aktionen das Erstellen und Genehmigen von Pullanforderungen erlauben** ist standardmäßig deaktiviert. Wenn Sie diese Einstellung aktivieren, kann `GITHUB_TOKEN` Pull Requests erstellen und genehmigen.