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. Klicke in der oberen rechten Ecke von GitHub Enterprise Server auf dein Profilbild und dann auf Enterprise settings.
2. Klicke links auf der Seite auf der Randleiste des Enterprise-Kontos 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 steuern.

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

•         **Unternehmensinterne Aktionen  zulassen**: Nur Aktionen , die in einem Repository innerhalb des Unternehmens definiert sind, können verwendet werden. 
  

• Ausgewählte Aktionen zulassen: Alle Aktionen , die in einem Repository innerhalb des Unternehmens definiert sind, sowie alle Aktionen , die den von Ihnen vorgegebenen Kriterien entsprechen, können verwendet werden.

Ausgewählte Aktionen zulassen

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

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

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

Bei Vorgeben von Aktionen ist die folgende Syntax zu verwenden:

• Um den Zugriff auf bestimmte Tags oder Commit-SHA-Werte einer Aktion einzuschränken, verwende dieselbe Syntax, die im Workflow genutzt wird, um die Aktion 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.
• Zum Angeben eines Musters ist ein Platzhalterzeichen, *, zu verwenden.
  • Um alle Aktionen in Organisationen zuzulassen, die mit space-org beginnen, ist space-org*/* anzugeben.
  • Um alle Aktionen in Repositorys zuzulassen, die mit „octocat“ beginnen, ist */octocat**@* zu verwenden.
• Um mehrere Muster anzugeben, verwende ,, um die Muster zu trennen.
  • Um alle Aktionen aus den Organisationen octocat und octokit zuzulassen, verwende octocat/*, octokit/*.

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.

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 auf einen beliebigen Wert 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 Cachespeicher, 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.