secure k8 s

Deployment: VM vs Kubernetes (HA)

Summary: Entscheidungshilfe für Enterprise-Kunden: OpenBao mit HA als klassisches VM-Cluster (Pakete + systemd + Raft) gegenüber OpenBao mit HA auf Kubernetes via Helm-Chart. Beide Varianten sind unterstützt; sie unterscheiden sich in Betriebsmodell, Sicherheitsannahmen und Abhängigkeitsgraph — nicht in den Vault-Kernfunktionen.

Sources: raw/docs/install.md, raw/docs/configuration/storage/raft.md, raw/docs/configuration/storage/postgresql.md, raw/docs/platform/k8s/index.md, raw/docs/platform/k8s/helm/examples/ha-with-raft.md, raw/docs/platform/k8s/helm/examples/ha-tls.md, raw/docs/platform/k8s/helm/examples/snapshot-cronjob.md, raw/docs/configuration/seal/, raw/docs/upgrading/.

Last updated: 2026-05-19

TL;DR — Empfehlung für Enterprise

Für eine zentrale, organisationsweite OpenBao-Instanz mit hohem Schutzbedarf lautet die übliche Empfehlung: HA-Cluster auf dedizierten VMs, idealerweise mit HSM- oder Cloud-KMS-basiertem Auto-Unseal, und K8s-Workloads konsumieren OpenBao über den External-Mode des Helm-Charts (Agent Injector / VSO / CSI; siehe kubernetes-platform).

Begründung in einem Satz: OpenBao ist üblicherweise die Wurzel des Vertrauens — sie sollte nicht von der Plattform abhängen, deren Secrets sie verwaltet.

Eine reine Helm-HA-Installation auf Kubernetes ist trotzdem die richtige Wahl, wenn (a) OpenBao ausschließlich K8s-Workloads bedient, (b) das Operations-Team K8s-first arbeitet, (c) Self-Service-Provisionierung und GitOps wichtiger sind als architektonische Entkopplung, und (d) ein verlässliches Auto-Unseal sowie ein gepflegter Storage-Class-Stack vorhanden sind.

Gemeinsame Basis

Beide Topologien nutzen typischerweise das gleiche Setup auf Vault-Ebene:

  • 3 oder 5 Knoten mit Raft als Integrated Storage (source: raw/docs/configuration/storage/raft.md).
  • Leader/Follower-Mechanik wie unter high-availability beschrieben — ein Knoten hält den Lock und ist active, die anderen sind standby und forwarden Schreibanfragen.
  • Auto-Unseal empfohlen (Cloud-KMS, HSM via PKCS#11 oder transit).
  • Mindestens zwei Audit-Devices mit unterschiedlichen Sinks.
  • Periodische Raft-Snapshots als primäres Backup.

Die Unterschiede liegen darum herum — wie die Knoten provisioniert, gestartet, gepatcht, vernetzt und geschützt werden.

Variante A — HA auf VMs

Architektur

3 oder 5 dedizierte VMs (oder Bare-Metal), Paketinstallation via OS-Paketmanager (source: raw/docs/install.md), Lifecycle über systemd, integrierter Raft-Storage auf lokalem Block-Storage, ein externer L4-Load-Balancer (oder DNS-Round-Robin mit Health-Check) vor den API-Listenern.

Vorteile

  • Geringer Abhängigkeitsgraph. Kein Kubernetes-Control-Plane, kein CNI, kein CSI im kritischen Pfad. Ein K8s-Vorfall kann OpenBao nicht mitreißen — wichtig, wenn OpenBao genau diesen Cluster mit Secrets versorgt (Bootstrap-Reihenfolge, Henne-Ei-Problem).
  • Stärkere Isolation. VM-Grenze statt Pod-Grenze; passt zu klassischen Tiering-/Zonen-Konzepten (Bastion, Mgmt-VLAN, Hardened Zone) und zu Audit-Frameworks, die Co-Tenancy auf einem geteilten Kernel kritisch bewerten.
  • HSM-Integration einfach. PKCS#11 gegen einen Netzwerk- oder lokal angebundenen HSM lässt sich über die seal "pkcs11"-Stanza direkt einbinden (source: raw/docs/configuration/seal/). In Kubernetes ist Device-Passthrough in Pods zusätzlich aufwendig.
  • Vorhersagbare Performance. Keine Noisy-Neighbor-Effekte aus anderen Pods; CPU, RAM und Disk gehören OpenBao allein.
  • Vertraute Betriebsmodelle. Patch-Management, Backup, Monitoring, IDS, Logging laufen über bestehende Enterprise-Werkzeuge (Konfigurationsmanagement wie Ansible, Image-Hardening per CIS-Baseline, journald + SIEM-Forwarder).
  • Audit- und Compliance-Story einfacher. Eine Maschine = eine OpenBao-Rolle. Sehr klare Zuordnung von Identitäten, Netzwerkpfaden und Datenhaltung — etwas, das Auditoren in regulierten Branchen (Finanz, Gesundheit, Public Sector) bevorzugen.
  • Zertifikatsmanagement geradlinig. TLS-CN entspricht typischerweise dem stabilen Hostname; keine Sonderlogik wie leader_tls_servername, die im K8s-Fall nötig wird (source: raw/docs/platform/k8s/helm/examples/ha-tls.md).
  • HA-Upgrades planbar. Knoten-für-Knoten-Replacement mit klarer Leader-Handoff-Reihenfolge gemäß upgrading.

Nachteile

  • Provisionierung ist manuelle Arbeit oder benötigt IaC. bao operator init, Unseal-Verteilung, bao operator raft join pro Knoten sind Schritte, die Sie über Ansible/Terraform/Cloud-Init scripten müssen. Helm tut das auf K8s implizit.
  • Kein eingebautes Self-Healing. Stirbt eine VM, muss ein Mechanismus (Hypervisor-HA, Cloud-AutoScalingGroup, externe Orchestrierung) sie neu erzeugen und der Cluster aufnehmen lassen. Auf K8s erledigt das der StatefulSet-Controller.
  • OS-Lifecycle in eigener Verantwortung. Kernel-Patches, CVEs, Hardening, Compliance-Scans pro VM.
  • Skalierung träger. Neue Knoten brauchen neue VMs — schneller als ein Pod-Restart geht das nicht.
  • Netzwerk muss manuell modelliert werden. Load-Balancer, Firewall-Regeln, DNS, mTLS-PKI für Raft-Replikation — alles eigenständig.
  • Mehr Infrastruktur insgesamt. VMs, Storage-Volumes, LB, Monitoring-Agents, Backup-Agents.

Wann diese Variante richtig ist

  • OpenBao ist zentral und organisationsweit — auch für Nicht-K8s-Workloads (Legacy-Apps, Datenbanken, CI-Runner, Netzwerkgeräte, Cloud-IAM).
  • Regulatorische Anforderungen (BaFin/PCI/HIPAA/BSI) verlangen klar getrennte Tiers oder HSM-basiertes Sealing.
  • Es existiert ein eingespieltes klassisches Ops-Team mit IaC und Patch-Pipelines.
  • OpenBao darf nicht vom selben Kubernetes-Cluster abhängen, den es absichert.

Variante B — HA auf Kubernetes via Helm

Architektur

StatefulSet mit drei Pods (openbao-0..2), persistente PVCs pro Pod, Headless-Service (openbao-internal) für die Raft-Peer-Kommunikation, regulärer Service als Client-Eintrittspunkt, ein optionaler Ingress/LB davor. Bring-up gemäß k8s-ha-setup:

helm install openbao openbao/openbao \
  --set='server.ha.enabled=true' \
  --set='server.ha.raft.enabled=true'

(source: raw/docs/platform/k8s/helm/examples/ha-with-raft.md)

Vorteile

  • Deklarativer Bring-up. Eine Helm-Installation liefert ein 3-Knoten-Raft-Cluster; identische Reproduktion in Dev/Stage/Prod ist trivial.
  • Self-Healing & Identitätsstabilität. Fällt ein Pod aus, startet der StatefulSet ihn mit gleicher Identität und gleichem PVC neu — der Raft-Cluster heilt sich von selbst, sofern Quorum erhalten bleibt.
  • Nahtlose Workload-Integration. Der gleiche Chart liefert oder vernetzt sich mit Agent Injector, VSO und CSI (source: raw/docs/platform/k8s/index.md) — Pods bekommen Secrets ohne Code-Änderungen.
  • Service-Registrierung. Über die service_registration-Stanza erscheinen Active/Standby/Sealed als Pod-Labels — Kubernetes-Services können den aktiven Knoten direkt selektieren (source: raw/docs/platform/k8s/index.md).
  • GitOps-fähig. Helm-Values und CRDs lassen sich über ArgoCD/Flux verwalten; Drift-Detection und Pull-Requests inklusive.
  • Snapshots als CronJob. Reguläre Raft-Snapshots laufen als Kubernetes-CronJob — kein eigener Scheduler nötig (source: raw/docs/platform/k8s/helm/examples/snapshot-cronjob.md).
  • Schnelle Bereitstellung non-prod. Test- und Dev-Cluster sind in Minuten reproduzierbar.

Nachteile

  • Harte Abhängigkeit von Kubernetes selbst. Control-Plane, etcd, CNI, CSI, Ingress — alle werden Teil des kritischen Pfads für die Wurzel des Vertrauens. Plattform-Vorfälle werden zu OpenBao-Vorfällen.
  • Bootstrap-Zirkularität. Wenn der gleiche Cluster OpenBao für seine eigenen Workloads konsumiert: Wer entsperrt OpenBao, wenn nach einem kompletten Cluster-Restart erst OpenBao laufen muss, damit die Workloads starten? Lösbar (Cloud-KMS-Auto-Unseal), aber muss bewusst designt werden.
  • Auto-Unseal faktisch verpflichtend. Shamir-Unseal nach jedem Pod-Restart manuell durchführen ist im K8s-Alltag nicht praktikabel (source: raw/docs/platform/k8s/helm/examples/ha-with-raft.md, seal-unseal). Ohne Cloud-KMS oder HSM-Anbindung ist diese Variante nicht produktionstauglich.
  • TLS-Konfiguration fummelig. Per-Pod-DNS-Namen passen ohne Workaround nicht zum Zertifikats-CN; entweder leader_tls_servername je Pod oder ein Load-Balancer-Frontend (source: raw/docs/platform/k8s/helm/examples/ha-tls.md).
  • Geringere Isolation. Pods teilen den Kernel mit anderen Workloads; in Hochsicherheitsumgebungen reicht das oft nicht. Mitigation: dedizierte Node-Pools mit Taints, Pod-Security-Standards restricted, eigene Namespaces, NetworkPolicies — alles zusätzliche Komplexität.
  • HSM/PKCS#11-Anbindung aufwändig. Device-Plugins oder externes HSM-Gateway nötig, um aus dem Pod auf Hardware zuzugreifen.
  • PVC-Qualität entscheidet über Datensicherheit. Eine fehlerhaft konfigurierte StorageClass (z. B. RWX statt RWO, oder Block-Storage ohne fsync-Garantien) gefährdet Raft. Auf VMs ist die Disk-Semantik üblicherweise besser verstanden.
  • Zwei Upgrade-Ebenen. Chart-Upgrade und Kubernetes-Upgrade müssen koordiniert werden; siehe upgrading zur HA-Upgrade-Reihenfolge.
  • Operativer Skill-Mix breiter. Das Team braucht Vault- und Kubernetes-Expertise gleichzeitig — Troubleshooting durch CNI/Service/Endpoints/Pod hindurch ist anspruchsvoll.

Wann diese Variante richtig ist

  • OpenBao bedient ausschließlich K8s-Workloads, idealerweise im selben Cluster.
  • Die Plattform-Organisation ist K8s-nativ; klassisches VM-Management wäre der Sonderfall.
  • Cloud-KMS oder zentrales transit-Cluster für Auto-Unseal sind verfügbar.
  • Self-Service, GitOps und schnelle Reproduzierbarkeit überwiegen architektonische Entkopplung.

Direktvergleich

DimensionVM-HAKubernetes-HA (Helm)
Abhängigkeitsgraphminimal (OS + LB)breit (K8s-Control-Plane, CNI, CSI, Ingress)
Bring-upmanuell/IaC, mehrere Schrittehelm install + Init/Unseal/Join
Self-Healingüber Hypervisor/AutoScalingnativ via StatefulSet
Auto-Unsealoptional (aber empfohlen)faktisch verpflichtend
HSM/PKCS#11nativ einfachnur über Device-Plugins / externes Gateway
IsolationVM-GrenzePod-Grenze (Kernel geteilt)
TLS-Setupgeradlinigerfordert leader_tls_servername oder LB-Vorbau
BackupSnapshots via Cron/SkriptSnapshots via K8s-CronJob
Upgrade-Komplexitäteine Ebene (OpenBao)zwei Ebenen (Chart + K8s)
Skill-Profilklassisches Linux/OpsK8s + Vault parallel
Compliance/Auditbekanntes Tiering-Modellerfordert zusätzliche Pod-/Namespace-Härtung
Reproduzierbarkeit non-prodlangsamer (VMs anlegen)sehr schnell
Workload-Integration in K8süber Agent/VSO/CSI im External-Modenativ inklusive
Bootstrap-Zirkularitätkeinemöglich, muss designt werden

Hybrides Muster (häufigste Enterprise-Lösung)

In der Praxis kombinieren viele Kunden beide Welten:

  1. Zentrales OpenBao-HA-Cluster auf VMs (3 oder 5 Knoten, HSM-Auto-Unseal, hinter LB, in eigener Sicherheitszone).
  2. Pro K8s-Cluster wird der Helm-Chart im External-Mode installiert (source: raw/docs/platform/k8s/index.md): er bringt nur Agent Injector und/oder VSO/CSI mit und zeigt auf die externe OpenBao-Adresse.
  3. Authentifizierung der K8s-Workloads gegen das zentrale OpenBao über die Kubernetes-Auth-Methode (TokenReview-API), pro Cluster eine Auth-Mount.

Dieses Muster liefert die operative Bequemlichkeit der K8s-Integration ohne die Wurzel des Vertrauens in den abhängigen Cluster zu legen.

Empfehlung für die Kundenpräsentation

  1. Default-Empfehlung: VM-HA + HSM-Auto-Unseal + K8s-Workloads über External-Mode.
  2. Alternative: Helm-HA auf K8s, wenn das Einsatzprofil rein K8s-zentriert ist und Cloud-KMS-Auto-Unseal verfügbar ist.
  3. Anti-Pattern: Helm-HA auf K8s, und dieser Cluster konsumiert OpenBao für seinen eigenen kritischen Pfad, ohne Cloud-KMS-Auto-Unseal und ohne dedizierten Node-Pool. Diese Konstellation explizit ausschließen.