Erzwingen von Richtlinien für GitHub Actions in Ihrem Unternehmen

Welche Richtlinien gelten für GitHub Actions?

Unternehmensrichtlinien steuern die Optionen, die für Unternehmensmitglieder verfügbar sind, wenn sie sie verwenden GitHub Actions.

Wenn Sie keine Unternehmensrichtlinien erzwingen, haben Organisationsbesitzer und Benutzer mit der Berechtigung "Organisationsaktionen verwalten" die vollständige Kontrolle über GitHub Actions ihre Organisationen.

Durchsetzen von Richtlinien

1. Navigieren Sie zu Ihrem Unternehmen. Beispielsweise auf der Seite Unternehmen in GitHub.com.
2. Klicken Sie oben auf der Seite auf "Richtlinien".
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 in Ihrem Unternehmen mit den folgenden Optionen verwenden GitHub Actionskönnen:

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

Steuern des Zugriffs auf öffentliche Aktionen und wiederverwendbare Workflows

Unternehmen möchten häufig den Zugriff auf eine gut getestete Gruppe öffentlicher Aktionen und wiederverwendbarer Workflows als Teil ihrer Lieferkettengovernance beschränken. Die in GitHub verfügbaren Richtlinien ermöglichen es Ihnen, den Zugriff zu steuern, ohne die dynamischen Workflows zu blockieren, die von code scanning und GitHub Code Quality verwendet werden.

Mit den folgenden Optionen können Sie strikte Kontrollen durchsetzen, ohne Ausnahmen oder zusätzliche Konfigurationen für code scanning und GitHub Code Quality zu definieren:

• Alle Aktionen und wiederverwendbaren Workflows zulassen: Jede Aktion oder ein wiederverwendbarer Workflow kann verwendet werden, unabhängig davon, wer sie erstellt hat oder wo er definiert ist.
• Zulassen von Unternehmensaktionen und wiederverwendbaren Workflows: 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, z. B. der actions/checkout Aktion, erstellt wurden.
• Enterprise-Workflows zulassen und Workflows ohne Enterprise, Aktionen und wiederverwendbare Workflows auswählen: Jede Aktion oder ein wiederverwendbarer Workflow , der in einem Repository innerhalb des Unternehmens definiert ist, kann verwendet werden, sowie alle Aktionen oder wiederverwendbaren Workflows , die den von Ihnen angegebenen Kriterien entsprechen.
• 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 umfasst Aktionen aus Ihrem Unternehmen sowie von GitHub erstellte Aktionen. Auf wiederverwendbare Workflows kann weiterhin nach Tag verwiesen werden. Weitere Informationen findest du unter Referenz zur sicheren Verwendung.

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

Wenn Sie diese Option auswählen, sind Aktionen und wiederverwendbare Workflows in Ihrem Unternehmen zulässig, und Sie haben die folgenden Optionen, um andere Aktionen und wiederverwendbare Workflows zuzulassen:

• Aktionen zulassen, die von GitHub erstellt wurden: Ermöglicht alle Aktionen, die von GitHub erstellt wurden und sich in den Organisationen actions und github befinden.
• Marketplace-Aktionen von verifizierten Erstellern zulassen: Ermöglicht alle GitHub Marketplace von verifizierten Erstellern erstellten Aktionen, die mit gekennzeichnet sind.
• Zulassen oder Blockieren von angegebenen Aktionen und wiederverwendbaren Workflows: Ermöglicht Aktionen und wiederverwendbare Workflows , die Sie angeben. Sie können einzelne Aktionen und wiederverwendbare Workflows oder ganze Organisationen und Repositorys angeben.

Verwenden Sie beim Angeben von Aktionen und wiederverwendbaren Workflows die folgende Syntax:

• Um den Zugriff auf bestimmte Tags einzuschränken oder SHAs einer Aktion oder eines wiederverwendbaren Workflows zu übernehmen, verwenden Sie dieselbe Syntax, die im Workflow zum Auswählen der Aktion oder des wiederverwendbaren Workflows verwendet wird.
  • 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 für Organisationen zuzulassen, die mit space-org beginnen, verwenden Sie space-org*/*.
  • Um alle Aktionen und wiederverwendbaren Workflows in Repositorys zuzulassen, die mit octocat beginnen, verwenden Sie */octocat**@*.
• Um mehrere Muster anzugeben, verwende ,, um die Muster zu trennen.
  • Um alle Aktionen und wiederverwendbaren Workflows aus den octocat und octokit Organisationen zuzulassen, verwenden Sie octocat/*, octokit/*.
• Um bestimmte Muster zu blockieren, verwende das Präfix !.
  • Um alle Aktionen und wiederverwendbaren Workflows aus der Organisation space-org zuzulassen, aber eine bestimmte Aktion wie space-org/action zu blockieren, verwenden Sie space-org/*, !space-org/action@*.
  • Standardmäßig sind nur Aktionen und wiederverwendbare Workflows zulässig, die in der Liste angegeben sind. Um alle Aktionen und wiederverwendbaren Workflows zuzulassen und gleichzeitig bestimmte Aktionen zu blockieren, verwenden Sie *, !space-org/action@*.

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 Repositories von Enterprise Managed Users (EMU) deaktivieren: Verhindert das Erstellen von Runnern für Repositories im Besitz von verwaltete Benutzerkonten.

Deaktivieren von standardmäßig gehosteten Runnern

Sie können standardmäßige GitHub-gehostete Runner auf Enterprise-Ebene deaktivieren. Diese Einstellung erfordert, dass Workflows Runner über Runner-Gruppen ansprechen, und trägt dazu bei, konsistente Zugriffskontrollen und Governance durchzusetzen.

Informationen zu den Grenzwerten für die Auftragsparallelität bei GitHub-gehosteten Runnern finden Sie in Actions-Grenzwerte.

1. Navigieren Sie zu Ihrem Unternehmen. Beispielsweise auf der Seite Unternehmen in GitHub.com.
2. Klicken Sie oben auf der Seite auf "Richtlinien".
3. Klicke unter „ Policies“ auf Actions.
4. Scrollen Sie zum Abschnitt "Standard gehostete Läufer", und klicken Sie für alle Organisationen auf "Deaktivieren".
5. Klicke auf Speichern.

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.

• Genehmigung für Mitwirkende erforderlich, die bei GitHub neu sind. Erfordert eine Genehmigung für Benutzer, die sich nie für das Repository verpflichtet haben und über neue GitHub Konten verfügen.
• 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.