PowerShell & Scripting

SecretManagement

Overview

Microsoft.PowerShell.SecretManagement ist eine Abstraktionsschicht für Secret-Tresore. Skripte nutzen immer dieselben Cmdlets, egal ob das Secret im lokalen Tresor, in Azure Key Vault oder in einem Passwortmanager liegt. Dazu kommt Microsoft.PowerShell.SecretStore als lokaler Tresor, der Secrets für den aktuellen Benutzer verschlüsselt in einer Datei ablegt.

Aktuelle Versionen sind SecretManagement 1.1.2 und SecretStore 1.0.6. Microsoft hat beide Module als funktional abgeschlossen erklärt: Es gibt nur noch Sicherheits- und kritische Fehlerkorrekturen, die Repositorys sind archiviert.

Erweiterungen (Vault Extensions) gibt es unter anderem für Azure Key Vault (Az.KeyVault, von Microsoft), KeePass, LastPass, HashiCorp Vault, den macOS-Schlüsselbund und die Windows-Anmeldeinformationsverwaltung. Weitere findest Du in der PowerShell Gallery über das Tag SecretManagement.

How it works

Das Zusammenspiel:

  1. Installation von Microsoft.PowerShell.SecretManagement und einer Vault Extension, z. B. Microsoft.PowerShell.SecretStore oder Az.KeyVault.
  2. Register-SecretVault meldet den Tresor unter einem Namen an, ein Tresor kann als Standard gelten.
  3. Set-Secret legt ein Secret ab, Get-Secret ruft es ab, standardmäßig als SecureString bzw. PSCredential.
  4. Die Authentifizierung regelt jede Erweiterung selbst: SecretStore fragt ein Kennwort ab (konfigurierbar), Azure Key Vault nutzt die Az-Anmeldung oder eine Managed Identity.
  5. Unlock-SecretVault entsperrt einen Tresor, falls er ein Kennwort verlangt.

PSReadLine kennt die SecretManagement-Cmdlets und schreibt Aufrufe wie Get-Secret trotz des Worts „secret“ in die History, weil sie keine Werte im Klartext enthalten.

Benefits

  • Keine Kennwörter im Code: Skripte lassen sich im Git-Repository versionieren, ohne Zugangsdaten preiszugeben
  • Austauschbarer Speicher: Wechselst Du vom lokalen Tresor zu Azure Key Vault, ändert sich nur die Registrierung, nicht das Skript
  • Einheitliche Syntax: Ein Get-Secret-Aufruf funktioniert für alle angebundenen Tresore
  • Plattformübergreifend: SecretStore läuft überall, wo PowerShell 7 läuft

Practical example

Ein Spediteur mit 180 Mitarbeitenden hatte in mehreren Skripten das Kennwort eines Dienstkontos für die Telematik-API im Klartext stehen. Die IT legt das Secret in Azure Key Vault ab, registriert den Tresor per Az.KeyVault und ersetzt im Code die Zeile mit dem Kennwort durch Get-Secret. Der Verwaltungsserver greift über eine Managed Identity von Azure Arc auf den Key Vault zu. Kennwortwechsel erfolgen nun zentral im Key Vault, ohne Skripte anzufassen.

Things to keep in mind

  • Für Server und unbeaufsichtigte Jobs einen zentralen Tresor wie Azure Key Vault verwenden, SecretStore ist an Benutzer und Rechner gebunden
  • Bei SecretStore ohne Kennwortabfrage bedenken, dass jeder mit Zugriff auf das Benutzerprofil die Secrets lesen kann
  • Wo möglich ganz auf Secrets verzichten und Managed Identities oder Zertifikate nutzen
  • Community-Erweiterungen vor dem Einsatz prüfen, weil sie nicht von Microsoft gepflegt werden
  • Da die Module nur noch Sicherheitsupdates erhalten, keine neuen Funktionen erwarten und die Vault Extension mit Bedacht wählen

Licensing & availability

SecretManagement und SecretStore sind kostenlos und Open Source, beide gelten als funktional abgeschlossen und erhalten nur noch Sicherheits- und kritische Fehlerkorrekturen. Kosten entstehen gegebenenfalls für den angebundenen Tresor, etwa Azure Key Vault nach Verbrauch oder kommerzielle Passwortmanager. Stand: Oktober 2026.

Conclusion

SecretManagement ist der einfachste Weg, Klartextkennwörter aus PowerShell-Skripten zu entfernen. Für Serverautomatisierung kombinierst Du es am besten mit Azure Key Vault und einer Managed Identity.

Further reading

Related articles