Erstellen und sichern Sie Container zur Unterstützung Ihrer CI/CD-Pipeline

In jedem Unternehmen gibt es 2 Systeme, die kritisch sind: das Gehaltsabrechnungssystem und das CI/CD-System. Und warum? Das fragen Sie sich vielleicht... Wenn das Gehaltsabrechnungssystem nicht funktioniert, verlassen die Leute das Unternehmen und das Unternehmen bekommt (möglicherweise) rechtliche Probleme; das CI/CD-System ist das Tor zur Produktion. Wenn es nicht funktioniert und ein Fehler in der Produktion auftritt, wirkt sich das auf Ihr Geschäft aus: Umsatzverluste, Kundenverluste, Geldverluste, um nur einige Beispiele zu nennen. Normalerweise finde ich diese Probleme im Zusammenhang mit dem CI/CD-Tooling:

• Schlechtes Software Lifecycle Management, mit veralteter Software, die kritische Schwachstellen enthält
• Alte Funktionen in den Build-Agenten. Im Extremfall Frameworks und Tools, die von den Anbietern nicht mehr unterstützt werden
• Abdriftende Agenten. Das bedeutet, dass die Teams etwas zaubern mussten, um die Software zu erstellen
• Fehlende ordnungsgemäße Isolierung zwischen verschiedenen Builds. Das bedeutet, dass ein Build auf die Dateien eines anderen Builds zugreifen kann.
• Teams bei der Aktualisierung oder Installation eines neuen Frameworks leiten
• Überholte und strenge Regeln, die von einem Betriebsteam vorgegeben werden. Normalerweise von Leuten, die veraltete Heuristiken darüber haben, wie Software entwickelt werden sollte.

Um diese Probleme zu lösen, empfehle ich in der Regel den Einsatz einer SaaS-Lösung, bei der die Verantwortung für die Wartung und Sicherung des Tools auf den Anbieter übertragen wird. Außerdem empfehle ich die Auswahl eines Tools, das Container unterstützt, in denen die Software erstellt wird. Damit können mehrere Probleme gelöst werden, z. B. die Isolierung und die Verkürzung der Vorlaufzeit für die Bereitstellung neuer Funktionen. Außerdem können Teams so ihre eigenen Container erstellen und die Verantwortung des Plattformteams auf die Entwicklungsteams verlagern. Durch die Verwendung von Containern als Recheneinheit sind granulare Fähigkeiten möglich (im Vergleich zu den typischen voll geflaggten Maschinen), so dass eine sauberere Umgebung auf der Grundlage spezifischer Anforderungen entsteht. Ein zusätzlicher Vorteil ist, dass das Plattformteam nicht mehr eingeschränkt ist, da die Entwicklungsteams keine neuen Fähigkeiten für die Build/Deploy-Agenten anfordern müssen. Das Plattformteam ist für einen Dienst verantwortlich, der dem Unternehmen zur Verfügung gestellt wird, und dieser Dienst muss stabil und sicher sein. Es ist ein Paradigmenwechsel und eine neue Denkweise für das typische Betriebsteam, das zu einem Plattformteam werden kann, das den Entwicklern hervorragende Dienste anbietet.

Alle Kästchen sind angekreuzt! Oder auch nicht...

Die entscheidende Änderung ist die Verlagerung der Verantwortlichkeiten vom Plattformteam auf die Entwicklungsteams. Nun, das schreit nach einer großartigen Lebensweisheit von Ben Parker:

Mit großer Macht kommt auch große Verantwortung! Ben Parker, Spider-Man

Wenn man den Teams erlaubt, ihre eigenen Container zu bauen, wer garantiert dann die Sicherheit der Container? Obwohl es einige Vorteile bietet, entstanden neue Herausforderungen...

Es sind 0en und 1en

Das Plattformteam, das den Dienst anbietet, ist in der perfekten Position, um eine Pipeline zu implementieren (Dogfooding), in der die Container getestet und auf Schwachstellen untersucht werden. Wenn alle Tests bestanden sind, wird das Container-Image in der Container-Registry gespeichert und kontinuierlich überwacht. Da CVEs jederzeit veröffentlicht werden können, werden diese Images ständig überwacht. Mit diesem Ansatz hat das Plattformteam die Kontrolle über die CI/CD-Umgebung und ist flexibel genug für die Entwicklungsteams, um schnell Werte zu liefern. Am Ende geht es um 0 und 1. Auch bekannt als Infrastructure as Code, und wie jedes Stück Code sollte es erstellt, getestet, in einem zentralen Artefaktspeicher gespeichert und bereitgestellt werden.

Rekapitulation (oder das eine Bild, das alles erklärt)

Die Welt in einem Bild erklären Zusammenfassend lässt sich die Pipeline durch das vorherige Bild beschreiben. Der Code befindet sich in einem Git-Repository und ein Build-Agent verwendet ein Image aus der Container-Registry, um die Pipeline zu starten. Sobald die Pipeline gestartet ist, erstellt sie den Code (in diesem Fall ein weiteres Container-Image), testet und scannt ihn. Wenn alles in Ordnung ist, wird das neue Image in die Container-Registrierung übertragen. All dies geschieht unter Verwendung der typischen trunkbasierten Entwicklung mit Pull Requests zur Durchsetzung des 4-Augen-Prinzips (Rückverfolgbarkeit für Audit-Zwecke).

Erstaunlich, ein weiteres Architekturdiagramm... Und die Implementierung?

Eine mögliche Implementierung kann auf diesem Open-Source-Projekt beruhen. Es verwendet kostenlose Tools für Open-Source-Projekte, aber es gibt auch andere Alternativen. Die Implementierung ist einfach und verwendet die folgenden Tools:

• GitHub als Git-Repository
• Azure DevOps als CI/CD-Server
• Dockerfile mit einer Beschreibung der Schritte zur Erstellung des Container-Images
• Google Container Structure Tests als Test-Framework
• Snyk als Tool zum Scannen und Überwachen

Die Entscheidungen für die Werkzeuge waren:

• Verwenden Sie ein Testframework, das sprachunabhängig ist. Heutzutage verwenden einige Test-Frameworks YAML, um die Erwartungen an das Artefakt zu beschreiben. Im Vergleich zu einem sprachbasierten Test-Framework ist dies leicht zu erlernen. Das ist wichtig für Organisationen, in denen es mehrere Programmiersprachen gibt
• Ein Scan-Tool, das auch die Artefakte überwachen kann. Angesichts der Art der Offenlegung der CVEs ist es wichtig, ein Tool zu haben, das alle neuen Erkenntnisse automatisiert und meldet.

Wenn Sie sich die Implementierung genauer ansehen, können Sie sie in Aktion sehen:

• Tests schlagen fehl, TDD auf ganzer Linie (commit b6b0a6c): dev.azure.com/joaoasrosa/
• Scan fehlgeschlagen (Commit b92b058): dev.azure.com/joaoasrosa/
• Überwachung ist vorhanden:

Berichtsüberwachung ab 2019/01/24

Zusammenfassend lässt sich sagen...

Die Implementierung ermöglicht es den Entwicklungsteams, ihre eigenen Container zu erstellen, die in den Build-Umgebungen verwendet werden, ohne andere Teams zu behindern. Außerdem kann das Plattformteam die Kontrolle ausüben, ohne die Entwicklungsteams einzuschränken, und die "heiligen Regeln" der "Plattform" diktieren. Es bietet jedoch das richtige Maß an Sicherheitskontrollen, da alles automatisiert ist, PR's durchgesetzt werden und es möglich ist, genau zu wissen, was und wann es verwendet wurde. Das macht das Leben der Prüfer einfacher und schafft eine sicherere Umgebung! Wenn Sie alternative Implementierungen oder Ideen haben, können Sie sich gerne melden! Diese Implementierung verwendet einige Tools, und vielleicht haben Sie bessere Alternativen. Ich würde sie gerne diskutieren!

Fußnote: Dieser Blogbeitrag steht auch in meinem persönlichen Blog.