Let’s Deploy with ayedo, Teil 1: GitLab CI/CD, Harbor Registry, Vault Secrets

TL;DR

• GitLab CI/CD wird zum zentralen Orchestrator Ihres Delivery-Workflows: klar strukturierte Stages (build, test, package, deploy) machen Ihre Artefaktkette nachvollziehbar und prüfbar.
• Rootless, daemonlose Container-Builds mit Kaniko oder Buildah ermöglichen sichere Pipelines ohne privilegierte Docker-Daemons – inklusive SBOM-Generierung als Grundlage für Auditierbarkeit und kommenden Vorgaben aus NIS2 und Cyber Resilience Act (in Kraft seit dem 09.01.2024).
• Eine zentrale Registry wie Harbor wird vom simplen Image-Speicher zum Compliance-Drehkreuz: automatisches CVE-Scanning, Image-Signing und durchgesetzte Vulnerability-Policies erhöhen Ihre Supply-Chain-Sicherheit messbar.
• Mit HashiCorp Vault und dem External Secrets Operator automatisieren Sie das Secrets-Management von der Pipeline bis zum /kubernetes/-Cluster – inklusive dynamischer Credentials und Rotation, ohne Secrets in GitLab-Variablen zu „verstecken“.
• ayedo liefert eine integrierte Plattform mit GitLab, Harbor, HashiCorp Vault und ESO sowie praxiserprobte GitLab CI/CD-Templates, die genau diesen Workflow für Sie vorstrukturieren.

---

GitLab CI/CD als Rückgrat des Deployment-Workflows

Für moderne, regulierungskonforme Softwarelieferung ist eine saubere CI/CD-Pipeline nicht „nice to have“, sondern das technische Organigramm Ihrer Organisation. In vielen Unternehmen übernimmt GitLab diese Rolle – in der ayedo Plattform ist es der erste Schritt im End-to-End-Workflow.

Repository-Setup mit Blick auf Compliance

Ein Application-Repository sollte die spätere Automatisierung bereits widerspiegeln:

• Applikationscode (z. B. src/ für eine Django-App)
• Tests (Unit, Integrations- und, wo sinnvoll, Security-Tests)
• Dockerfile für den Container-Build
• Chart-Verzeichnis für das spätere Packaging in Helm/ohMyHelm
• Eine .gitlab-ci.yml, die den gesamten Lebenszyklus der Anwendung abbildet

Wichtig ist dabei weniger die exakte Ordnerstruktur als die klare Trennung von Verantwortlichkeiten: Code, Infrastruktur-Definition und Delivery-Logik bleiben unterscheidbar. Das erleichtert Audits und reduziert das Risiko von „versteckten“ Konfigurationen.

Stages: build, test, package, deploy – bewusst getrennt

Eine typische Pipeline für eine Django-Anwendung lässt sich in vier Hauptstages gliedern:

• test: Qualitätssicherung
• build: Container-Image bauen und signieren
• package: Applikation paketieren (z. B. Helm-Chart mit referenzierter Image-Version)
• deploy: Übergabe an das Deployment-System (in Teil 1 noch bis Harbor; ArgoCD folgt in Teil 2)

Diese Trennung schafft Transparenz: Ein Auditor oder ein neuer Teamlead erkennt auf einen Blick, an welcher Stelle Tests stattfinden, wann Images unveränderlich werden und wo Sicherheitsprüfungen greifen.

Darüber hinaus lassen sich Genehmigungsprozesse entlang dieser Stages einziehen: etwa, dass nur auf dem main-Branch vollständige Pipelines bis einschließlich package und deploy laufen, während Feature-Branches auf test und eventuell build begrenzt sind. So verbinden Sie Entwicklerproduktivität mit klaren Kontrollpunkten.

---

Sichere Container-Builds: Kaniko vs. Buildah, Dockerfile-Disziplin und SBOM

Die Zeiten, in denen ein privilegierter Docker-Daemon im CI-Runner lief, sollten vorbei sein – nicht nur aus Sicherheitsgründen, sondern auch, weil viele Compliance-Rahmenwerke den Betrieb privilegierter Services in Shared-Umgebungen kritisch sehen.

Rootless, daemonless: Warum Kaniko oder Buildah?

Sowohl Kaniko als auch Buildah sind darauf ausgelegt, Container-Images ohne laufenden Docker-Daemon und ohne Root-Rechte im Container zu bauen:

• Kaniko

  • Speziell für Container-Plattformen entwickelt, ideal für Runner auf /kubernetes/.
  • Nutzt die Registry für Caching und arbeitet direkt auf dem Dateisystem.
  • Sehr gute Integration in GitLab CI/CD, schlank und stabil.

• Buildah

  • Bietet eine sehr mächtige CLI und unterstützt komplexe Build-Szenarien.
  • Kann Dockerfile-basiert oder skriptbasiert genutzt werden.
  • Gut, wenn Sie bereits Podman/Buildah im Unternehmen etabliert haben.

Beide Ansätze reduzieren die Angriffsfläche Ihrer Runner erheblich. Das ist besonders relevant, wenn Sie perspektivisch den Anforderungen von NIS2 (mit Wirkung ab dem 18.10.2024) entsprechen wollen, wo sichere Betriebsprozesse und Risikominimierung explizit gefordert sind.

Dockerfile Best Practices als Compliance-Baustein

Ein sicheres Image beginnt nicht beim Scanner, sondern im Dockerfile. Für eine Django-Anwendung haben sich unter anderem folgende Prinzipien bewährt:

• Minimalistische Basis-Images (z. B. distroless, Slim-Varianten) statt voll ausgestatteter Distributionen
• Multi-Stage-Builds, um Build-Dependencies aus dem finalen Laufzeit-Image herauszuhalten
• Nicht-root-User im Container, konsequent eingesetzt
• Explizite Versions-Pins für Betriebssystem-Pakete und Python-Dependencies
• Reproduzierbarkeit: deterministische Builds, bei denen ein Commit immer dasselbe Image erzeugt

Diese Muster sind keine stilistische Frage, sondern erleichtern die Sicherheitsbewertung erheblich: Weniger Pakete bedeuten weniger potenzielle CVEs, und klare Versionsangaben machen es einfacher, auf advisories und Scans zu reagieren.

SBOM-Generierung: Lieferkette sichtbar machen

Ein weiterer Baustein in Richtung regulierungskonformer Lieferkette ist die Software Bill of Materials (SBOM). Sie beschreibt, welche Komponenten (z. B. Python-Packages, Systembibliotheken) in einem Image enthalten sind.

In der Pipeline sollte der SBOM-Schritt eng mit dem Container-Build verzahnt sein:

• SBOM-Erzeugung direkt aus dem finalen Image
• Nutzung etablierter Formate wie CycloneDX oder SPDX
• Ablage des SBOM als Artefakt sowie idealerweise als Anhang im Registry-Metadatenmodell

Damit schaffen Sie eine Grundlage, um auf zukünftige regulatorische Anforderungen zu reagieren – etwa, wenn Kunden oder Aufsichtsbehörden im Rahmen des Cyber Resilience Act detaillierte Auskünfte zur Komponentenliste Ihrer Software haben möchten.

---

Harbor Registry: Vom Image-Speicher zum Sicherheits-Gateway

Eine moderne Registry wie Harbor ist deutlich mehr als ein Ort, an dem latest-Tags „geparkt“ werden. In einer gut gestalteten CI/CD-Landschaft wird Harbor zum Security- und Compliance-Gateway zwischen Build und Deployment.

Image-Push als expliziter Übergabepunkt

Im Build-Stage der Pipeline wird das Image mit Kaniko oder Buildah erzeugt und anschließend in ein dediziertes Projekt in Harbor gepusht. Üblicherweise entsteht dabei mindestens ein unveränderlicher Tag (z. B. Commit-Hash oder Build-Nummer) und optional ein „beweglicher“ Tag wie latest.

Dieser Push ist ein klarer Übergabepunkt: Vorher ist das Image ein temporäres Ergebnis eines Builds, danach ein versioniertes Artefakt, das von Produktionssystemen genutzt werden darf – allerdings erst, wenn es die definierten Kontrollen in Harbor bestanden hat.

Automatisches CVE-Scanning und Policies

Harbor integriert Schwachstellenscanner und führt nach jedem Push automatisch ein Image-Scanning durch. Für eine Django-App, die auf einem Python- oder Debian/Ubuntu-Base-Image aufsetzt, werden damit sowohl OS-Pakete als auch Laufzeitbibliotheken erfasst.

Die entscheidende Stärke liegt in den Policies:

• Sie definieren, welche Schweregrade (z. B. „High“ und „Critical“) toleriert werden.
• Sie können festlegen, dass Images mit bestimmten Schwachstellen nicht gepullt oder nicht in „Production“-Projekten promoted werden dürfen.
• Sie können ein Modell etablieren, in dem bekannte, aber noch nicht behebbare Schwachstellen gezielt akzeptiert und dokumentiert werden (z. B. über Allow-Listen mit Begründung und Zeitlimit).

So bauen Sie eine Brücke zwischen Security-Team und Delivery-Teams: Nicht jedes Finding blockiert sofort die Pipeline, aber nichts geht stillschweigend durch.

Image Signing als Supply-Chain-Guardrail

Neben dem Scanning gewinnt Image Signing stark an Bedeutung. Harbor unterstützt moderne Signaturmechanismen (z. B. Notary v2, cosign) und kann Signaturen als Voraussetzung für bestimmte Aktionen erzwingen.

Ein praxisnahes Modell:

• Das Build-Stage signiert jedes erfolgreich gebaute Image mit einem technischen Key.
• Harbor akzeptiert Pulls in sensible Zielprojekte nur für signierte Images.
• Später im Workflow (in ArgoCD, Teil 2 der Reihe) werden nur signierte Images deployed.

Damit schaffen Sie eine kryptographisch abgesicherte Kette: Nur Images, die tatsächlich aus Ihrer GitLab-Pipeline stammen, erreichen die Produktionscluster. Das ist ein zentraler Baustein, um Supply-Chain-Angriffe wie das Einbringen fremder Images wirksam zu erschweren.

---

Secrets-Management mit HashiCorp Vault und ESO: Vorbereitung für den Betrieb

Auch wenn dieser erste Teil der Reihe beim Push nach Harbor endet, gehört das Thema Secrets schon in diesen Abschnitt – sonst landen Zugangsdaten unnötig in GitLab-Variablen oder sogar in Repositories.

Vault als zentrale Instanz für Credentials

HashiCorp Vault dient in der ayedo Plattform als zentrale Drehscheibe für:

• Datenbank-Credentials (z. B. PostgreSQL für die Django-App)
• API-Tokens, Zertifikate und TLS-Material
• Kurzlebige Zugangsdaten für Builds (z. B. Authentifizierung gegenüber Harbor)

Statt feste Benutzername/Passwort-Paare in GitLab zu hinterlegen, bezieht die Pipeline kurzlebige Tokens oder dynamic credentials aus Vault. Das reduziert das Risiko geleakter Secrets erheblich und erfüllt gleichzeitig gängige Vorgaben zu Least Privilege und Rotation.

ESO: Automatischer Sync in den Kubernetes-Cluster

Der External Secrets Operator ist das Bindeglied zwischen Vault und Ihrem /kubernetes/-Cluster. Er synchronisiert Secrets aus Vault automatisiert in native Kubernetes-Secrets, die dann von Deployments genutzt werden können.

Auch wenn der eigentliche Rollout in dieser Artikelserie erst im zweiten Teil mit ArgoCD behandelt wird, sollten Sie bereits jetzt sicherstellen:

• Alle laufzeitkritischen Secrets der Django-App liegen in Vault, nicht in GitLab.
• ESO-Konfigurationen sind vorbereitet, sodass beim ersten Deployment keine manuellen „Secret-YAMLs“ erforderlich sind.
• Die Rollen- und Rechte-Modelle in Vault sind abgestimmt: Entwickler, CI/CD und Plattform-Teams haben genau die Rechte, die sie benötigen – nicht mehr und nicht weniger.

So entsteht eine Lieferkette, in der Artefakte (Images, Charts) und Konfiguration (Secrets) klar getrennt, aber technisch sauber integriert sind.

---

Praktisches Pipeline-Design für eine Django-Anwendung

Wie sieht das nun konkret – aber ohne YAML – für eine Django-App aus?

Stage „test“: Qualität und Basis-Sicherheit

In der Test-Stage laufen typischerweise:

• Installation der Python-Dependencies aus definierten Requirements-Dateien
• Django-Testsuite mit Unit- und Integrations-Tests gegen eine temporäre Datenbank
• Linting (z. B. mit flake8, isort, black – im Check-Modus)
• Optional erste SAST- oder Dependency-Checks

Wichtig ist, dass diese Stage auf allen relevanten Branches läuft und schnell genug bleibt, um Entwicklerfeedback nicht zu bremsen.

Stage „build“: Image, SBOM, Signatur

Die Build-Stage übernimmt:

• Container-Build mit Kaniko oder Buildah anhand des Dockerfiles
• Tagging mit einer unverwechselbaren Build-ID (z. B. Commit-Hash und Pipeline-ID)
• Erzeugung eines SBOM für das fertige Image
• Signierung des Images mit einem technischen Schlüssel
• Push in ein dediziertes Harbor-Projekt für Builds

Am Ende dieser Stage existiert ein eindeutig identifizierbares, signiertes und mit SBOM versehenes Image in Harbor – die Grundlage für jede weitere Nutzung.

Stage „package“: Applikation als deploybares Artefakt

Für Django-Anwendungen, die über Helm/ohMyHelm deployt werden, übernimmt die Package-Stage:

• Aktualisierung der Chart-Metadaten (Version, appVersion) entsprechend dem Image-Tag
• Erstellung eines Chart-Pakets, das genau auf das in Harbor liegende Image zeigt
• Optional: Push des Charts als OCI-Artefakt in Harbor

Damit entsteht ein zweites, höherstufiges Artefakt: das Anwendungs-Paket, das im nächsten Schritt von ArgoCD konsumiert werden kann.

Stage „deploy“ (Teil 1): Übergabe statt Cluster-Rollout

Im ersten Teil unseres Workflows verstehen wir „deploy“ bewusst als Übergabe an die Plattform, noch nicht als Rollout in einen Cluster. Mögliche Aufgaben dieser Stage:

• Technische Promotion des Images/Charts in ein „stabil“-Projekt in Harbor nach erfolgreichem Scanning
• Aktualisierung von Metadaten oder Release-Informationen, die später von ArgoCD ausgewertet werden
• Dokumentation des Releases in GitLab (Release-Tag, Changelog-Eintrag)

Der eigentliche /kubernetes/-Rollout erfolgt dann im zweiten Teil der Serie über GitOps mit ArgoCD; an dieser Stelle stellen wir sicher, dass alle benötigten Artefakte und Informationen vollständig und überprüft in Harbor vorliegen.

---

Häufige Fragen

1. Kaniko oder Buildah – was ist für GitLab CI/CD typischerweise sinnvoller?

Beide Werkzeuge sind praxistauglich. In vielen Organisationen ist Kaniko die erste Wahl, wenn GitLab-Runner ohnehin auf /kubernetes/ laufen und ein möglichst schlanker, standardisierter Weg gesucht wird. Buildah spielt seine Stärken aus, wenn bereits Podman/Buildah-Erfahrung vorhanden ist oder komplexere Build-Szenarien (z. B. non-Dockerfile-basierte Builds) erforderlich sind.
Strategisch wichtig ist weniger die konkrete Wahl, sondern dass Sie konsequent auf rootless, daemonlose Builds setzen und diesen Ansatz in Ihren Sicherheits- und Architektur-Dokumenten verankern.

2. Wie streng sollten Vulnerability-Policies in Harbor sein?

Zu strenge Policies blockieren Releases, zu laxe bringen Sie in Erklärungsnot. Bewährt hat sich ein abgestuftes Modell:

• Für Entwicklungsprojekte: Warnungen bei High/Critical, aber keine harten Blockaden.
• Für Staging/Production: Pulls oder Promotions nur bei maximal „Medium“-Findings, High/Critical erfordern eine dokumentierte Ausnahme mit Zeitlimit und Verantwortlicher.

Wichtig ist eine enge Abstimmung zwischen Security, Plattform-Team und Entwicklung. Harbor liefert die technische Grundlage, die eigentliche Governance definieren Sie organisatorisch.

3. Wie integriert sich Vault/ESO mit bestehenden GitLab-Variablen?

Der Übergang muss nicht „Big Bang“ erfolgen. Ein mögliches Vorgehen:

1. Besonders kritische Secrets (z. B. Datenbankzugänge, externe API-Schlüssel) werden zuerst nach HashiCorp Vault migriert.
2. Die Pipeline wird so angepasst, dass sie statt GitLab-Variablen kurzlebige Tokens oder dynamische Credentials aus Vault bezieht.
3. Über den External Secrets Operator werden die gleichen Werte in den Clustern bereitgestellt, sodass Applikationen nahtlos weiterlaufen.
4. Schrittweise werden verbleibende GitLab-Variablen bereinigt oder auf nicht-sensible Konfigurationswerte reduziert.

So reduzieren Sie das Risiko, ohne Ihre bestehende CI/CD-Infrastruktur zu destabilisieren.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Die beschriebenen Bausteine – GitLab CI/CD, sichere Container-Builds, Harbor als Compliance-Gateway und Vault/ESO für Secrets – ergeben zusammen einen robusten, auditierbaren Workflow. In vielen Organisationen scheitert die Umsetzung jedoch weniger an der Technik als an der Integration: Wer betreibt Harbor? Wer verantwortet Vulnerability-Policies? Wer pflegt Vault-Rollen und ESO-Konfigurationen? Und wie übersetzen wir all das in konkrete Pipelines für reale Anwendungen wie eine Django-App?

Genau hier setzt ayedo an. Auf unserer /platform/ bündeln wir GitLab, Harbor, HashiCorp Vault und den External Secrets Operator zu einer integrierten Software Delivery Plattform – inklusive Betriebsverantwortung, Security-Guardrails und klaren Schnittstellen zu Ihren Entwicklungsteams. Anstatt jedes Tool isoliert zu betreiben, erhalten Sie einen durchgängig gedachten Workflow vom Commit bis zum registrierten, geprüften Image.

Für GitLab CI/CD stellen wir praxiserprobte Templates bereit, die genau die in diesem Artikel beschriebenen Prinzipien abbilden: rootless Container-Builds mit Kaniko oder Buildah, SBOM-Generierung, automatisches CVE-Scanning und Signing in Harbor sowie die Vorbereitung für ein GitOps-basiertes Deployment mit ArgoCD im zweiten Teil der Reihe. Diese Templates sind bewusst so gestaltet, dass sie eine solide Basis für Compliance-Anforderungen bieten, ohne Ihre Teams mit unnötiger Komplexität zu überfordern.

Wenn Sie Ihre bestehenden Pipelines schrittweise in diese Richtung entwickeln oder einen neuen, regulatorisch belastbaren Delivery-Workflow aufbauen möchten, ist ein gemeinsamer Einstieg über ein GitLab CI/CD Template oft der pragmatischste Weg.

GitLab CI/CD Template