Einrichten eines internen GitHub-Aktionsmarktplatzes

Eine der besten Praktiken bei der Verwendung von GitHub Actions ist die alle Aktionen verzweigen die Sie für die Organisation Ihrer internen Aktionen verwenden möchten. Wenn Sie häufig organizationname-actions dafür, genau wie ich es für meine eigene persönliche Einrichtung hier tue: rajbos-Aktionen. Nach dem Forking der Repositories bekomme ich immer die Frage gestellt:

• Was nun?
• Wie gehen wir mit der internen Entdeckung um?
• Wie können wir einen Prozess einrichten, der unseren Ingenieuren die Kontrolle über die von uns verwendeten Maßnahmen gibt?
• Wie können wir all dies auf sichere Weise tun?
• Können wir diesen Prozess automatisieren? Wie kann ich mit dem übergeordneten Repository auf dem Laufenden bleiben?

Dieser Beitrag beschreibt meine Arbeitsweise und wie ich einen GitHub Actions Marketplace eingerichtet habe. Die Gründe für Forking sind reichlich, zum Beispiel:

• Übernehmen Sie die Kontrolle über die Aktionen als Backup für Ihre Produktionsorganisation (da sie vom Runner just-in-time heruntergeladen werden)
• Legen Sie einen formellen Moment in Ihrer Organisation fest, der das Ende der Sicherheitsprüfung des Quellcodes der Aktionen markiert (sehr wichtig!).
• Eine zentrale Stelle für alle Aktionen, die innerhalb Ihrer Produktionsorganisation verwendet werden können (lässt sich gut mit dem nächsten Punkt kombinieren)
• Sperren Sie Aktionen vom Marktplatz für die Verwendung in Ihrer Produktionsorganisation (siehe Punkt oben)

Möchten Sie mehr wissen? Sehen Sie sich eine frühere Benutzergruppensitzung zu diesem Thema an hier oder meine Sitzung 2021 auf GitHub Universe 2021! Nachdem wir den internen Marktplatz eingerichtet haben (siehe unten), auf dem die 'gesegneten' Aktionen gehostet werden, müssen wir auch verhindern, dass andere Aktionen in unserer Produktionsorganisation verwendet werden. Dies können Sie in den Einstellungen der Organisation festlegen:

Marktplatz für interne Aktionen

Der Grund für einen internen Marktplatz für Aktionen ist ein zentraler Ort für alle Aktionen, die innerhalb unserer Produktionsorganisation verwendet werden können. Damit soll verhindert werden, dass Aktionen vom öffentlichen Marktplatz in unserer Produktionsorganisation verwendet werden, ohne dass sie zuvor auf Sicherheitsrisiken geprüft wurden.

Leitlinien für die Organisation von Aktionen

1. DevOps-Ingenieure besitzen die Aktionen, wenn sie sie aufspalten
2. Vor Forking-Aktionen findet eine vollständige Sicherheitsüberprüfung statt
3. Anfragen zum Hinzufügen von Aktionen laufen über ein internes Repository, indem Sie Themen hinzufügen
4. Richten Sie einen internen Marktplatz ein, um die internen Aktionen zu entdecken
5. Erstellen Sie einen Kommunikationsplan für neue Aktionen, z.B. über eine Plattform für den Austausch von Informationen (Newsletter?)

Vollständiger Marktplatz-Prozess

Das Hinzufügen von Aktionen zum Marktplatz läuft folgendermaßen ab:

1. Benutzer findet eine Aktion auf dem Marktplatz
2. Anfrage über eine Ausgabe, um sie aufzunehmen
3. Manuelle Sicherheitsüberprüfung
4. Ausgabe wird beschriftet security-check
5. Sicherheitsüberprüfung der Ausgabe (Scannen des Quell-Repos)
6. Entscheiden Sie sich für das Risiko, die Aktion zu fälschen und sie zu verwenden
7. Absegnung durch das Sicherheitsteam [optional, kann im nächsten Schritt erledigt werden].
8. Ausgabe wird beschriftet security-approved
9. Fork it and own the maintenance
10. Korrekturen an das übergeordnete Repository weitergeben

Anfrage über eine Ausgabe, um sie aufzunehmen

Ich habe ein (Anfang eines) Beispielprojekts eingerichtet github-actions-requests die verwendet wird, um Aktionen anzufordern, die dem internen Marktplatz hinzugefügt werden sollen. Um dies zu tun:

• muss ein Benutzer ein Problem in einem speziell eingerichteten Repository erstellen und dabei die Aktion und den Grund für die Anfrage beschreiben. Es ist hilfreich, wenn sie bereits ein Beispiel-Repository haben, für das sie es verwenden möchten.
• ein DevOps-Ingenieur mit Sicherheitsbewusstsein und -hintergrund prüft das Repository für Aktionen und den Code (siehe weiter unten)
• nach der ersten und manuellen Prüfung kennzeichnet der Techniker das Problem mit security-check
• eine automatisierte Sicherheitsprüfung des Aktions-Repositorys, mit Kommunikation in der Ausgabe (z.B. Sicherheitsscores)

Manuelle Sicherheitsüberprüfung

Ein DevOps-Ingenieur kann das Repository für Aktionen auschecken und den Code überprüfen. Dies geschieht folgendermaßen:

• einen Blick auf die Einrichtung der Aktion werfen: Ist es JavaScript, Typescript oder ein Docker-Container?
• Tut die Aktion nur das, was sie tun soll?
• Liest die Aktion Dateien von der Festplatte außerhalb des Arbeitsordners? (z.B. Ihre ssh-Schlüssel)
• Liest die Aktion irgendwelche Umgebungsvariablen?
• was macht es mit all den Informationen, auf die es Zugriff hat? (z.B. sendet er sie an einen externen Endpunkt?)
• verwendet es die GitHub Token für irgendetwas? Wenn ja, ist es sicher?
• Unterstützt es den GitHub Enterprise Server (GHES), falls Sie ihn benötigen? (z.B. verwendet es die github.com Domain für irgendetwas, oder verwendet es die GITHUB_API_URL Umgebungsvariable?)

Sicherheitsprüfung

Für die Sicherheitsüberprüfung können Sie Ihre eigene interne Einrichtung verwenden. Sie benötigen etwas, das eine Analyse der Softwarezusammensetzung (SCA) Scan und erhalten dann Sicherheitswarnungen für alle Abhängigkeiten, die sie haben. Hierfür gibt es eine Vielzahl von Tools, zum Beispiel Schwarzente oder Weiße Quelle. GitHub hat bereits Dependabot verfügbar, die kostenlos in öffentlichen Repos verwendet werden können. Da es sich bei einem Fork bereits um ein öffentliches Repository handelt, können Sie es auch zum Scannen des Quellcodes von Aktionen verwenden. Für unsere endgültige Einrichtung möchte ich den Prozess so weit wie möglich automatisieren, daher werde ich ihn hier beschreiben. Nachdem die erste Validierung abgeschlossen ist und die internen Anforderungen erfüllt sind, möchte ich das Repository mit security-validation und führen Sie eine automatische Sicherheitsüberprüfung durch. Mehr dazu weiter unten, aber ich richte das auch in der Beispiel-Repo hier. Die Ergebnisse der Prüfungen werden der Ausgabe als Badges aus den verschiedenen Systemen hinzugefügt, mit Deep Links zu diesen Systemen, um die Analyse zu überprüfen. Dies kann dann für die endgültigen Prüfungen verwendet werden.

Dependabot

Für die Softwarekompositionsanalyse können wir Dependabot verwenden, um den Quellcode der Aktionen nach den von ihnen verwendeten Paketen zu durchsuchen. Sie können die Ergebnisse einer meiner Aktionen in den Repositories sehen Abhängigkeitsdiagramm: Hier finden Sie die direkten Abhängigkeiten (in diesem Fall von der packages.json Datei des Repositorys) und alle 'transienten' Abhängigkeiten. Eine transiente Abhängigkeit ist eine Abhängigkeit, die von einer Ihrer direkten Abhängigkeiten verwendet wird. Und da die vorübergehende Abhängigkeit ihre eigenen Abhängigkeiten haben kann... kann die Liste sehr lang werden. Aus diesem Grund haben Untersuchungen ergeben, dass 70 % des Codes, den Sie einsetzen, nie von Ihnen erstellt wurde, sondern über eine Abhängigkeit eingezogen wurde. Aus diesem Grund ist eine Software Composition Analysis (SCA) so wichtig, um Ihre Abhängigkeiten zu kennen und sie mit einer bekannten Schwachstellendatenbank abzugleichen, auch 'Common Vulnerabilities and Exposures' oder 'CVE' genannt. Einige Beispiele für diese Datenbanken sind die Nationale Datenbank für Schwachstellen von NIST oder die CVE-Datenbank von Mitre. GitHub hat sein eigenes GitHub Beratungsdatenbank mit vielen darin aufgeführten Sicherheitslücken:

Sicherheitshinweise

Nachdem Dependabot den Quellcode der Aktionen gescannt hat, weiß es, welche Abhängigkeiten verwendet werden. Als nächstes erstellt es eine Liste von Sicherheitshinweisen für die gefundenen Pakete. Es kann sogar Pull Requests für das Repository erstellen, um die verwundbaren Pakete auf eine nicht verwundbare Version zu aktualisieren. Da wir es hier auf einem öffentlichen Fork verwenden, nutzen wir es nicht selbst. Der Herausgeber der Aktion sollte es auf seiner Seite verwenden, um die gefundenen Probleme zu beheben. Sie können es natürlich auch auf Ihrer Abspaltung verwenden und dann einen Pull Request an das übergeordnete Projektarchiv senden, um die Probleme zu beheben, und den Herausgeber wissen lassen, dass er diese Funktionen ebenfalls nutzen kann. Bei dieser Konfiguration können wir die Ergebnisse des Dependabot-Scans verwenden, um zu überprüfen, ob wir die Aktion ohne große Sicherheitslücken in den verwendeten Paketen verwenden können.

CodeQL

CodeQL ist ein Tool, mit dem der Quellcode von Aktionen auf Schwachstellen untersucht werden kann und das in öffentlichen Repositories, wie unseren Forks, kostenlos verfügbar ist. Sie konfigurieren es als Arbeitsablauf, wie ich es getan habe hier. Für die Ausführung werden Aktionsminuten benötigt. Beachten Sie, dass das Programm standardmäßig das gesamte Repository durchsucht. In meinem Fall handelt es sich um eine Typescript-basierte Aktion. Das bedeutet, dass das Typescript in JavaScript umgewandelt und dann in das Repository hochgeladen wird. CodeQL scannt dann also alles. Das bedeutete, dass ich eine Ausgabe in moment.js durch das JavaScript im Repository. Wenn Sie nur den Typescript-Code überprüfen, finden Sie das natürlich nicht, da es nicht in diesem Teil des Codes enthalten ist. Der CodeQL-Workflow lädt seine Scan-Ergebnisse auf GitHub hoch, das Sie unter 'Sicherheit' und dann 'Code Scanning Alerts' finden: Sie können dann die aufgelisteten Schwachstellen überprüfen und die Empfehlung kontrollieren.

Hinweis: Es kann sehr schwierig sein, die Quelle der Code-Schwachstelle im JavaScript-Code zu finden. Transpilieren Sie Ihr Typescript mit dem inlineSourceMap Einstellung, um die Suche nach der eigentlichen Typescript-/Abhängigkeitsquelle zu erleichtern.

Scannen von Containern

Da die Aktionen auch als Container ausgeführt werden können, müssen wir auch diese Abhängigkeiten überprüfen. Das bedeutet, dass wir den Container von der Image-Einstellung in der action.yaml. Diese Einstellung kann auch auf eine Dockerdatei im Stammverzeichnis des Repositorys verweisen: Das Scannen der Container kann mit einem Programm wie Trivy oder Anchore.

Sicherheit genehmigt

Wenn Sie alle Sicherheitsprüfungen durchgeführt haben, können wir die Aktion formell genehmigen und sie in unsere eigene Aktionsorganisation auf GitHub aufnehmen. Kennzeichnen Sie das Problem als security-approved wird einen Arbeitsablauf auslösen, der:

• Verzweigt das Repository auf die Organisation organization-actions
• Aktualisiert die Ausgabe mit diesen Informationen
• Schließt die Ausgabe, da die Anfrage erfüllt wurde

Fork it and own the maintenance

Nun, da wir die Aktion geforkt haben, liegt es an uns, sie zu pflegen, sie mit den neuesten Änderungen aus dem übergeordneten Projektarchiv zu aktualisieren und eventuell auftretende Probleme zu beheben (und diese an das übergeordnete Projektarchiv zurückzuschicken!). Wie Sie alles mit den eingehenden Änderungen aus dem übergeordneten Projektarchiv auf dem neuesten Stand halten, habe ich bereits in einem früheren Blog beschrieben hier.

Hinweis: Wir benötigen auch einen Prozess, um neue Code-Scanning-Warnungen für das Repository zu verarbeiten, und eine Möglichkeit, den CodeQL-Workflow am Laufen zu halten, da er automatisch gestoppt wird, wenn 90 Tage lang keine neuen Code-Änderungen im Repository vorgenommen wurden. Dann müssen wir auch alle neuen Sicherheitswarnungen von CodeQL behandeln.

Interner Marktplatz

Jetzt, wo wir das alles eingerichtet haben, brauchen wir eine gute Möglichkeit, die Aktionen zu entdecken, die in unserer Aktionsorganisation verfügbar sind. Wir können die Standard-Übersichtsseite des Projektarchivs verwenden, aber das ist nicht sehr benutzerfreundlich. Wir möchten eine durchsuchbare Liste von Aktionen mit mehr Informationen als der Standardbeschreibung des Repositorys. Da es nichts Standardmäßiges gibt, habe ich selbst etwas entwickelt. Mit der Einrichtung von Aktionen-Marktplatz Ich habe einen Marktplatz für Aktionen erstellt: Sie können ihn aufspalten, konfigurieren und verwenden GitHub Seiten um Ihre Website zu hosten. Damit haben Ihre internen Benutzer einen zentralen Ort, um nach internen Aktionen zu suchen. Ich möchte dort auch Links zu den internen Workflows einfügen, die die Aktionen verwenden, damit Sie leicht Beispiele finden können. Für die Betreuer des Marketplace bietet dies auch eine Möglichkeit, die interne Nutzung der Aktionen zu verfolgen: Wenn die Aktion in keinem Workflow mehr verwendet wird, sollten Sie sie aus dem Marketplace entfernen, um Ihnen etwas Wartungsarbeit zu ersparen.

Einrichten des Marktplatzes

Das Marktplatz-Repositorium wurde mit drei Hauptkomponenten eingerichtet:

1. Erfassung der verfügbaren Aktions-Repositories in einer Organisation
2. Sammeln Sie die verwendeten Aktionen aus einer Organisation
3. Hosten Sie den Marktplatz mit GitHub Actions, um die Informationen aus den vorherigen Schritten anzuzeigen

Erfassung der verfügbaren Aktions-Repositories in einer Organisation

Die get-action-data.yml Workflow lädt alle Repositories einer Organisation, auf die er Zugriff hat, prüft das Stammverzeichnis auf ein action.yml oder action.yaml Datei und wertet sie nach Informationen aus. Das Ergebnis ist eine json-Datei, die im Ziel-Repository mit einem bestimmten Zweig namens gh-pages.

Sammeln Sie die verwendeten Aktionen aus einer Organisation

Die get-action-usages.yml Workflow lädt alle Repositories einer Organisation (kann eine andere sein als der andere Schritt), auf die er Zugriff hat, prüft das Verzeichnis des Workflows auf alle Dateien mit einer .yml Erweiterung und analysiert sie nach Informationen. Das Ergebnis ist eine json-Datei, die im Ziel-Repository mit einem bestimmten Zweig namens gh-pages.

Zusammenfassung

In diesem Beitrag habe ich Ihnen einen Weg aufgezeigt, wie Sie mit einem internen Marktplatz für GitHub-Aktionen beginnen können, um die Verantwortung für die Nutzung und Pflege der Aktionen zurückzuerhalten. Ich habe Ihnen auch gezeigt, wie Sie einige Sicherheitsprüfungen einbauen können und einige Beispiele für die Einrichtung all dessen. Haben Sie ein Feedback oder weitere Fragen zur Einrichtung? Bitte lassen Sie es mich wissen!

Anmerkung: Die github-actions-requests Beispiel-Repository, das ich gerade einrichte, führt derzeit nur die ersten Schritte aus. Ich bin noch dabei, den Rest des Workflows zu entwickeln.

Aktueller Status:

Derzeit ist die github-actions-request:

• wird durch die Kennzeichnung der Ausgabe ausgelöst
• sucht nach einer Verwendungsanweisung im letzten Kommentar der Ausgabe
• wenn es gefunden wird, wird das Repository auf die Organisation organization-actions geforkt (derzeit im Workflow fest einkodiert)
• fügt eine CodeQL-Workflow-Datei zum forked Repository hinzu

Da die Organisation 'organization-actions' so eingerichtet wurde, dass der Dependency Graph und die Dependabot-Warnungen aktiviert sind, brauche ich das im Workflow nicht zu tun. Ich brauche nur eine Möglichkeit (nach einer bestimmten Zeit) zu prüfen, ob es Alarme gibt, und diese in die Probleminformationen zu integrieren.