Plattformarchitektur

gh0stcloud ist in zwei klar getrennte Schichten aufgeteilt: die Management Plane koordiniert Identität, Secrets und Billing, während die Runtime Cluster Tenant-Workloads isoliert ausführen. Die einzige erlaubte Brücke zwischen beiden ist GitOps.

Architektur-Prinzip: Desired State wird in Git beschrieben, von Flux CD reconciled und vom Provisioning-Layer materialisiert. Direkte Mutationen an Runtime-Objekten sind kein unterstützter Betriebspfad.

Architekturübersicht

gh0stcloud Plattformarchitektur — Management-Services und Runtime Cluster sind physisch getrennt — GitOps ist die kontrollierte Delivery-Brücke.

Cluster-Topologie

Umgebung	Rolle	Hardware	Standort
Management Environment	Management Plane	dedizierter Bare-Metal-Server	Deutschland
Development Environment	Development Runtime	Shared Compute Nodes (Control + Worker)	Deutschland
Production Environment	Production Runtime	Shared Compute Nodes + optionaler dedizierter Bare-Metal-Server	Deutschland

Alle Cluster laufen auf K3s mit Cilium als CNI und sind über NetBird zu einem privaten VPN-Mesh verbunden.

Management Plane

Die Management Plane hostet alle Platform Services und hat keine Tenant-Workloads:

Service	Funktion
Keycloak	Identity Provider — SSO, OIDC, PKCE, OAuth2, Tenant-Organisationen
OpenBao	Secrets Authority — Credentials werden per ESO in Namespaces synchronisiert, nie als Plaintext
gh0stplane	Platform Control API — Billing-Aggregation und Portal-Backend
Flux CD	GitOps Reconciliation Engine

Keycloak verwaltet Tenant-Organisationen als isolierte Identity-Grenzen. Jeder Tenant bekommt eine eigene Organisation mit scoped Groups und Roles — kein gemeinsamer Identity-Context über Tenants hinweg.

OpenBao ist die alleinige Secrets Authority. Workloads erhalten Credentials ausschließlich durch automatische Synchronisation in ihren Namespace — Secrets werden nie im Repository gespeichert oder manuell angelegt.

gh0stplane ist die Business-Logik der Plattform: Billing-Aggregation aus Nutzungsdaten, die Portal-API und die monatliche Rechnungserstellung.

Runtime Cluster

Jeder Runtime Cluster hat die gleiche Service-Basis:

Service	Funktion
Flux CD	GitOps-Pull aus dem Tenant-Source-Repository
Provisioning System	Reconciliert Plattform-Konfiguration und Tenant-Namespaces
Kyverno	Admission-Policies, NetworkPolicy-Baseline, Namespace-Guardrails
Prometheus + Alloy	Metrics-Collection und Log-/Trace-Forwarding
Beyla	eBPF-basiertes automatisches Application-Instrumentation — keine Code-Änderungen nötig

Jeder Tenant bekommt mindestens einen dedizierten, isolierten Namespace. Network Policies, die Cross-Tenant-Traffic unterbinden, werden automatisch angewendet.

GitOps Delivery — Wie Changes laufen

Alle Änderungen folgen einem einzigen, auditierbaren Pfad:

Source Repository
  └─► Flux CD
        └─► Provisioning Layer
              └─► Namespace · RBAC · Policy · Workload

Es gibt keinen Click-Ops-Pfad. Wer etwas im Cluster ändern möchte, tut das über einen Git-Commit. Die Reihenfolge der Reconciliation ist strikt geregelt — von Core-Services bis hin zu Tenant-Workloads.

Netzwerk und Connectivity

Intern: NetBird-VPN-Mesh verbindet alle Cluster. Kein Public Exposure für interne APIs.
Tenant-Ingress: Über kontrollierten Ingress-Controller pro Cluster, konfigurierbar per Tenant.
Egress: Dedizierter Egress-Node für Production, um ausgehende IPs beherrschbar zu halten.

Open-Source-Fundament

gh0stcloud setzt ausschließlich auf CNCF-/Open-Source-Projekte: Kubernetes, K3s, Cilium, Flux CD, Keycloak, OpenBao, Prometheus, Grafana, Kyverno. Proprietäres Wissen steckt im Betrieb und in den Automatisierungen — nicht in Lock-in-Komponenten.