Training Module

HashiCorp Vault – Secrets Management Grundlagen

In diesem 2-Stunden-Modul löst ihr das Problem, das die meisten Teams kennen: Passwörter, API-Keys und Zertifikate liegen in Klartext-Dateien, Umgebungsvariablen oder Base64-kodierten Kubernetes-Secrets – nichts davon ist verschlüsselt, versioniert oder nachvollziehbar. Ihr startet einen echten Vault-Server im Dev-Mode und lernt die Kernkonzepte Sealed/Unsealed, Storage Backend und die KV-Engine v2 kennen, schreibt und versioniert Secrets, richtet mit Policies und AppRole-Auth einen geltungsbereichsbeschränkten Maschinen-Zugriff ein und prüft live, dass ein zu weit gefasster Zugriff tatsächlich abgewiesen wird. Ein Konzeptblock ordnet Vault gegenüber Kubernetes-nativen Secrets (Base64, keine Verschlüsselung) ein und zeigt den Vault Agent Injector bzw. den External Secrets Operator als Brücke – ohne dass in dieser Session selbst etwas gegen Kubernetes deployt wird. Zum Abschluss aktiviert ihr das Audit-Log und lest eine echte Log-Zeile. Die komplette Session läuft ausschließlich über vault server -dev auf eurem eigenen Rechner: kein Cloud-Account, kein Cloud-KMS und kein produktives Storage-Backend – das ist bewusst außerhalb dieses Trainings (siehe Abgrenzung unten).

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

2 Stunden, live (remote oder vor Ort), Input & Hands-on

Teilnehmende

DevOps-/Platform-Engineers, die Secrets aktuell in Klartext oder Base64 verwalten und zentrales Secrets Management kennenlernen wollen

Voraussetzungen

Linux-CLI-Grundkenntnisse, kein Vault-Vorwissen nötig. Kein eigener Cloud-Account nötig – die gesamte Session läuft über vault server -dev auf dem eigenen Rechner.

Warum dieses Training für deine Organisation wirkt

Rotation ohne Klartext-Chaos

Teilnehmende schreiben ein Secret, überschreiben es und lesen anschließend gezielt die alte und die neue Version zurück – die KV-Engine v2 versioniert automatisch, ohne dass irgendwo eine manuelle Backup-Kopie in Klartext liegen muss.

Geltungsbereich statt Alles-oder-Nichts

Statt einem Dienst einen Root-Zugriff zu geben, bauen Teilnehmende mit Policy und AppRole-Auth einen Token, der ausschließlich den eigenen Pfad lesen darf – und sehen live den 403 permission denied, wenn dieser Token einen anderen Pfad oder einen Schreibzugriff versucht.

Jede Aktion nachvollziehbar

Mit aktiviertem Audit-Log landet jeder Zugriff als JSON-Zeile mit request.path und Operation im Log – Teilnehmende lesen die eigene, gerade ausgeführte Aktion direkt aus einer echten Log-Zeile heraus.

Was Teilnehmende mitnehmen

  • Vaults Kernkonzepte einordnen: Sealed/Unsealed, Storage Backend, KV-Engine v2 – und warum Dev-Mode dafür reicht, ohne produktiven Storage-Backend-Betrieb zu behandeln.
  • Einen Vault-Server mit vault server -dev starten und den Server-Zustand über vault status lesen.
  • Secrets in der KV-Engine v2 schreiben, lesen und gezielt eine ältere Version zurückholen (vault kv get -version=1).
  • Eine Policy als HCL-Datei schreiben und mit vault policy write hochladen.
  • AppRole-Auth aktivieren, eine Role anlegen und daraus role_id/secret_id erzeugen.
  • Sich über AppRole einloggen und live prüfen, dass der entstandene Token nur genau den freigegebenen Pfad lesen darf – jeder andere Zugriff wird abgewiesen.
  • Kubernetes-native Secrets (Base64, keine Verschlüsselung) gegen Vault als zentralen Secrets-Speicher einordnen, inklusive Vault Agent Injector/External Secrets Operator als Brücke – als Konzept, ohne eigenen Kubernetes-Hands-on-Block.
  • Das Audit-Log aktivieren und eine reale Log-Zeile mit request.path lesen.

Für wen dieses Modul ideal ist

  • • DevOps-/Platform-Engineers, die Secrets aktuell in Klartext-Dateien, Umgebungsvariablen oder Base64-kodierten Kubernetes-Secrets verwalten
  • • Teams, die vor der Einführung eines zentralen Secrets-Speichers stehen und erst die Kernkonzepte verstehen wollen, bevor sie produktiv einsteigen
  • • Alle mit Linux-CLI-Grundkenntnissen, die kein Vault-Vorwissen mitbringen müssen

Rahmendaten

  • • Dauer: 2 Stunden live (remote oder vor Ort)
  • • Format: Input, Live-Demo, Hands-on-Übungen entlang der Vault-CLI
  • • Voraussetzungen: Linux-CLI-Grundkenntnisse, kein Vault-Vorwissen, kein eigener Cloud-Account nötig

Modulaufbau & Agenda

  1. Warum Secrets Management, Vault-Kernkonzepte (20 min): Sealed/Unsealed, Storage Backend und KV-Engine v2 im Überblick. Hands-on: vault server -dev starten und den Serverzustand über vault status lesen.

  2. KV-Engine v2 Hands-on (30 min): Ein Secret schreiben, lesen, überschreiben – und anschließend gezielt die alte Version neben der aktuellen abrufen. Zeigt Vaults eingebaute Versionierung an einem echten Beispiel.

  3. Policies & AppRole-Auth (30 min): Eine Policy-Datei schreiben und hochladen, AppRole-Auth aktivieren, eine Role mit role_id/secret_id anlegen, einloggen und live prüfen, dass der entstandene Token nur den freigegebenen Pfad lesen darf.

  4. Konzept-Block, kein Hands-on (20 min): Kubernetes-native Secrets (Base64) gegenüber Vault als zentralem Secrets-Speicher einordnen, inklusive Vault Agent Injector und External Secrets Operator als Brücke zu Kubernetes.

  5. Audit-Log (20 min): Audit-Device aktivieren, eine vorherige Aktion wiederholen und die entstandene Log-Zeile gemeinsam lesen.

Hands-on Inhalte (Auszug)

Vault-Kernkonzepte & Setup

  • Sealed/Unsealed und Storage Backend als Konzepte
  • vault server -dev lokal starten, kein Cloud-Account nötig
  • vault status lesen (u. a. Sealed: false)

KV-Engine v2 & Versionierung

  • vault kv put secret/app/db password=…
  • vault kv get secret/app/db liefert immer die aktuelle Version
  • vault kv get -version=1 secret/app/db holt gezielt eine ältere Version zurück

Policies & AppRole-Auth

  • Policy-Datei mit capabilities = [“read”] auf genau einen Pfad
  • vault auth enable approle, Role mit token_policies
  • Login mit role_id/secret_id → geltungsbereichsbeschränkter Token

Audit-Log

  • vault audit enable file file_path=…
  • Eine vorherige Aktion wiederholen
  • Log-Zeile mit request.path und Operation gemeinsam lesen

Abgrenzung zum Modul “Kubernetes Security Vertiefung”: Dieses Training behandelt bewusst kein Kubernetes-Deployment (kein Vault Agent Injector- oder External-Secrets-Operator-Hands-on gegen einen echten Cluster), kein Cloud-KMS und kein produktives Storage-Backend – ausschließlich der lokale Dev-Mode. Wer Kubernetes-seitige Secrets-Encryption-at-Rest gegen etcd vertiefen will, findet das im Aufbaumodul Kubernetes Security Vertiefung — Pod Security Admission & Secrets-Härtung.

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zum ersten funktionierenden Stack, Ergebnis der Hands-on-Übung) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir passen die Hands-on-Übung auf euren Erfahrungsstand und eure Zielumgebung an.

Academy Briefing anfragen