Secure GitOps Pipelines selbstgebaut

Bei einem Kunden haben wir ein Stagingsystem aufgesetzt, was in der Azure Cloud ein AKS-Cluster bereitstellt, um verschiedene Featurebranches parallel testen zu können und, in einer weiteren Iteration, A/B testing zu ermöglichen. Wir haben die benötigte Infrastruktur mit Terraform abgebildet weil dies uns einige Vorteile verschafft:

• Die Umgebung kann nachts oder am Wochenende heruntergefahren werden und durch die Pipeline neu erstellt werden, um Kosten zu sparen.
• Eine gleiche Umgebung, zum Beispiel eine Produktionsumgebung, kann ohne großen Aufwand parallel erzeugt werden.
• Probleme durch manuelle Konfiguration und „zusammenklicken“ werden ausgeschlossen.

Dabei werden durch Terraform alle notwendigen, sicherheitsrelevanten Komponenten generiert, zum Beispiel Datenbankpasswörter und Zertifikate und natürlich das Kubernetes Cluster.

Doch wie finden nun all diese Variablen den Weg zurück in die Pipelines derer Services, die eigentlich auf dem Cluster deployed werden sollen? Und das auch noch geschützt vor neugierigen Augen?

GitOps ist das Stichwort. In der Pipeline zur Clustererstellung läuft folgendes Script

TL;DR

Das Skript klont die angegebenen Repositories, ersetzt die Werte in den JSON Dateien durch die aktuellen Werte (Zeile 76, 4) und eröffnet über die git push options ein Merge Request in den entsprechenden App-Repositories.

TC;DU

too complicated, didn’t understand

Da es sich um sicherheitsrelevante Daten handelt, haben wir die entsprechenden Dateien mit sops

Im Gegensatz zu GitCrypt bietet es uns die Möglichkeit, nur die Werte zu verschlüsseln, anstatt die komplette Datei. Somit sind Änderungen einfacher sichtbar.

GitLab unterstützt diverse git push options, mit denen nicht nur Merge Requests erstellt sondern auch mit mergerequest.mergewhenpipelinesucceeds automatisch akzeptiert werden können, sobald die Pipeline erfolgreich durchgelaufen ist. Hier finden sich alle Optionen, die beim Skripting nützlich sein können.

Diese Pipelines sollten optimalerweise einen Smoketest machen, um herauszufinden, ob die neue Konfiguration geeignet ist, damit daraufhin alles weitere auf dem neuen Cluster deployed werden kann.

Hier ein Beispiel mit Sonobuoy

Disclaimer

Dies ist ein Ansatz mit wenig overhead, der sich möglicherweise nicht für jeden Usecase eignet. Eine Alternative könnte die Nutzung von Hashicorp Vault sein. Vault kümmert sich darum, sensitive Daten zu verwalten und kann sogar Secrets dynamisch in einen Kubernetes Pod einfügen. Hier ein Blogpost dazu.

Um auch weitere Cross-Repository Aufgaben mit GitLab zu erledigen, empfehlen wir euch noch diesen Blogpost.

Auch lässt sich sops direkt mit Terraform nutzen.