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. Klicke in der oberen rechten Ecke von GitHub Enterprise Server auf dein Profilbild und dann auf Enterprise settings.
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

Unternehmen möchten häufig den Zugriff auf eine gut getestete Gruppe öffentlicher Aktionen 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 zulassen: Jede Aktion kann verwendet werden, unabhängig davon, wer sie erstellt hat oder wo er definiert ist.

• Zulassen von Unternehmensaktionen : Nur Aktionen , die in einem Repository innerhalb des Unternehmens definiert sind, können verwendet werden.

• Ausgewählte Aktionen zulassen: Jede Aktion , der in einem Repository innerhalb des Unternehmens definiert ist, kann verwendet werden, sowie alle Aktionen , 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. Weitere Informationen findest du unter Referenz zur sicheren Verwendung.

Ausgewählte Aktionen zulassen

Wenn Sie diese Option auswählen, sind Aktionen in Ihrem Unternehmen zulässig, und Sie haben die folgenden Optionen, um andere Aktionen 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.

  Nur verfügbar, wenn GitHub Connect aktiviert und mit GitHub Actions konfiguriert ist. Siehe Aktivieren des automatischen Zugriffs auf GitHub.com Aktionen mithilfe von GitHub Connect.

• Zulassen oder Blockieren von angegebenen Aktionen: Ermöglicht Aktionen , die Sie angeben. Sie können einzelne Aktionen oder ganze Organisationen und Repositorys angeben.

Verwenden Sie beim Angeben von Aktionen die folgende Syntax:

• Um den Zugriff auf bestimmte Tags einzuschränken oder SHAs einer Aktion zu übernehmen, verwenden Sie dieselbe Syntax, die im Workflow zum Auswählen der Aktion 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.
• Zum Angeben eines Musters ist ein Platzhalterzeichen, *, zu verwenden.
  • Um alle Aktionen für Organisationen zuzulassen, die mit space-org beginnen, verwenden Sie space-org*/*.
  • Um alle Aktionen in Repositorys zuzulassen, die mit octocat beginnen, verwenden Sie */octocat**@*.
• Um mehrere Muster anzugeben, verwende ,, um die Muster zu trennen.
  • Um alle Aktionen aus den octocat und octokit Organisationen zuzulassen, verwenden Sie octocat/*, octokit/*.
• Um bestimmte Muster zu blockieren, verwende das Präfix !.
  • Um alle Aktionen 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 zulässig, die in der Liste angegeben sind. Um alle Aktionen 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.

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. Klicke in der oberen rechten Ecke von GitHub Enterprise Server auf dein Profilbild und dann auf Enterprise settings.
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-, Protokoll- und Cacheeinstellungen

Diese Richtlinien steuern die Speicherung von Artefakten, Protokollen und Caches.

Aufbewahrung von Artefakten und Protokollen

Standardmäßig werden von Workflows generierte Artefakte und Protokolldateien 90 Tage lang aufbewahrt. Sie können diesen Aufbewahrungszeitraum zwischen 1 und 400 Tagen ändern.

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

Grenzwerte für maximale und standardmäßige Cachegröße

Standardmäßig:

• Der gesamte Cache-Speicher, den GitHub Actions im externen Speicher für Ihre GitHub Enterprise Server-Instance verwendet, ist auf maximal 10 GB pro Repository beschränkt.
• Die maximal zulässige Größe, die für ein Repository festgelegt werden kann, beträgt 25 GB.

Wenn du diesen Grenzwert überschreitest, wird GitHub den neuen Cache speichern, jedoch auch damit beginnen, Caches zu löschen, bis die Gesamtgröße kleiner als das Limit des Repositorys ist.

Sowohl die standardmäßige Gesamtgröße des Caches für ein Repository als auch die maximal zulässige Gesamtgröße des Caches für ein Repository kann angepasst werden. Sie möchten z. B., dass die Gesamtgröße des Caches für jedes Repository standardmäßig 5 GB beträgt, aber den Administratoren die Möglichkeit geben, bei Bedarf eine Gesamtgröße des Caches von maximal 15 GB für einzelne Repositorys zu konfigurieren.

Organisationsbesitzende können eine niedrigere Cachegesamtgröße festlegen, die für jedes Repository in ihrer Organisation gilt. Personen mit Administratorzugriff auf ein Repository können eine Cachegesamtgröße für ihre Repositorys festlegen, die der maximal zulässigen Cachegröße gemäß der Richtlinieneinstellung für das Unternehmen oder die Organisation entspricht.

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.