Zum Hauptinhalt springen

Referenzarchitektur

Die On-Premise-Bereitstellung von DuoKey ist eine hochverfügbare (HA), produktionstaugliche Hybridarchitektur. Sie kombiniert einen OpenShift-Cluster für containerisierte Anwendungs-Workloads mit einer dedizierten VM-Infrastruktur für zentrale Daten, CI/CD und Secrets-Management — alles gestützt durch einen umfassenden Backup- und Wiederherstellungsplan.

DuoKey On-Premise OpenShift-Referenzarchitektur

Für die Anpassung konzipiert

Die untenstehende Architektur beschreibt das empfohlene Referenzdesign. Die Wahl von Speicher, Ingress und Object-Store kann an Ihre Umgebung angepasst werden (Bare Metal, VMware, OpenStack oder Nutanix) — Ihr DuoKey-Ansprechpartner unterstützt Sie bei der Anpassung.

Kernkomponenten​

1. Zentralisierte Secrets — externes OpenBao​

  • Standalone-Isolation — OpenBao (der community-getriebene, quelloffene Fork von Vault der Linux Foundation) läuft extern auf dedizierten virtuellen Maschinen, konfiguriert in einem HA-Setup mit einer Speicher-Engine auf Basis von Raft-Konsens.
  • Sicherer Authentifizierungs-Handshake — der OpenShift-Cluster betreibt den External Secrets Operator (ESO). Wenn ein Anwendungs-Pod startet, authentifiziert sich ESO über die Kubernetes Auth Method bei OpenBao mithilfe des ServiceAccount-Tokens des Pods.
  • Dynamische, nicht-persistente Injektion — Anmeldedaten, Datenbank-Verbindungs- zeichenfolgen und Cache-Schlüssel werden bei Bedarf aus OpenBao abgerufen und als native Kubernetes-Secret-Primitive injiziert, die auf flüchtige, im Arbeitsspeicher gehaltene (tmpfs) Volumes abgebildet werden. Kein Rohsecret wird jemals in den Cluster-Speicher geschrieben oder fest in Git codiert.
HSM-Integration

Für das höchste Sicherheitsniveau wird die Schlüsselverwahrung entweder in DuoKeys eigenem MPC (verteilte Schlüssel-Shares, kein Single Point of Compromise) oder in einem Securosys-HSM verankert. Siehe Voraussetzungen für Details.

2. Continuous Delivery & Quellcodeverwaltung — GitLab​

  • Zentrale für Quellcode & Registry — Code-Repositorys, CI-Pipelines und benutzerdefinierte Basis-Container-Images befinden sich auf einer selbst gehosteten GitLab-Instanz, die auf einer eigenständigen VM läuft. Diese kann durch das SaaS-Angebot von GitLab ersetzt werden, sofern die Richtlinien dies zulassen.

3. Persistente Datenbank — PostgreSQL-Cluster​

  • Datenbank-Hochverfügbarkeit — PostgreSQL läuft unter einem cloud-nativen Datenbank-Operator (wie CloudNativePG oder Patroni) und pflegt einen primären Lese-/Schreibknoten sowie mehrere Hot-Standby-Replikate.

4. Plattform- & Anwendungsorchestrierung​

  • OpenShift-Control-Plane — nutzt die integrierten OpenShift-Operatoren, um Lebenszyklus, Netzwerk, Routing und Plattform-Upgrades automatisch zu verwalten.
  • Ingress & Lastausgleich — der integrierte, hochverfügbare OpenShift Ingress Router verarbeitet den Edge-Verkehr, terminiert TLS und verteilt die Last über die Frontend-Pods. Das interne Routing zwischen dem Frontend und dem Rust-API-Backend verwendet native Headless- und ClusterIP-Kubernetes-Services.
  • HA-Topologie — alle Frontend- und Backend-Pods verwenden explizite Pod- Anti-Affinity-Regeln, die garantieren, dass Workloads über verschiedene Worker-Knoten und separate Availability Zones (AZs) verteilt werden.
  • GitOps-Reconciliation — der im Cluster laufende OpenShift GitOps (ArgoCD)- Operator verfolgt kontinuierlich Branches in GitLab. Wenn sich Anwendungsmanifeste ändern, erkennt ArgoCD die Abweichung (Drift) und überträgt die Aktualisierungen sauber in die betroffenen Namespaces.

5. Persistente Datenebene​

  • Stateful-Orchestrierung — Datenbank- und Caching-Engines werden als StatefulSets bereitgestellt, um Netzwerkidentitäten und Block-Device-Zuordnungen über Neustarts hinweg zu erhalten.
  • Speicheranbieter — die Persistenz wird durch OpenShift Data Foundation (ODF) oder einen für Ihre Plattform geeigneten CSI-Treiber bereitgestellt (z. B. OpenStack Cinder, vSphere CSI).
  • Cache-Hochverfügbarkeit — Redis ist als Sharded Cluster mit mehreren Knoten und automatisiertem Master/Replica-Failover konfiguriert.

6. Observability — VictoriaMetrics & VictoriaLogs​

  • Metriken — schlanke vmagent-Instanzen scrapen Performance-Endpunkte und leiten sie an einen verteilten VictoriaMetrics-Stack (vmstorage, vminsert, vmselect) weiter.
  • Logs — Vector-Agenten sammeln stdout/stderr und leiten sie zur strukturierten Suche an VictoriaLogs weiter.
  • Dashboards — ein integriertes Grafana verbindet sich mit beiden als Datenquellen für operative Dashboards.

Anfrage- & Datenfluss​

Netzwerk & Availability Zones​

  • Anwendungs-Pods werden über mindestens drei Worker-Knoten verteilt, die separate Availability Zones / Failure Domains umspannen.
  • Die dedizierte VM-Ebene (OpenBao, PostgreSQL, GitLab) wird in isolierte Netzwerke segmentiert, idealerweise mit einem separaten, gehärteten VLAN für jegliches HSM.
  • Der gesamte Datenverkehr zwischen den Komponenten wird bei der Übertragung verschlüsselt (TLS); OpenBao wird nur über beidseitig authentifizierte Kanäle erreicht.

Siehe Voraussetzungen → Netzwerk für die konkreten Netzwerk- und Firewall-Anforderungen.