Neu in Vault

Vault portiert Fixes innerhalb einer Major-Linie nicht über Minor-Grenzen zurück. Seit 2.1.0 ist 2.0.4 vom 04.08.2026 damit der letzte 2.0-Patch: Am 16.09.2026 erschienen 2.1.1 und die Enterprise-Patches 1.21.11, 1.20.16 und 1.19.22, für 2.0 keiner, auch kein Enterprise-Build. Security-Fixes gibt es nur über das Upgrade auf 2.1.x. Die 1.x-Linien laufen nur noch als Enterprise-Builds, ihre letzten Community-Releases waren 1.21.4, 1.20.4 und 1.19.5.

Die native Absicherung von KI-Agenten-Workflows ist nach der Public Beta seit 2.0.3 (17.06.2026) allgemein verfügbar. Die OAuth-Resource-Server-API braucht keine Aktivierung über sys/activation-flags/oauth-resource-server/activate mehr. OAuth-2.0-JWTs lassen sich über die Token-Revoke-APIs für Vault sperren, eine globale Denylist wirkt über alle Namespaces. issuer_id und unique_id_claim eines Resource-Server-Profils sind nach dem Anlegen unveränderlich: Ändern heißt löschen und neu anlegen.

Die relevanten PKI-Endpunkte geben Zertifikat-Bundles auch als PKCS#12 (PFX) oder Java-Keystore (JKS) aus, base64-kodiert und passwortgeschützt. Die Konvertierung per openssl oder keytool im Deploy-Schritt kann entfallen.

Das External-CA-Plugin erfüllt ACME-DNS-01-Challenges selbst, unterstützt sind AWS Route53, Azure DNS, Google Cloud DNS sowie BIND und andere RFC-2136-Server. Öffentliche Zertifikate, deren Ausstellung DNS-01 verlangt, etwa Wildcards, laufen damit vollständig über Vault.

Hybrid sign/verify in der Transit-Engine akzeptiert SLH-DSA als Post-Quanten-Komponente, kombinierbar mit ECDSA P-256, P-384, P-521 und Ed25519. SLH-DSA ist hashbasiert und hängt damit nicht an den Gitterannahmen hinter ML-DSA.

2.1.0 bereinigt den vom Aufrufer steuerbaren DisplayName, bevor er in generierte Datenbank-Usernames einfließt, und schließt damit SQL-Injection über username_template. Neu ist eine Konfigurationswarnung, wenn ein username_template DisplayName ohne truncate nutzt. Derselbe Fix kam am 01.09.2026 in 1.21.10, 1.20.15 und 1.19.21 (Enterprise). Eigene username_templates auf die Warnung prüfen.

Ab 2.1.1 laufen höchstens 20 retry-join-Worker gleichzeitig, weitere Versuche scheitern mit too many concurrent raft retry joins in progress. Dieselbe Grenze kam in den Enterprise-Linien schon früher: am 01.09.2026 mit 1.20.15 und 1.19.21, am 16.09.2026 mit 1.21.11. 2.1.0 hatte sie noch nicht. Automatisierung, die viele Nodes gleichzeitig joinen lässt, muss das abfangen.

Der Versionssprung von 1.21 auf 2.0 markiert den Wechsel vom HashiCorp-LTS-Modell auf IBM Support Cycle-2 (SC2). Die Versionen folgen jetzt V.M.F: Ein Major startet einen Support-Lifecycle, Minor-Releases bringen Features, Fix-Releases Patches. Enterprise erhält je Major 2 Jahre Base Support, 1 Jahr Extended Support für kritische Fixes und 3 Jahre Sustained Support ohne neue Fixes. Vault Enterprise 1.19 ist die letzte LTS-Linie, ihre Extended Maintenance läuft bis April 2027 (1.16 endete im April 2026). Wer auf 1.19 steht, braucht den Wechsel auf 2.x vorher und nimmt dabei die Breaking Changes aus 1.20 und 1.21 mit.

sys/rekey, sys/generate-root und sys/replication/dr/secondary/generate-operation-token verlangen ab 2.0.0 eine Authentifizierung. Das alte Verhalten lässt sich über den HCL-Schlüssel enable_unauthenticated_access zurückholen. Break-Glass-Automatisierung und Disaster-Recovery-Runbooks vor dem Upgrade prüfen, sonst steht man im Ernstfall vor einem 403.

Das Container-Image hat innerhalb der 2.0-Linie zweimal gewechselt: 2.0.1 setzte cap_ipc_lock zur Build-Zeit, 2.0.2 hat die Capability wieder entfernt, damit Vault in üblichen Container-Runtimes startet. Konsequenz für den Betrieb: disable_mlock = true setzen und Swap auf dem Host abschalten oder verschlüsseln. 2.0.4 entfernt zusätzlich gnupg, openssl und procps aus den UBI-Images, was Debug- und Init-Skripte brechen kann.

Als Fix für CVE-2026-39829 erzwingt Vault ab 2.0.2 eine maximale RSA-Modulgröße von 8192 Bit, größere Schlüssel lassen sich weder verwenden noch signieren. Gleicher Stand ab 1.21.7, 1.20.12 und 1.19.18.

Enthält die gerenderte Ausgabe eines Identity-Templates + oder *, etwa aus Gruppen-Metadaten, antwortet Vault ab 2.0.1 mit permission denied. Gleiches gilt ab 1.21.6, 1.20.11 und 1.19.17.

Ab 2.0.3 kann ein deny auf einem spezifischeren Pfad nicht mehr durch ein LIST mit abschließendem Slash umgangen werden, wenn daneben ein breiteres allow existiert. Policies, die sich auf das alte, fehlerhafte Verhalten verlassen haben, verweigern danach den Zugriff.

Ab 2.0.4 führen doppelte Attribute in Konfigurationsdateien und Policies immer zum Parse-Fehler, die Notbremse VAULT_ALLOW_PENDING_REMOVAL_DUPLICATE_HCL_ATTRIBUTES ist entfernt. Der Pfad lief über drei Releases: deprecated in 1.20, Fehler mit Escape in 1.21, harter Fehler in 2.0.4.

Neues Enterprise-Plugin, das Zertifikate von öffentlichen CA-Anbietern per ACME bezieht. Vault Agent rendert Templates automatisch neu, wenn ein solches Zertifikat ausgestellt oder erneuert wird. Damit laufen interne und öffentliche Zertifikate durch denselben Verteilweg.

Die neue Listener-Option max_token_header_size begrenzt X-Vault-Token- und Authorization-Bearer-Header, Default 8 KB. Derselbe Wert wird als MaxHeaderBytes des HTTP-Servers gesetzt und begrenzt damit den gesamten Request-Header. -1 schaltet die 8-KB-Prüfung ab, es bleibt nur die Obergrenze des Go-HTTP-Servers (rund 1 MB). Sie gilt nur am API-Listener, nicht für zwischen Cluster-Nodes weitergeleitete Requests. Wer Enterprise-JWTs oder OIDC-Tokens mit großen authorization_details-Payloads nutzt, misst vor dem Upgrade die größten Tokens samt übriger Request-Header und hebt den Wert an.

Die Option hat seit 1.20.0 keinen Default mehr. Wer Integrated Storage nutzt und disable_mlock nicht ausdrücklich auf true oder false setzt, dessen Vault-Server startet nicht. Trifft jeden Sprung von 1.19 auf 1.20 oder später, also auch den Weg aus der LTS-Linie auf 2.x.

Der Listenvergleich wechselt von exact match auf contains all. Policies, die Parameterlisten einschränken, können danach mehr durchlassen als beabsichtigt. Betroffene Policies neu bewerten, nicht nur syntaktisch prüfen.

Die CRDs HCPAuth und HCPVaultSecretsApp sind mit Controllern, RBAC und Helm-Assets entfernt, HCP Vault Secrets ist seit 01.07.2026 end-of-life. Vorhandene Instanzen vor dem Upgrade löschen, sonst bleiben sie wegen des Finalizers hcpvaultsecretsapp.secrets.hashicorp.com/finalizer in Terminating hängen.

spec.syncConfig.instantUpdates funktioniert jetzt für jede Secrets Engine, die Vault-Events sendet, sowohl für Static Roles (allowStaticCreds=true) als auch für dynamische Leases. Event-getriggerte Reconciles von VaultStaticSecret und VaultDynamicSecret senden den X-Vault-Index-Header, damit Performance Standbys keine veralteten Werte liefern (ab Vault 1.20).

Mit controller.rbac.enabled=false legt das Chart weder ClusterRole und Role noch die Bindings an, die RBAC-Objekte muss dann der Cluster-Admin vorab provisionieren. 1.6.0 behebt außerdem einen falschen API-Pfad, durch den jede Zertifikatsanforderung aus VaultPKISecret mit gesetztem issuerRef auf 404 lief, und löst rolloutRestartTargets bei Static Roles mit allowStaticCreds: false nicht mehr bei jedem Reconcile aus, sondern nur, wenn sich die Credentials tatsächlich ändern.

spec.appRole.secretIDPath in VaultAuth und VaultAuthGlobal ist ersatzlos entfernt. Stattdessen spec.appRole.secretRef verwenden, das auf ein Kubernetes-Secret mit der AppRole Secret ID zeigt. Manifeste vor dem Upgrade umstellen, sonst schlägt die Authentifizierung fehl.