Mitglied werden – KI-Tutor mit vollen Antworten

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).

Teil der Cybersecurity-Weiterbildung: Querschnitt aus DevSecOps, Docker, Kubernetes und Secrets-Management.

Academy Briefing vereinbaren

Oder sofort per Mail an mail@mhm-dl.de

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. Dynamic Secrets über die Database Secrets Engine, die PKI Secrets Engine, den Vault Agent Injector gegen einen echten Cluster sowie das Produktionsbetrieb-Konzept Raft-HA und Auto-Unseal vertieft das Aufbaumodul Vault Fortgeschritten: Dynamic Secrets, PKI & Produktionsbetrieb.

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