GitHub Actions[1] sind eine leistungsstarke Möglichkeit, eine Pipeline zu erstellen, um auf Ereignisse in GitHub zu reagieren. Indem Sie eine Workflow-Datei erstellen, führen Sie Aktionen auf Codeaktualisierungen aus, um Ihre Anwendung zu erstellen, Aufgaben zur Lösung von Problemen zu automatisieren und viele andere nützliche Funktionen zu nutzen.
Machen Sie Ihren eigenen Octocat: myoctocat
Tyrannei der Vorgabe
Jede Demo auf GitHub Actions zeigt, wie einfach es ist, loszulegen: Fügen Sie eine Textdatei mit einigen Aktionen hinzu und schon kann es losgehen. Leider ist dies höchst unsicher! Um zu verstehen, warum das so ist, müssen Sie wissen, was die Angriffsvektoren Ihres Workflows sind und wie Sie sich dagegen schützen können.
Lassen Sie uns zunächst mit einer Einführung in GitHub Actions beginnen.
Indem Sie die Datei dotnetcore.yml am richtigen Ort speichern, haben Sie einen neuen Workflow hinzugefügt, der bei Ereignissen ausgelöst werden kann. Es gibt eine Vielzahl von Ereignissen, vom Push-Ereignis in diesem Beispiel(1) bis hin zu Kommentaren zu einer Ausgabe und dem Schließen eines Pull Request.
Im Abschnitt Aufträge(2) können Sie einen oder mehrere Aufträge erstellen, die auf einem bestimmten Läufer ausgeführt werden, der die Schritte(3) in der Reihenfolge der Datei ausführt. In diesem Beispiel wird zuerst das Repository ausgecheckt(3) , dann wird eine Version der .NET Core-Tools installiert(4) und im letzten Schritt wird das .NET Core-Projekt mithilfe der Tools erstellt(5).
Kennen Sie Ihre GitHub-Aktionen
Bei der Verwendung von GitHub-Aktionen ist es wichtig, dass Sie verstehen, was die von Ihnen verwendeten Aktionen tun. Sie können jede Aktion verwenden, indem Sie die Einrichtung von GitHub nutzen: Der Aktionsbezeichner ist die Organisation oder der Benutzername, die/der die Aktion hostet, und der Name des Repositorys, in dem sie sich befindet.
In diesem Beispiel finden Sie die Aktion in der Organisation 'aws-action' in deren eigenen Repositories. Hinzufügen des Aktionspfads zu github direkt zum Aktions-Repositorium.
Eine gültige action.yml im Repository macht es für jeden Workflow nutzbar. Wenn Sie die Aktion auf diese Weise verwenden, stellen Sie sicher, dass die Workflows immer die neueste verfügbare Version des Repositorys herunterladen und den darin enthaltenen Code ausführen. Dies ist auch der größte Nachteil von Aktionen: Die Voreinstellung ist bereits unsicher! Jeder kann eine solche Aktion erstellen und es gibt keinen Prozess, der die von Ihnen verwendete Aktion auf Qualitäts- oder Sicherheitsprobleme prüft. Selbst die Beschränkung der Aktionen, die in Ihrem Unternehmen verwendet werden können, auf die auf dem Marktplatz aufgeführten Aktionen ist unsicher: Es gibt keinen Prozess, der überprüft, ob Ihre Aktion bösartige Dinge tut.
Die Quelle jeder Aktion ist öffentlich, was auch bedeutet, dass Sie sich das Aktions-Repository ansehen und überprüfen können, was sie tut, wenn sie ausgeführt wird. Sie können z.B. überprüfen, ob sie Ihre Umgebungsvariablen an ihre eigene API weiterleitet oder Ihre Betriebssysteminformationen zusammen mit Ihrer IP-Adresse protokolliert.
Was sind die Risiken?
Es ist wunderbar, Aktionen verwenden zu können, die jemand anderes bereits mit viel Zeit und Mühe erstellt hat, was Ihnen möglicherweise eine Menge Zeit spart. Allerdings birgt dies auch ein gewisses Risiko für Ihr Repository, die Anwendung, die Sie erstellen, und die Einrichtung, die sie umgibt. Um das Risiko zu verstehen, müssen wir uns die Ergebnisse eines Angriffs auf Ihre Arbeitsabläufe ansehen.
Ein bösartiger Akteur kann auf drei verschiedene Arten Schaden in Ihrer Anwendung oder deren Umgebung anrichten:
- Datendiebstahl
- Verstöße gegen die Datenintegrität
- Verfügbarkeit
Datendiebstahl
Indem sie sich in Ihre Workflows einklinken, könnten andere Personen Zugriff auf den Code in Ihrem Repository erhalten, aber möglicherweise auch auf die Umgebung, in der Ihr Workflow ausgeführt wird. Diese Umgebung könnte so eingerichtet sein, dass API-Schlüssel für den Zugriff auf Dienste zur Verfügung stehen, die Sie zum Erstellen oder Bereitstellen Ihrer Anwendung benötigen, oder dass Zertifikate zum Signieren von Code installiert sind. Er könnte sogar Zugriff auf ein Konto auf Ihrer Cloud-Plattform haben, das über administrative Rechte verfügt und dort auf Daten zugreifen oder die Infrastruktur löschen kann. Die Beschränkung des Zugriffs für den Läufer, der Ihren Workflow ausführt, auf das absolute Minimum ist der Schlüssel zum Schutz vor Datendiebstahl.
Wenn Sie Ihren Workflow auf gehosteten Runnern[2] ausführen, ist GitHub dafür verantwortlich, diese mit den neuesten Betriebssystem- und Tool-Updates auf dem neuesten Stand zu halten. Um sicherzustellen, dass die Angriffsfläche so klein wie möglich ist, erstellt GitHub für jeden Lauf eine komplett neue Umgebung und bereinigt die Umgebung, wenn sie nicht mehr verwendet wird.
Wenn Sie die Workflows auf privaten Läufern[3] ausführen, liegt es an Ihnen, all diese Sicherheitsmaßnahmen zu ergreifen. Denken Sie daran, dass Sie diese Verantwortung übernehmen, wenn Sie einen privaten Runner installieren. Sie müssen das Betriebssystem sichern und den Zugriff des Kontos, unter dem der Workflow ausgeführt wird, auf die Dinge beschränken, auf die er Zugriff haben muss (weisen Sie ihm also keine Netzwerkadministratorrechte zu!). Sie müssen auch dafür sorgen, dass die Tools auf diesem Rechner mit allen Sicherheits-Patches auf dem neuesten Stand sind.
Verstöße gegen die Datenintegrität
Wenn ein bösartiger Akteur in Ihren Workflow oder Ihre Ausführungsumgebung eindringen kann, kann er auch bösartigen Code in Ihre Anwendung einschleusen. Die meisten Workflows erstellen ein Artefakt zur Bereitstellung in einer Umgebung und speichern die Artefakte in der Pipeline-Umgebung. Es besteht die Möglichkeit, dass der Angreifer etwas in das Artefakt injiziert und die Bereitstellung dann den bösartigen Code für Sie bereitstellt! Der jüngste Angriff von Solorigate[4] ist ein Paradebeispiel für diese Art von Angriff. Das Hinzufügen einer bösartigen Assembly vor dem Hochladen des Artefakts (und die Umgehung einer Vielzahl von Erkennungsmethoden) war der zentrale Punkt, an dem der Angriff ausgeführt wurde.
Andere Beispiele für Verletzungen der Datenintegrität sind das Vergiften Ihres Abhängigkeits-Caches: Es gibt viele Blogposts[5], in denen erklärt wird, dass Sie die Abhängigkeiten, die Sie verwenden, z. B. mit SHA512-Hashes des Commits[6] überprüfen müssen, um sicherzustellen, dass Sie nicht unwissentlich eine neuere Version der Abhängigkeit einbinden, wenn Sie Ihre Anwendung bauen.
Etwas Ähnliches passiert bei Angriffen durch Tippfehler[7]: Können Sie den Unterschied zwischen der Verwendung von 'npm install crossenv' und 'npm install cross-env' erkennen? Ein leicht zu begehender Fehler, aber wenn es sich bei der ersten Variante um eine bösartige Kopie des von Ihnen benötigten Pakets handelt, mit einem Bonuscode, der zur Laufzeit ausgeführt wird, sind Sie vielleicht schon kompromittiert, bevor Sie es merken! Diese Angriffe werden jetzt noch raffinierter, indem sie die Namen der von Ihnen verwendeten internen Pakete herausfinden und eine bösartige Version auf der öffentlichen Repository-Website hosten. Die meisten Pakettools prüfen standardmäßig zuerst die öffentlich gehosteten Endpunkte. Wenn das Paket dort nicht gefunden wird, versucht es dasselbe auf den internen Endpunkten. Sehen Sie sich die Konfigurationen, die Sie verwenden, genau an.
Verfügbarkeit
Ein Angriffsvektor, der weniger wahrscheinlich erscheint, ist das Einschleusen eines Angriffs in Ihren Workflow, der dazu führt, dass der Workflow nicht mehr läuft. Heutzutage sind die meisten DevOps-Teams sehr stark von ihren Pipelines abhängig, um Code in die Produktion zu bringen, und es fällt ihnen schwer, Updates zu veröffentlichen, wenn ihre Pipelines nicht mehr funktionieren. Um den Zugriff der Ingenieure einzuschränken, wird alles gesperrt und nur ein Dienstkonto hat Zugriff auf die Produktion. Was ist, wenn Ihre Anwendung ausfällt oder schlimmer noch: anfällig für einen Angriff ist? Was ist, wenn jemand genau in diesem Moment auslöst, dass Ihr Workflow nicht mehr ausgeführt werden kann? Hat Ihr DevOps-Team die Möglichkeit, die Schwachstelle ohne seine Pipelines zu beheben[8]?
Angriffs-Vektoren
Indem Sie die Aktion aus dem Internet abrufen, führen Sie deren Code in Ihrer Umgebung aus: Das kann ein gehosteter Runner auf der Infrastruktur von GitHub sein oder Ihr eigener Runner in Ihrer eigenen Cloud-Umgebung.
Der Code in der Aktion kann mehrere Dinge tun: Er kann Ihre Daten, Ihren Code oder Ihre Umgebungseinstellungen (SSH-Schlüssel, lokal gespeicherte Zertifikate usw.) an einen eigenen Endpunkt senden und auf diese Weise Daten exfiltrieren. Sie können auch versuchen, Zugriff auf Ihre Umgebung oder Ihre GitHub-Einrichtung zu erhalten: entweder den Code im Repository selbst oder sogar versuchen, administrativen Zugriff auf das gesamte Repository zu erhalten. Sie könnten zusätzliche Abhängigkeiten in Ihren Code einbringen, andere Aktionen zu Ihrem Workflow hinzufügen oder sogar Ihre Aktionsläufe mit Bitcoin-Minern für ihren eigenen Vorteil missbrauchen.
Es gibt mehrere Möglichkeiten, sich Zugang zu verschaffen. Hin und wieder veranstaltet GitHub 'Capture The Flag' (CTF) Events, bei denen die Community eingeladen wird, ein Repository auszuprobieren und Zugang zu erhalten. Bei diesen Veranstaltungen erfahren sie viel über die Einrichtung und Möglichkeiten, die Sicherheit des Repositorys zu umgehen. Ein einfaches Beispiel für einen Angriffsvektor ist das Einsenden eines Pull Request, der die Workflow-Dateien selbst verändert, indem er eine bösartige Aktion einfügt. Raffiniertere Angriffe sind z.B. das Hinzufügen von JavaScript in den Issue-Kommentar, das vom Workflow abgefangen und nicht sicher behandelt wird: Das JavaScript wird dann ausgeführt, indem es z.B. in die Ausgabe protokolliert wird (hilfreich, um es in den Protokollen zu sehen), was es dem Angreifer wiederum ermöglicht, aus der Aktionsumgebung selbst auszubrechen und einen Prozess in der Runner-Umgebung auszuführen. Mit diesem Setup kann jemand einen neuen Pull Request für das Repository erstellen, der den nächsten Schritt des Angriffs einleitet, indem er Code in das Repository zurückschreibt. Aus den CTF-Ereignissen lernen wir die neuen Zugriffsmöglichkeiten kennen, und GitHub kann versuchen, diese Art von Angriffen zu verhindern.
Sichern Sie die von Ihnen ausgeführten Aktionen
Es gibt mehrere Maßnahmen, die Sie ergreifen können, um Ihre Aktionen zu sichern. Es ist keine gute Idee, einfach die neueste Version der Aktion zu verwenden: Neuer Code könnte unangenehme Nebeneffekte wie die Einführung neuer Sicherheitslücken haben, wie wir in den vorherigen Abschnitten gesehen haben. Das Repository der Aktion könnte sogar von einem neuen Betreuer mit bösen Absichten übernommen werden und Ihre Einrichtung dennoch gefährden. Deshalb ist es keine gute Idee, die Aktion (wie in jeder Demo angezeigt!) wie in diesem Beispiel auszuführen:
Option 1: Versions-Tags
Sie können die Versionsnummer der Aktion am Ende der Konfiguration hinzufügen, aber es gibt keine Möglichkeit zu überprüfen, ob es sich immer noch um denselben Code handelt: Der Tag kann mit neuen Codeänderungen wiederverwendet werden, so dass das Hinzufügen dieser Angabe keine wirkliche Sicherheit bietet.
verwendet docker/login-action@v1
Option 2: Beginnen Sie zumindest hier
Überprüfen Sie zunächst die Aktionen, die Sie ausführen, indem Sie in das Repository der Aktion schauen. Überprüfen Sie den Code im Repository auf seine Richtigkeit und fügen Sie ihn mit dem Commit SHA von GitHub am Ende Ihrer Aktionskonfiguration hinzu:
Der SHA der Übergabe ist unveränderlich: Wenn sich der Code im Repository ändert, wird der SHA anders sein. Dies ist der einzige sichere Weg, um sicher zu sein, dass der Code, den Sie ausführen, der Code ist, den Sie selbst überprüft haben und dass Sie die Risiken, die mit seiner Verwendung verbunden sind, akzeptiert haben.
Auf dem Laufenden bleiben
Jetzt, da wir die Aktionen so sicher wie möglich verwenden (indem wir überprüfen, was sie tatsächlich tun und sicherstellen, dass keine unbemerkten Änderungen hinzugefügt werden können), muss die nächste Frage beantwortet werden: Wie erhalten wir weiterhin Updates?
Da es auf dem Marktplatz keinen Update-Feed oder einen Blog gibt, dem man folgen kann, habe ich einen Twitter-Bot[9] erstellt, der regelmäßig nach neuen oder aktualisierten Aktionen sucht und diese dann twittert.
Die Überprüfung der verwendeten Aktionsversionen in Ihren Workflow-Dateien und deren automatische Aktualisierung können Sie mit Dependabot [10] durchführen: Es scannt Ihre Workflow-Dateien nach einem Zeitplan und erstellt einen Pull Request für jede aktualisierte Aktion. So haben Sie die Möglichkeit, die eingehenden Änderungen manuell zu überprüfen und dann den Pull Request zu akzeptieren.
Option 3: Forking des Aktions-Repositorys
Die ultimative Sicherheitseinrichtung, die ich gefunden habe, ist das Forking des Aktions-Repositorys an eine spezielle Organisation dafür. Diese Arbeitsweise wurde schon früher in der Dokumentation vorgeschlagen, hat sich aber nicht durchgesetzt.
Das Forking des Repositorys gibt Ihnen die volle Kontrolle über die Aktionen und ihre Aktualisierungen. Es bietet außerdem einen klaren Prüfpfad für die Aktionen und schützt Sie davor, dass Aktionen vom Betreuer abgezogen werden. Außerdem haben Sie ein Backup für den Fall, dass die Aktion vom Herausgeber gelöscht, umbenannt oder in ein anderes Repository verschoben wird. Erinnern Sie sich an die Verfügbarkeitsprobleme, die auftreten können? Auch das lässt sich so verhindern. Sie können nun Ihre anderen Organisationen (oder separaten Repositories) so absichern, dass nur Aktionen aus den geforketen Repositories ausgeführt werden können.
Dies ist auch eine ideale Strategie für Unternehmensorganisationen. Sie können eine spezielle Aktionen-Organisation erstellen, in der Sie alle Aktionen, die Sie benötigen, aufspalten. Dann sperren Sie die normale(n) Organisation(en), die jeder verwendet, so dass nur Aktionen aus der Aktionen-Organisation zugelassen werden. Die Einrichtung würde wie folgt aussehen:
Befähigen Sie Ihre DevOps-Ingenieure!
Sperren Sie Ihre DevOps-Ingenieure nicht aus: Es ist Teil der DevOps-Arbeitsweise, ihnen die Kontrolle über die von ihnen verwendeten Tools zu überlassen. Fügen Sie eine Organisation hinzu, in der die Mitarbeiter neue Aktionen zum Testen und Validieren ihrer Arbeitsabläufe heranziehen können, so dass sie auch neue Aktionen verwenden können, die Sie noch nicht geforkt haben. Sie übernehmen die Verantwortung für die Aktionen, die sie verwenden möchten, und forken die Aktionen selbst!
Auf diese Weise haben sie volle Autonomie und müssen nicht auf die Genehmigung von jemandem warten, bevor sie neue Aktionen oder Updates testen können.
Halten Sie Ihre Gabeln auf dem neuesten Stand
Nun, da Sie Ihre Organisation abgesichert und sichergestellt haben, dass Sie Ihre DevOps-Ingenieure nicht blockieren, indem Sie ihnen die Kontrolle über die Aktionen übertragen, brauchen Sie eine Möglichkeit, Ihre Forks (alle) zu aktualisieren. Um dies so einfach und dennoch sicher wie möglich zu machen, habe ich das GitHub Fork Updater Repository [11] erstellt: ein spezielles Repository, das alles enthält, was Sie brauchen. Forken Sie es, fügen Sie einige Konfigurationen hinzu, damit es alle Repositories in dieser Organisation aktualisieren kann, und schon sind Sie startklar!
Das Update funktioniert folgendermaßen:
- Prüfen Sie nach einem Zeitplan alle Repositorys in der Organisation des Forks mithilfe eines Workflows.
- Wenn es Aktualisierungen gibt, erstellen Sie einen Eintrag im fork-updater Repository.
- Mit der Standardeinstellung für GitHub-Benachrichtigungen werden Ihre Techniker über neue Issues benachrichtigt.
- Sie können die Ausgabe überprüfen und die Sicherheitsprüfung der eingehenden Änderungen über einen speziellen Link in der Ausgabe durchführen.
- Durch das Hinzufügen eines Labels zu der Ausgabe geben sie an, dass sie die eingehenden Änderungen überprüft haben und sie in das forked Repository ziehen wollen.
- Bei der Kennzeichnung der Ausgabe wird ein Workflow ausgelöst und der Fork wird aktualisiert.
- Das Thema ist abgeschlossen.
Zusammenfassung
Die Verwendung von GitHub-Aktionen aus dem Marktplatz ist standardmäßig nicht sicher: Es gibt keine wirklichen Prüfungen des Codes, den sie ausführen, und es liegt an Ihnen zu überprüfen, ob die Aktionen sicher sind.
Geben Sie Ihren DevOps-Ingenieuren die Möglichkeit, die Verantwortung für die Aktionen zu übernehmen, indem Sie die Repositories forken und eine Due-Diligence-Prüfung durchführen, um sicherzustellen, dass sie Ihre Daten nicht an einen unbekannten Dritten weitergeben. Dazu können Sie in Ihrem GitHub-Konto eine gesicherte Konfiguration mit zusätzlichen Organisationen einrichten und alle Aktionen, die Sie verwenden möchten, dort forken. Sie können die Aktualisierung Ihrer Forks so weit wie möglich automatisieren, indem Sie den GitHub Fork Updater nutzen, um über Änderungen auf dem Laufenden zu bleiben. Überprüfen Sie immer die eingehenden Änderungen!
Autor Rob Bos (Berater bei Xpirit).
[1]: github Aktionen
[2]: Using-github-hosted-runners über von github gehostete Läufer
[3]: Hosting Ihrer eigenen Läufer
[4]: Solorigate
[5]: 99 der Codes gehören nicht Ihnen
[6]: webappsec subresource integrity/
[8]: Sicherheit-Notfall-Zugang
[9]: github Aktionen
[10] Halten Sie Ihre Aktionen mit dependabot auf dem Laufenden
[11]: github-fork-updater
Verfasst von
Rob Bos
Rob has a strong focus on ALM and DevOps, automating manual tasks and helping teams deliver value to the end-user faster, using DevOps techniques. This is applied on anything Rob comes across, whether it’s an application, infrastructure, serverless or training environments. Additionally, Rob focuses on the management of production environments, including dashboarding, usage statistics for product owners and stakeholders, but also as part of the feedback loop to the developers. A lot of focus goes to GitHub and GitHub Actions, improving the security of applications and DevOps pipelines. Rob is a Trainer (Azure + GitHub), a Microsoft MVP and a LinkedIn Learning Instructor.
Contact