So deployen Sie HashiCorp Vault in Kubernetes, ohne Unmengen von YAML-Manifesten zu schreiben

Jeder, der versucht hat, HashiCorp Vault in einem Kubernetes-Cluster manuell einzurichten, erinnert sich an die endlose Zusammenstellung von Deployments, StatefulSets, ConfigMaps, TLS-Secrets und Sidecar-Containern. Eine falsch gesetzte Einrückung in einer YAML-Datei — und Ihre Anwendungen verlieren den Zugriff auf Datenbanken.

Der offizielle vault-helm Chart löst dieses Problem. HashiCorp-Ingenieure haben das Deployment des Secrets-Managers in einen einzigen Chart verpackt, der alles abdeckt — von der lokalen Entwicklungsumgebung bis zum verteilten HA-Cluster.

Warum diesen Chart überhaupt verwenden?

Das Repository ist zum Standard für die Ausführung von Vault in Kubernetes geworden. Sie müssen keine Pod-Spezifikationen von Grund auf schreiben oder herausfinden, wie Sie Storage für den integrierten Raft-Konsens einbinden. Die Einstellungen sind bereits in der values.yaml-Konfigurationsdatei enthalten.

Das Tool ist nützlich für DevOps-Ingenieure und Systemadministratoren, die Secrets-Management in ihrer Infrastruktur organisieren. Wenn Ihre Services API-Keys, Datenbank-Zugangsdaten oder TLS-Zertifikate benötigen, hilft Ihnen der Chart, einen zuverlässigen Vault innerhalb von Minuten zu deployen.

Wichtige Features

Die Chart-Entwickler haben die wichtigsten Anwendungsfälle antizipiert:

• Schnelles Wechseln zwischen Betriebsmodi Sie können eine Instanz über Konfigurationsparameter vom Standalone-Modus auf ein fehlertolerantes Cluster umschalten. Für lokale Tests reicht eine minimale values-Datei aus, während Produktionsumgebungen den integrierten Raft oder eine externe Datenbank aktivieren.

• Secret-Injection über Vault Agent Injector Ihre Anwendung muss nicht mehr wissen, wie sie mit der REST-API von Vault umgeht. Der Injector fügt dem Pod automatisch einen Sidecar-Container hinzu. Dieser Container ruft Secrets ab und speichert sie im lokalen Dateisystem des Pods. Die Anwendung liest die Daten aus der Datei, ohne jemals mit dem Vault-Netzwerk zu interagieren.

• Authentifizierung über Kubernetes Auth Engine Der Chart integriert sich in den Kubernetes-Autorisierungsmechanismus. Vault verifiziert Pod-Service-Accounts und liefert Secrets nur an autorisierte Anwendungen aus.

• Komponententrennung Sie können die Serverseite, Agents und den Injector separat deployen. Dies hilft Ihnen, den Vault-Server außerhalb der Hauptanwendung zu betreiben oder nur leichtgewichtige Agents auf Worker-Nodes auszuführen.

So deployen Sie den Vault

Sie benötigen einen laufenden Kubernetes-Cluster in Version 1.29 oder neuer sowie Helm in Version 3.6+. Das Einrichten einer einfachen Release-Instanz dauert nur zwei Befehle:

helm repo add hashicorp https://helm.releases.hashicorp.com
helm install vault hashicorp/vault

Für eine echte Umgebung reichen Standardeinstellungen in der Regel nicht aus. Sie benötigen eine eigene Parameterdatei, zum Beispiel custom-values.yaml:

server:
  ui:
    enabled: true
  dataStorage:
    enabled: true
    size: 10Gi

injector:
  enabled: true

Deployen Sie den Chart mit den zusammengestellten Parametern:

helm install vault hashicorp/vault -f custom-values.yaml

Anschließend müssen Sie nur noch auf den laufenden Pod zugreifen, den Befehl vault operator init ausführen und den Vault entsiegeln.

Betriebliche Aspekte

Die Konfigurationsdatei values.yaml enthält Hunderte von Optionen. Diese beim ersten Versuch alle zu verstehen, kann eine Herausforderung sein — bereiten Sie sich also darauf vor, Zeit für das Lesen der offiziellen Dokumentation zu investieren.

Der zweite Punkt betrifft das Entsiegeln des Vault nach Neustarts. Standardmäßig startet Vault in einem versiegelten Zustand. Für die Produktion empfiehlt es sich, gleich Auto-Unseal über Cloud-KMS-Services zu konfigurieren, andernfalls müssen Sie nach jedem Pod-Absturz manuell Schlüssel eingeben.

Für wen ist dieses Tool gedacht?

Wenn Sie mit Kubernetes arbeiten und zentralisiertes Secrets-Management implementieren möchten, spart Ihnen dieser Chart Wochen an Arbeit an eigenen Manifesten.

Beginnen Sie damit, eine Testinstanz in einem isolierten Namespace zu deployen. Versuchen Sie, Injector-Annotations zu einer einfachen Test-Anwendung hinzuzufügen, und beobachten Sie, wie Secrets ohne jegliche Änderungen an Ihrem Quellcode in den Container gelangen.