Secret Management

• Lokal (.env): Entwickler haben eine .env Datei (diese wird von .gitignore ignoriert!). dotenv lädt sie beim Start.
• CI/CD (GitHub Secrets): In den Repo Settings trägst du AWS_KEY ein. Die Pipeline injiziert sie beim Build.
• Cloud (Parameter Store): AWS SSM Parameter Store speichert Configs und Secrets verschlüsselt.

1. HashiCorp Vault

Der Gold-Standard (aber komplex). Vault speichert nicht nur statische Secrets. Es kann Dynamic Secrets. App: "Ich brauche DB Zugriff". Vault: Erstellt einen User app-user-123 in Postgres (mit 1h TTL). Vault: Gibt Passwort an App. Nach 1h löscht Vault den User wieder. Selbst wenn das Passwort geklaut wird, ist es bald wertlos. "Identity based Security".

2. Secret Sprawl & Scanning

Entwickler vergessen .gitignore. Secrets landen in der Git History. Tools wie TruffleHog oder Gitleaks scannen jeden Commit auf Muster (Regex für AWS Keys, Private Keys). Sie blockieren den Push (Pre-Commit Hook) oder alarmieren sofort. "Jedes Secret im Git muss als kompromittiert betrachtet und sofort rotiert werden."

3. Hardware Security Module (HSM)

Banken und CAs vertrauen keiner Software (könnte Bugs haben). Sie nutzen HSMs. Spezielle Hardware-Chips (FIPS 140-2 Level 3 zertifiziert). Der Key verlässt niemals den Chip. Verschlüsselung passiert auf dem Chip. Wenn du versuchst, das HSM aufzubohren, löscht es sich selbst (Tamper Detection). Cloud Provider nutzen CloudHSM für ihre Vaults im Hintergrund.

Shamir's Secret Sharing (Unseal Process)

Wenn HashiCorp Vault neu bootet, ist der gesamte Tresor-Speicher selbst kryptografisch versiegelt (Sealed). Da Hardware-Vaults es ablehnen, einen "Master-Key" in der Config zu speichern (Hacker!), wird eine hochkomplexe Mathematik von Adi Shamir eingesetzt. Der Master-Key aus dem RAM wird beim Setup in z.B. 5 Teilschlüssel (Shares) zerrissen. Das Prinzip verlangt ein mathematisches Polynom-Threshold: Um den Tresor zu entschlüsseln ("Unseal"), müssen zwingend 3 von diesen 5 Schlüsseln eingegeben werden. Keines der Teilstücke allein offenbart auch nur einen Bruchteil des Keys. Diese 5 Shares gibt man fünf getrennten Security-Offices – ein Rogue Admin kann niemals das System aufbrechen.

External Secrets Operator (K8s)

Native Kubernetes-Secrets stehen faktisch als Base64-Strings in der etcd-Datenbank (Katastrophe bei Fehlkonfiguration). Zudem ist der manuelle Copy-Paste-Prozess furchtbar. Der Industriestandard heißt heute External Secrets Operator (ESO). Der K8s-Controller lauscht auf Manifeste (ExternalSecret). Statt das Secret im Git anzulegen, zieht der Operator das geheime Feld per gRPC/API direkt live "Just-In-Time" aus dem AWS Secrets Manager (oder Azure KeyVault). Das Cluster-YAML enthält nur Referenz-Pfade (remoteRef: key=MyDatabasePass). Wenn sich das Passwort in der Cloud rotiert, drückt ESO das native K8s-Secret ohne Reboot ins System oder rollt bei Deployment Pods direkt neu hoch.

Sidecar Vault Injection (Zero Trust via Mutating Webhook)

Selbst Native-Secrets-Mounts als Files (/tmp/secret) sind auf Nodes unsicher (Prio LFI-Angriffe auf Kubelet). Spezialisten injizieren den Hashicorp Vault Token direkt. Der Kube-API Mutating Admission Webhook beraubt beim Start eines Pods den yaml-Schnitt und pumpt im laufenden Flug einen kleinen Sidecar-Container ("Vault-Agent") mit hinein. Dieser Agent authentifiziert sich direkt am Vault über seine K8s SA Token-Identität und schreibt das fertige Secret in ein nur im RAM lebendes Memory-Volume tmpfs. Die Haupt-App liest das RAM-File. Der Container stürzt ab - die Spuren der Keys verpuffen sofort. Zero Footprint auf Storage Disks.