Sie denken also, Ihre CI/CD-Umgebung ist sicher?

In diesem gemeinsam von Weaveworks und Snyk verfassten Beitrag erfahren Sie, wie eine GitOps-Pipeline für Continuous Integration (CI) und Continuous Delivery (CD) in Kombination mit bewährten Sicherheitspraktiken die Sicherheit Ihres Entwicklungsworkflows für Kubernetes insgesamt verbessert.

Die typische CI/CD-Pipeline

Ihre CI/CD-Pipeline könnte dem unten dargestellten vereinfachten Modell sehr ähnlich sehen. Der Ablauf beginnt ganz links: Der Code befindet sich auf dem Rechner der Entwickler und wird in ein Code-Repository wie GitHub übertragen. Anschließend ruft ein CI-Tool den Code ab, führt Tests aus und erstellt ein Artefakt, beispielsweise ein Container-Image. Das Image wird in das Image-Repository übertragen und in einem Open-Source-Orchestrator wie Kubernetes oder einem vergleichbaren System bereitgestellt.

Oft wird jedoch nicht bedacht, ob das typische Push-Modell Ihrer CI/CD-Pipeline sicher ist. Stellen Sie sich dazu die folgenden zwei Fragen:

• Hat Ihre CI-Umgebung direkten Zugriff auf das Container-Image-Repository?

• Hat Ihre CI-Umgebung direkten Zugriff auf den Produktionscluster?

Sehen wir uns die Pipeline noch einmal an, diesmal mit Fokus darauf, welche Phasen jeweils Zugriff aufeinander haben. In der Abbildung steht RW für Lese- und Schreibzugriff und RO für Lesezugriff. Es gibt vermutlich deutlich mehr rote Linien, als Sie erwartet haben! Diese einfache Pipeline verstößt gegen einige der Sicherheitsprinzipien des Open Web Application Security Project (OWASP), darunter das Prinzip der geringsten Berechtigungen und die Aufgabentrennung. So hat beispielsweise der Entwickler Lese- und Schreibzugriff auf das Code-Repository und den Cluster.

Wenn Sie den direkten Zugriff von Entwicklern auf das Image-Repository und den Cluster entfernen, wird die Angriffsfläche verkleinert, der privilegierte Zugriff minimiert und die Aufgabentrennung sichergestellt.

GitOps kommt ins Spiel

GitOps ist eine Methode für Continuous Delivery von Cloud-Native-Anwendungen. Dabei dient Git als zentrale Quelle für deklarative Infrastruktur und Anwendungen. Delivery-Pipelines spielen Änderungen an Ihrer Infrastruktur automatisch aus, sobald Änderungen an Git vorgenommen werden. Doch die Idee geht noch weiter: Tools prüfen auch den tatsächlichen Produktionszustand und melden, wenn die Quelle nicht mit der Realität übereinstimmt.

Die GitOps-Methode begegnet unsicheren Pipelines, indem ein Abgleichoperator direkt im Cluster ausgeführt wird. Er arbeitet mit einem Git-Repository für Konfigurationen und verwendet dafür separate Anmeldedaten. Der Operator vergleicht den gewünschten Zustand, der in den Manifestdateien im Git-Repository beschrieben ist, mit dem tatsächlichen Zustand des Clusters und gleicht beide ab.

So gelangen keine Anmeldedaten über Sicherheitsgrenzen hinweg. Das CI-System kann in einer separaten Sicherheitszone statt auf dem Zielcluster ausgeführt werden. Jede Pipeline-Komponente benötigt nur ein einziges Anmeldeinformationenpaar mit Lese- und Schreibzugriff. Da die Cluster-Anmeldedaten den Cluster nie verlassen, können Sie Ihre Geheimnisse nun „nah bei sich behalten“.

Muss ich mir um Sicherheit jetzt keine Sorgen mehr machen?

Mit diesem Ansatz verringern Sie Sicherheitsrisiken, indem Sie Probleme wie Verstöße gegen das Prinzip der geringsten Berechtigungen und die Aufgabentrennung beseitigen. Damit sind natürlich nicht alle Sicherheitsbedenken ausgeräumt. Vielmehr wird dadurch noch wichtiger, auf gute Sicherheit in Ihrem Code-Repository zu achten.

GitSecOps kommt ins Spiel

Na gut – in unserer Branche gibt es schon genug Schlagwörter, da sollten wir nicht noch eins erfinden. Allerdings wird vieles von dem, was James Governor, alias @monkchips, sagt, früher oder später Realität. Danke für die Idee, James – wir hoffen, Ihnen gefällt der Blogbeitrag!

Hier sind einige Tipps, wie Sie Ihr Code-Repository besser absichern können.

Sicherheitstests zu Ihren PRs hinzufügen

Alle großen Code-Repositorys bieten leistungsstarke ereignisgesteuerte Hook-Frameworks, mit denen Sie bei bestimmten Ereignissen HTTP-POST-Anfragen an einen Dienst Ihrer Wahl senden können. Es gibt zahlreiche Ereignisse, auf die Sie reagieren können. Eines der nützlichsten zum Testen inkrementeller Codeänderungen ist das Ereignis pull_request.

Viele Tools zur statischen Codeanalyse unterstützen Hooks. Wird ein PR erstellt, löst ein HTTP-POST eine Prüfung Ihrer neuesten Änderungen aus. Das ist auch ein guter Zeitpunkt, um sicherzustellen, dass Code- und Konfigurationsänderungen Ihren Sicherheitsanforderungen entsprechen.

Ihr Repository mit Snyk statisch analysieren

Snyk analysiert Ihr Repository statisch, um anfällige Abhängigkeiten zu finden, die Sie möglicherweise verwenden, und unterstützt Sie dabei, diese zu beheben. Sie können Ihre Repositorys über die Snyk-Benutzeroberfläche auf Probleme testen. Außerdem können Sie verhindern, dass Nutzer neue anfällige Bibliotheken hinzufügen: Testen Sie Pull Requests und lassen Sie einen Test fehlschlagen, wenn dadurch eine neue Sicherheitslücke eingeführt wird.

Neben der praktischen Integration in GitHub, GitLab und Bitbucket haben Pull Requests gegenüber einem „Build-Abbruch“ weitere Vorteile. Sie müssen einen Merge nicht einmal blockieren, da sie standardmäßig lediglich Informationen bereitstellen. Die Tests konzentrieren sich ausschließlich auf Ihre Änderungen und nicht auf das Gesamtergebnis. Sie schlagen nur fehl, wenn Sie eine anfällige Bibliothek eingeführt haben – nicht, wenn diese bereits zuvor vorhanden war.

Anmeldedaten niemals im Code oder in Konfigurationsdateien speichern

Eine kurze Suche auf GitHub zeigt, wie weit verbreitet das Problem gespeicherter Passwörter in Repositorys tatsächlich ist. Die 350.000 Commits, die bei dieser einfachen Suche gefunden wurden, berücksichtigen weder Fälle, die anhand der Commit-Nachrichten nicht so leicht erkennbar waren, noch diejenigen, bei denen versucht wurde, die Spuren durch das Entfernen der Historie zu verwischen.

Sie können auch Tools wie git-secrets verwenden, um Builds automatisch abzubrechen, wenn vertrauliche Informationen in Code oder einer Konfigurationsdatei gefunden werden. Teamweite Regeln, die solche Fälle verhindern, sind eine gute Möglichkeit, Fehlverhalten im bestehenden Entwicklerworkflow zu unterbinden.

Es gibt viele Möglichkeiten, Anmeldedaten gar nicht erst in Ihr Repository aufzunehmen. Sie sollten möglichst viele davon umsetzen. Doch selbst dann können vertrauliche Informationen durchsickern. Ziehen Sie außerdem regelmäßige Audits Ihrer Repositorys in Betracht und nutzen Sie Tools wie GitRob oder truffleHog. Beide durchsuchen Ihre Codebasis mithilfe von Mustererkennung nach vertraulichen Informationen.

Wenn Sie feststellen, dass Sie vertrauliche Daten in Ihrem Code-Repository gespeichert haben, müssen Sie mehrere Schritte unternehmen, um den Schaden zu beheben:

1. Sie müssen die Tokens und Passwörter, die öffentlich zugänglich waren, ungültig machen.

2. Sobald ein Geheimnis im Internet öffentlich zugänglich ist, sollten Sie davon ausgehen, dass Angreifer es in die Hände bekommen haben, und entsprechend reagieren.

3. Entfernen Sie sämtliche Spuren Ihrer Geheimnisse, damit sie weder im Code noch im Audit-Trail zurückbleiben.

Zugriff streng kontrollieren

Schreiben Sie für Ihre Mitwirkenden die folgenden grundlegenden Praktiken vor:

• Verlangen Sie für alle GitHub-Konten von Mitwirkenden eine Zwei-Faktor-Authentifizierung.

• Lassen Sie Nutzer niemals Konten oder Passwörter gemeinsam verwenden.

• Sichern Sie alle Laptops und Geräte mit Zugriff auf Ihren Quellcode angemessen ab.

• Konten sind oft persönlicher Art und werden nicht automatisch deaktiviert, wenn Nutzer das Unternehmen verlassen. Entziehen Sie daher sorgfältig allen Nutzern den Zugriff, die nicht mehr mit Ihnen zusammenarbeiten.

• Repository-Administratoren sollten den Teamzugriff auf Daten verwalten. Gewähren Sie Mitwirkenden nur Zugriff auf die Daten, die sie für ihre Arbeit benötigen.

Eine SECURITY.md-Datei hinzufügen

Für die meisten Projektverantwortlichen und Maintainer ist es selbstverständlich, ihrem Repository eine README.md hinzuzufügen. Heutzutage wird ein fehlendes README sogar oft kritisch gesehen. Ebenso verbreitet sich die Praxis, eine SECURITY.md-Datei mit sicherheitsrelevanten Informationen zum Projekt hinzuzufügen. Eine solche Datei stellt Nutzern wichtige Sicherheitsinformationen zur Verfügung und regt Maintainer dazu an, sich mit dem Umgang mit Sicherheitsmeldungen, Updates und allgemeinen Sicherheitspraktiken auseinanderzusetzen. Gute Beispiele für SECURITY.md-Dateien finden Sie in den Repositorys von Apache Storm und TensorFlow.

Zusammenfassung

Ihr CI-Server kann die Entwicklung mit Zusammenführen in den Hauptzweig, Build und Tests problemlos orchestrieren. Wenn CI-Server jedoch Continuous-Delivery-Vorgänge übernehmen, kommen weitere Sicherheitsaspekte hinzu. GitOps nutzt Kubernetes oder den Cluster, um Bereitstellungen anhand von Aktualisierungen des Hauptzweigs intern zu verwalten. Dieses Vorgehen wird auch als „Pull-Modell für CD“ bezeichnet.

Git ist die zentrale Quelle der Wahrheit für den Code sowie die Konfiguration und den zugehörigen Stack. Dadurch rückt es stärker in den Fokus der Sicherheit. Allgemeine Best Practices für Ihr Code-Repository können dabei helfen – zum Beispiel, bei jedem Pull Request automatisch Testtools wie Snyk einzusetzen, eine SECURITY.MD-Datei mit etablierten Sicherheitsverfahren anzulegen und Geheimnisse in Tresoren statt im Code zu speichern.

Möchten Sie Ihre Git-Workflows oder CI/CD-Pipelines um Sicherheit ergänzen? Testen Sie Snyk kostenlos! Sie können außerdem eine private Demo buchen, um Snyk in Aktion zu erleben.