Voraussetzungen
Bevor Sie beginnen, stellen Sie sicher, dass Ihre Umgebung die nachfolgenden Anforderungen erfüllt. Wir empfehlen, diese Checkliste während der Planungsphase gemeinsam mit Ihrem DuoKey-Ansprechpartner durchzugehen.
Plattform
| Anforderung | Empfohlen |
|---|---|
| OpenShift | Ein aktuelles unterstütztes 4.x-Release (OKD-Äquivalent wird unterstützt) |
| Cluster-Topologie | 3 Control-Plane-Knoten + ≥ 3 Worker-Knoten über ≥ 3 Fehlerdomänen |
| Container-Laufzeit | CRI-O (Standard in OpenShift) |
| Speicher | OpenShift Data Foundation (ODF) oder ein CSI-Treiber, der ReadWriteOnce-Block-Volumes und Snapshot-Unterstützung bereitstellt |
| Ingress | OpenShift Ingress Router (integriert) mit einem Wildcard-DNS + TLS-Zertifikat |
| Objektspeicher | S3-kompatibler Bucket für Backups (ODF NooBaa, MinIO oder extern) |
Compute-Dimensionierung (Ausgangspunkt)
Dies sind Basiswerte für eine produktive HA-Bereitstellung. Die endgültige Dimensionierung hängt von der Anzahl der Schlüssel, Clients und dem Anfragevolumen ab.
OpenShift-Worker-Knoten
| Profil | vCPU | RAM | Anmerkungen |
|---|---|---|---|
| Pro Worker (min. 3) | 8 | 32 GB | Beherbergt Frontend-, Backend- und Observability-Pods |
Dedizierte VM-Ebene
| VM | Anzahl | vCPU | RAM | Festplatte |
|---|---|---|---|---|
| OpenBao | 3 (HA / Raft) | 2 | 4 GB | 50 GB SSD |
| PostgreSQL | 3 (1 Primary + 2 Replikate) | 4 | 16 GB | 200 GB SSD |
| GitLab | 1 | 4 | 8 GB | 100 GB |
Die VM-Ebene kann auf Ihrem bestehenden Hypervisor virtualisiert werden (VMware, Proxmox, KVM/OpenStack). Halten Sie OpenBao und PostgreSQL nach Möglichkeit auf getrennten physischen Hosts, um einen Single Point of Failure zu vermeiden.
DKE-On-Premise-Dimensionierung
Bei Double-Key-Encryption-(DKE)-Bereitstellungen ist die dominierende Last die Anzahl der Key-Wrap-/Unwrap-Anfragen, die leichtgewichtig, aber stoßartig sind — sie steigen sprunghaft an, wenn Benutzer geschützte Dokumente öffnen oder speichern. Dimensionieren Sie für die Spitzen-Nebenläufigkeit, nicht nur für die Gesamtbenutzerzahl.
Ressourcen pro Komponente (HA-Baseline)
Dies sind die Request-Größen pro Replikat für die DuoKey-Komponenten mit der Mindestanzahl an Replikaten für eine hochverfügbare Bereitstellung. Die Images stammen aus der Harbor-Registry.
| Komponente | vCPU / Replikat | RAM / Replikat | Speicher | Min. Replikate (HA) |
|---|---|---|---|---|
| Cockpit (Frontend) | 2 | 4 GB | 20 GB | 2 |
| Cockpit API (Backend) | 4 | 8 GB | 20 GB | 3 |
| KMS API (DKE-Schlüsselendpunkt) | 2 | 4 GB | 20 GB | 2 |
| MPC- / TSM-Knoten | 4 | 8 GB | 20 GB | 3 |
| PostgreSQL (MPC + Cockpit) | 4 | 16 GB | 100 GB | 3 |
| Redis-Cache | 4 | 8 GB | 50 GB | 3 |
| Message-Broker (RabbitMQ/Kafka) | 4 | 8 GB | 50 GB | 3 |
| OpenBao (VM-Ebene) | 2 | 4 GB | 50 GB | 3 |
| Monitoring-Stack | 8 | 16 GB | 200 GB | 1 |
| Logging-Stack | 8 | 16 GB | 600–1000 GB | 1 |
Dimensionierungsstufen nach Benutzeranzahl
Die Ressourcen pro Komponente oben leiten sich aus der Referenzdimensionierung von DuoKey ab. Die Benutzeranzahl-Stufen unten sind indikative Ausgangspunkte, um die Planung zu erleichtern — sie sind keine vertragliche Zuordnung. Die tatsächliche Dimensionierung hängt von der Dokumentaktivität und der Spitzen-Nebenläufigkeit ab und wird mit DuoKey für Ihre Bereitstellung validiert.
Die folgende Tabelle dimensioniert die OpenShift-Anwendungs-Worker-Knoten (die oben genannten Pods). Sie schließt die 3 Control-Plane-Knoten und die dedizierte Daten-/VM-Ebene (PostgreSQL, OpenBao) aus, die entsprechend der Tabelle pro Komponente oben skalieren.
| Stufe | Benutzer | App-Worker-Knoten | Pro Knoten | Anmerkungen |
|---|---|---|---|---|
| Pilot / PoC | ≤ 1.000 | 3 | 8 vCPU / 32 GB | Minimale HA, reduzierte Replikate |
| Standard | ≤ 10.000 | 3–4 | 8 vCPU / 32 GB | Referenz-HA-Architektur |
| Groß | ≤ 50.000 | 6 | 16 vCPU / 64 GB | Skalierte Replikate + HPA |
| Enterprise | 100.000+ | 8+ | 16 vCPU / 64 GB | Individuell; typischerweise Multi-Site |
- MPC-Knoten sind während Schlüsseloperationen CPU-gebunden — skalieren Sie diese unter hoher DKE-Last zuerst.
- PostgreSQL wird als einfacher Datenspeicher verwendet (keine schweren Abfragen), daher ist es eher RAM-/IO-gebunden als CPU-gebunden.
- Redis und der Broker sind Durchleitung/Caching — moderate CPU.
- Aktivieren Sie den HorizontalPodAutoscaler auf Cockpit-API- und MPC-Knoten, um Anfragespitzen abzufangen.
Diese Werte sind ein sicherer Ausgangspunkt. Ihr DuoKey-Ansprechpartner wird sie anhand Ihrer tatsächlichen Benutzerpopulation, Dokumentaktivität, Spitzen-Nebenläufigkeit und Ihrer Verfügbarkeitsziele (Single-Site vs. Multi-Datacenter) verfeinern.
Software & Operatoren
Installieren Sie die folgenden OpenShift-Operatoren (über OperatorHub) vor der Bereitstellung:
- OpenShift GitOps (ArgoCD)
- External Secrets Operator (ESO)
- Ein PostgreSQL-Operator — CloudNativePG oder Patroni (wenn PostgreSQL im Cluster statt auf VMs betrieben wird)
- OpenShift Data Foundation (bei Verwendung von ODF als Speicher)
- Velero / OADP (OpenShift API for Data Protection) für Backups
Externe Software:
- OpenBao ≥ neueste stabile Version, konfiguriert mit integriertem Raft-Speicher
- GitLab (selbst gehostet) oder Zugang zu GitLab SaaS
- Redis ≥ 7 (Sharded Cluster) — In-Cluster-StatefulSet oder auf VMs
Netzwerk
| Fluss | Quelle | Ziel | Port |
|---|---|---|---|
| Benutzer → App | Clients | Ingress Router | 443/TCP |
| App → Secrets | Worker-Knoten | OpenBao-VMs | 8200/TCP |
| App → Datenbank | Worker-Knoten | PostgreSQL Primary/Replikate | 5432/TCP |
| GitOps → Quellcode | ArgoCD | GitLab | 443/TCP, 22/TCP |
| Backup | Cluster / Velero | Objektspeicher | 443/TCP |
| OpenBao → HSM (optional) | OpenBao-VMs | HSM | je nach HSM-Hersteller |
Anforderungen:
- Wildcard-DNS-Eintrag (z. B.
*.duokey.example.local), der auf die Ingress-Router-VIP zeigt. - TLS-Zertifikate für die Anwendungs-Hostname(n) — eine interne CA ist für Air-Gapped-Standorte ausreichend.
- Empfohlene Netzwerksegmentierung: getrennte VLANs für Anwendungs-, sicheren (HSM) und Backend-/Speicherverkehr.
- Für Air-Gapped-Installationen: eine Mirror-Registry (z. B. Quay / mirror.registry) für OpenShift-Release- und Operator-Images.
Schlüsselverwahrung: DuoKey MPC und/oder HSM
Die primäre Vertrauensbasis von DuoKey ist seine eigene Multi-Party Computation (MPC): Schlüsselmaterial wird in Anteile aufgeteilt, sodass kein einzelner Knoten oder Administrator jemals einen vollständigen Schlüssel hält — keine dedizierte HSM-Hardware erforderlich.
Für Bereitstellungen, die zusätzlich eine Hardware-Vertrauensbasis erfordern, integriert sich DuoKey mit dem Securosys-HSM (PKCS#11 / KMIP). Stellen Sie bereit:
- Netzwerkerreichbarkeit von den OpenBao-VMs zum Securosys-HSM (oder zum Securosys-Cloud-HSM- / CloudsJMS-Endpunkt), idealerweise auf einem dedizierten, gehärteten VLAN.
- HSM-Client-Anmeldedaten / -Partition, konfiguriert für OpenBao.
Zugang & Kenntnisse
- Cluster-Admin-Zugang zum OpenShift-Cluster.
- Administrativer Zugang zum VM-Hypervisor und zu DNS.
- Vertrautheit mit
oc/kubectl, GitOps-Konzepten und dem Betrieb von OpenBao.
Sobald diese vorhanden sind, fahren Sie mit der Installation fort.