Maximal isoliertes Kubernetes GitOps mit FluxCD und OCI Repositories

Maximal isoliertes Kubernetes GitOps mit FluxCD und OCI Repositories

Einleitung: Die Herausforderung maximal isolierter Umgebungen

Der Betrieb des Container Orchestrierungssytems Kubernetes in isolierten Umgebungen stellt Platform-Engineering-Teams vor besondere Herausforderungen. Wenn Cluster keinen direkten Zugang zum öffentlichen Internet haben, versagen herkömmliche GitOps-Workflows. Helm Charts können nicht aus öffentlichen Registries bezogen, Signaturen nicht gegen externe Schlüssel verifiziert und Laufzeit-Images nicht aus externen Quellen geladen werden.

Die cc cloud GmbH hat eine belastbare Architektur entwickelt, die die gesamte Software-Lieferkette in die isolierte Netzwerkgrenze bringt. Dieser Ansatz stellt sicher, dass jedes Artefakt, das der Cluster konsumiert — von Helm Charts bis zu Container-Images — verifiziert, signiert und innerhalb des privaten Netzwerks verfügbar ist. Die Architektur basiert auf zwei grundlegenden Repositories: Shared Artifacts und Software Releases. Gemeinsam bilden sie eine vollständige GitOps-Pipeline, die ausschließlich innerhalb der Isolationsgrenze operiert.

Architekturübersicht: Das Zwei-Repository-Muster

Das Fundament dieser Architektur ist eine klare Trennung der Zuständigkeiten. Wir betreiben zwei getrennte Git-Repositories, jedes mit einer spezifischen Rolle in der Software-Lieferkette.

Shared Artifacts ist der Eintrittspunkt. Es spiegelt Upstream-Helm-Charts aus öffentlichen Registries, verpackt sie als OCI-Artefakte, pusht sie in die private OCI-Registry, versieht sie mit Versions-Tags und signiert sie mit Cosign. Dieses Repository läuft vollständig in GitLab, gesteuert durch eine GitLab-CI-Pipeline mit Internetzugang. Es stellt sicher, dass alle benötigte Software innerhalb des privaten Netzwerks verfügbar ist, bevor ein Deployment-Versuch stattfindet.

Software Releases enthält die Konfiguration, die definiert, welche Software in welcher Version und mit welcher spezifischen Konfiguration in jedem Cluster läuft. In Helm-Chart-Terminologie enthält dieses Projekt die Helm Releases. Platform Engineers schreiben und pflegen die Konfiguration von GitLab aus. Die GitLab-CI-Pipeline pusht diese Konfiguration über die Isolationsgrenze hinweg, wo FluxCD sie ausliest und auf die Cluster anwendet. Wie Shared Artifacts lebt auch dieses Repository in GitLab und wird über GitLab CI verwaltet.

Diese Trennung schafft einen sauberen Übergabepunkt. Die GitLab-CI-Pipeline steuert beide Repositories von GitLab aus: Shared Artifacts bringt signierte Artefakte in die private OCI-Registry, während Software Releases die Deployment-Konfiguration über die Grenze hinweg pusht. FluxCD, das vollständig innerhalb der isolierten Zone operiert, liest sowohl aus der privaten OCI-Registry als auch aus den gepushten Software Releases, um den Cluster-Zustand abzugleichen. Die gesamte Architektur basiert auf FluxCD mit OCI Repositories und nutzt die Flux d2 Referenz Architektur, angepasst für den vollständig isolierten Betrieb.

Shared Artifacts: Der Spiegel

Das Shared Artifacts-Repository löst das grundlegende Problem isolierter Umgebungen: wie Software in die isolierte Zone hinein gelangt. Es fungiert als kontinuierliches Spiegelungssystem, das Upstream-Helm-Registries beobachtet und in die private OCI-Registry synchronisiert.

Der Spiegelungsprozess basiert auf einer CSV-Konfigurationsdatei, die alle öffentlichen Helm Charts auflistet, die gespiegelt werden sollen, einschließlich der Quell-Repository-URL, des Chart-Namens und optionaler Versionseinschränkungen. Diese Konfiguration definiert die gesamte Software-Infrastruktur, die innerhalb der isoliertern Zone verfügbar sein wird.

Die Mirroring-Pipeline verarbeitet diese Konfiguration durch automatisierte Skripte. Für jedes Chart führt die Pipeline mehrere Operationen durch. Sie bezieht das Chart aus der Upstream-Registry, extrahiert die Versionsmetadaten und ermittelt, ob eine neue Version gespiegelt werden muss. Für OCI-Artefakte wie CRDs extrahiert sie die Manifeste und pusht sie über die Flux CLI. Für Standard-Helm-Charts fügt sie optional Test-Manifeste hinzu und pusht das Chart anschließend in die OCI-Registry.

Nach dem Push wird jedes Artefakt mit seiner semantischen Version getaggt und mit Cosign signiert. Die Signierung verwendet einen privaten Schlüssel. Dadurch entstehen private, getaggte und signierte Kopien aller Upstream-Helm-Charts. Der öffentliche Schlüssel wird als Kubernetes Secret an die Cluster verteilt, um die Signaturverifizierung beim Deployment zu ermöglichen.

Software Releases: Die Konfigurationen

Software Releases lebt in GitLab neben Shared Artifacts. Es enthält die deklarative Konfiguration, die FluxCD zur Verwaltung des Cluster-Zustands nutzt: welche Software, in welcher Version und mit welcher Konfiguration in jedem Cluster läuft. In Helm-Chart-Terminologie enthält dieses Projekt die Helm Releases. Platform Engineers schreiben und prüfen Konfigurationen über GitLab Merge Requests, und die GitLab-CI-Pipeline pusht die Releases in die private Registry.

Das FluxCD Deployment nutzt FluxCD ResourceSets. Ein ResourceSet ist ein FluxCD Objekt, das mehrere zusammengehörige Ressourcen als Einheit erzeugt. Ein ResourceSet erstellt mehrere Ressourcen: einen Namespace für die Komponente, einen ServiceAccount und ein ClusterRoleBinding, die FluxCD die nötigen Berechtigungen zur Ressourcenverwaltung geben, ein OCIRepository, das auf die private OCI-Registry zeigt, und Kustomizations, die die Releases und Controller-Manifeste anwenden.

Die OCIRepository-Ressource enthält einen Verifizierungsabschnitt, der sicherstellt, dass nur signierte Artefakte deployed werden. Sie referenziert die private OCI-Registry, in die Charts durch die Shared Artifacts-Pipeline gepusht, getaggt und signiert wurden. Die Verifizierung prüft Signaturen mit dem öffentlichen Cosign-Schlüssel. Stimmt die Signatur nicht überein, markiert FluxCD die Quelle als fehlgeschlagen und verweigert das Deployment. Dies verhindert die Manipulation von Charts in der Registry.

Deployment-Reihenfolge und Abhängigkeiten

Infrastrukturkomponenten haben untereinander Abhängigkeiten. Zum Beispiel muss das Container Network Interface bereit sein, bevor Network Policies angewendet werden können. CRDs müssen installiert sein, bevor Controller sie nutzen können. Cert-Manager muss verfügbar sein, bevor eine Komponente TLS-Zertifikate benötigt.

Die Deployment-Reihenfolge wird über ein dediziertes ResourceSet orchestriert, das vier Deployment-Phasen definiert, um sicherzustellen, dass die Infrastruktur in der richtigen Reihenfolge hochfährt:

Die erste Phase deployed die Kerninfrastruktur wie Cilium und Kyverno und etabliert damit die Netzwerkschicht und die Admission Control des Clusters. Die zweite Phase behandelt Sicherheitskomponenten wie Cluster Roles und RBAC-Konfigurationen. Die dritte Phase umfasst DNS, Ingress und Zertifikatsverwaltung. Die vierte Phase deployed den Observability-Stack.

Jede Phase deklariert Abhängigkeitsbedingungen, die Kustomizations aus vorherigen Phasen referenzieren. FluxCD respektiert diese Bedingungen und geht erst zur nächsten Phase über, wenn die deklarierten Abhängigkeiten bereit sind. Dies stellt sicher, dass die Infrastruktur ohne manuellen Eingriff in der richtigen Reihenfolge hochfährt.

Umgebungs-Promotion: Von Dev zu Prod

Änderungen durchlaufen drei Umgebungen: dev → test → prod. Die Promotion-Pipeline ist über Renovate und GitLab CI automatisiert.

Renovate überwacht das Software Releases-Repository auf neue Helm Chart-Versionen. Wenn ein Update verfügbar ist, erstellt es einen Merge Request mit entsprechenden Labels. Labels umfassen die Umgebung, den Update-Typ und den Promotion-Tracking-Status.

Wenn ein Update in die nächste Umgebung promotet wird, ändern sich die Labels, um die Zielumgebung widerzuspiegeln. Die Promotion-Pipeline erstellt Eins-zu-eins-Merge-Requests, die die exakte Version von einer Umgebung in die nächste übertragen. Dies stellt sicher, dass genau das, was in Dev getestet wurde, auch in Test und schließlich in Prod deployed wird.

Auto-Merge-Konfigurationen ermöglichen störungsfreie Updates für Patch-Versionen, während für größere Änderungen eine manuelle Prüfung erforderlich ist. Diese Balance ermöglicht es der Plattform, bei Sicherheitspatches aktuell zu bleiben und gleichzeitig die Stabilität bei signifikanten Versionsänderungen zu gewährleisten.

Sicherheit und Vertrauen

Sicherheit in isolierten Umgebungen erfordert Verteidigung in der Tiefe. Jede Schicht der Architektur enthält Verifizierungsmechanismen.

Cosign-Signierung und -Verifizierung

Alle Artefakte, die in die private OCI-Registry gepusht werden, werden mit Cosign signiert. Der private Schlüssel wird als GitLab-CI-Secret verwaltet und ist niemals im Repository exponiert. Der öffentliche Schlüssel wird als Kubernetes Secret in jedem Komponenten-Namespace an die Cluster verteilt.

Die OCIRepository-Ressource von FluxCD prüft die Signatur bei jedem Sync. Ist die Signatur ungültig oder fehlt sie, markiert FluxCD die Quelle als fehlgeschlagen und wendet keine Änderungen aus diesem Artefakt an. Dies verhindert die Manipulation von Charts in der Registry.

Der Pull-Through-Cache: Der Abschluss

Container-Images, die von Helm Charts referenziert werden, müssen ebenfalls innerhalb der isolierten Zone verfügbar sein. Die Architektur löst dies mit einem Pull-Through-Cache-Mechanismus.

IaC erstellt Regeln, um die Upstream-Registries abzudecken, die von praktisch allen Infrastruktur-Helm-Charts genutzt werden: quay.io, registry.k8s.io oder auch Docker Hub. Diese Regeln ermöglichen es der privaten Registry, Images aus Upstream-Quellen zu cachen.

Kyverno ist als Admissions Controller installiert und überschreibt den Image-Repository-Pfad. Es mutiert Pod-Spezifikationen, um Image-Pulls von öffentlichen Registries auf den privaten Pull-Through-Cache umzuleiten. Dadurch wird sichergestellt, dass selbst wenn ein Helm Chart eine öffentliche Image-URL referenziert, der Cluster tatsächlich aus der privaten Registry bezieht, wo Images einer Security-Scanning-Prüfung unterzogen werden.

Workload Identity

FluxCD-Komponenten authentifizieren sich gegenüber der privaten OCI-Registry über Workload Identity. Dies bietet eine saubere Trennung zwischen Kubernetes Service Accounts und den Credentials, die für den Zugriff auf externe Dienste benötigt werden.

Wenn FluxCD Charts oder Images bezieht, verwendet es die Identität, die mit seinem Service Account verknüpft ist. Dies stellt sicher, dass der Zugriff auf die private Registry an den Workload selbst gebunden ist, anstatt an statische Secrets, die geleakt oder manuell rotiert werden könnten.

Netzwerkisolierung mit Cilium

Cilium stellt das CNI und die Network Policies bereit, die Zero-Trust-Networking innerhalb des Clusters durchsetzen. Jeder Komponenten-Namespace hat spezifische CiliumNetworkPolicies, die den Ingress und den Egress auf die erforderlichen Ziele beschränken. Die Netzwerkrichtlinien stellen sicher, dass selbst bei einer Kompromittierung einer Komponente keine Daten an unautorisierte Endpunkte exfiltriert werden können.

Die Deployment-Reihenfolge stellt sicher, dass Cilium und seine Netzwerkrichtlinien vor allen Workload-Komponenten installiert werden. Dies verhindert ein Zeitfenster, in dem Workloads ohne Durchsetzung von Netzwerkrichtlinien laufen.

Fazit

Isoliertes Kubernetes GitOps erfordert ein Splitten der Software-Lieferkette. Das Zwei-Repository-Muster trennt die Artefakt-Beschaffung von der Deployment-Konfiguration. Beide Repositories leben in GitLab und werden durch die GitLab-CI-Pipeline gesteuert. Shared Artifacts bringt Software in die isolierte Zone, verifiziert sie und stellt sie als signierte OCI-Artefakte bereit. Software Releases wird durch GitLab CI in die private Registry gepusht und FluxCD orchestriert das Deployment über ResourceSets, Deploymentreihenfolge und Signaturverifizierung.

Die Architektur zeigt, dass isolierte Umgebungen denselben Automatisierungs- und Sicherheitsgrad erreichen können wie Online Umgebungen. Der Schlüssel liegt darin, die gesamte Lieferkette — einschließlich Signierung, Verifizierung und Promotion-Workflows — innerhalb der Netzwerkgrenze zu verlagern. Mit Artefakt-Spiegelung, Abhängigkeitsverwaltung und Sicherheitskontrollen können isolierte Cluster mit einem Maximum an Sicherheit und Konsistenz im Deploymentprozess betrieben werden.

Die nächsten Artikel dieser Serie beleuchten Details der Implementierung der Konzepte, die in dieser Einführung vorgestellt worden sind.