GitHub-Aktionen & Sicherheit: Bewährte Praktiken

Ich habe mich mit den Sicherheitsaspekten der Verwendung von GitHub-Aktionen und wollte einige bewährte Verfahren an einem Ort teilen. Wenn Sie sich lieber in einer Präsentation als in einem Blog einen Überblick verschaffen möchten, finden Sie auch eine meiner Konferenzsitzungen zu diesem Thema hier.

Foto von Jon Moore auf Unsplash

Einrichten eines internen Marktplatzes für GitHub-Aktionen

Alle Beiträge führen letztendlich dazu, einen internen Marktplatz für GitHub-Aktionen einzurichten: etwas, das Ihr Team kontrollieren kann, das verhindert, dass zufällige Aktionen verwendet werden, und das Ihnen die Möglichkeit gibt, tatsächliche Sicherheitsüberprüfungen für die verwendeten Aktionen durchzuführen. Erfahren Sie, wie Sie einen solchen Marktplatz in Ihrer Organisation einrichten können hier.

Aktions-Repositories forken

In dem Beitrag auf Forkingaction repositories zeige ich diese Best Practices:

• Überprüfen Sie den Code, den die Aktion ausführt
• Pinning-Versionen
• Repositories forken
• Halten Sie Ihre Gabeln auf dem neuesten Stand

Zusätzlich (und vor allem in einem Unternehmen) sollten Sie Ihren eigenen internen Marktplatz für Aktionen einrichten. Wie Sie diesen einrichten und einen guten Sicherheitsprozess dafür einrichten, erfahren Sie hier hier.

Halten Sie Ihre Gabeln auf dem neuesten Stand

Nachdem Sie alle Aktionen, die Sie verwenden möchten, geforkt haben, müssen Sie sich auch um die Wartung kümmern. Ich habe eine gute Methode beschrieben, um Ihre Forks auf dem neuesten Stand zu halten hier, indem Sie sicherstellen, dass Sie die eingehenden Änderungen überprüfen, bevor Sie sie zusammenführen.

Sichern Sie Ihre privaten Läufer

In dem Beitrag auf Private Läufer erkläre ich diese bewährten Verfahren:

• Beschränken Sie den Zugriff auf Ihren privaten Läufer
• Verwenden Sie einen Runner nicht für mehr als ein Repository
• Verwenden Sie niemals einen privaten Runner für Ihre öffentlichen Repositories

Verwenden Sie einen Läufer niemals wieder!

• Ein Läufer, ein Arbeitsablauf

Führen Sie Ihre eigene Aktion in einem Container aus

Um eine zusätzliche Grenze für Ihre Aktion zu haben, können Sie sie innerhalb eines Containers ausführen. Dadurch können Sie auch etwas in Ihrem Container verwenden, das nicht auf dem Runner selbst installiert sein muss: Führen Sie Ihre Aktion in einem Container aus.

Lassen Sie Ihre Runner in einem Kubernetes-Cluster laufen

Um viele Angriffsvektoren bei der Ausführung Ihrer Runner auf einer virtuellen Maschine zu entschärfen (z.B. Festplatten-/Netzwerkzugriff), können Sie Ihre selbst gehosteten Runner in einer Kubernetes cluster. Dann haben Sie 'ephemere' Läufer, die nur während der Ausführung Ihres Arbeitsablaufs existieren und dann bereinigt werden.

Nicht vertrauenswürdige Eingabe

Ein Überblick von GitHub über nicht vertrauenswürdige Eingaben, vom Issue-Titel bis zur Commit-Nachricht. Wenn Sie auf diese Eingaben reagieren (und sei es nur, indem Sie sie in die Ausgabe einfließen lassen!), können sie missbraucht werden und stellen daher einen Angriffsvektor dar.

Verhindern von Pwn-Anfragen

Früher haben Sie Ihren Arbeitsablauf mit Hilfe des Befehls pull_request in der Auslöserdefinition. Dieser Bereich hatte zu viele Rechte, daher hat GitHub ihn eingeschränkt. Der Bereich mit mehr Rechten (z.B. auf Ihr Zugriffstoken mit einigen Schreibrechten) wurde nun folgendermaßen erstellt pull_request_target. Sie müssen sehr vorsichtig sein mit unter Verwendung dieses Bereichs. Am besten verwenden Sie hier ein Label für die Pull-Anfrage, damit Sie den PR manuell überprüfen und seine tatsächliche Ausführung autorisieren können.

Sie müssen bei eingehenden Pull Requests von jeder Abspaltung sehr vorsichtig sein: Möglicherweise ändern sie Skripte/Befehle in Ihrem Workflow oder sogar den Workflow selbst. Es gab Beispiele, bei denen ein PR eingesandt wurde, der den Arbeitsablauf aktualisierte und die 10 gleichzeitigen Jobs, die für Open-Source-Projekte zur Verfügung stehen, ausnutzte, um ein paar Bitcoin für den Angreifer zu generieren. Das ist der Grund, warum wir keine schönen Dinge haben können!