Storing secrets in scripts is a no-go since forever and therefor many workarounds exist to store credentials, API-keys and other secrets somewhere else to prevent them from getting stolen or compromised.
I personally prefer Export/Import-CliXML to store credentials on disk (on a secure place) as they use some user-key for encryption. But with PS Core and multiplatform support, PowerShell needs a better way to allow secure scripting which works also on all three platforms Windows, Linux and macOs.
To overcome this, Microsoft is developing the SecretManagement Module and some modules to store secrets, i.e the SecretStore Module.
As Microsoft announced the release candidates of the modules, i thought its a good time to dive into it.
The basic idea is to create a secret place for secrets which can only be accessed by the user actually loggin in (of the credentials a script is scheduled).
In this blog you will learn about the architecture of the technology, practical examples follow in Part 2.
A schematic overview on the 2 modules
As shown in the schema above, the main module is the SecretManagement Module. It contains all CmdLets to manage vaults and store and retrieve secrets.
The SecretStore Module is one of the hopefully many (in the future) modules that provides the ability to store vault types. It is shipped with 5 CmdLets to set/reset a configuration for the vaults.
PS: Every future to-be-shipped store-module will be shipped with those five CmdLets for their specific platform, but more on this later . . .
The masterplan for secrets and stores
From my understanding, the big idea with secretsmanagement is to be able to store secrets in multiple providers, which makes the whole thing very flexible.
In the example above you see that there are 4 different possibilities to physically store secrets. Filesystem is shipped my Microsoft, the KeePass Module is developed by Justin Grote. Maybe there will be a Azure KeyVault Module. Other modules are already available on the PowerShell Gallery:
So how does this all work together ?
It took me a while to understand the idea on the split between modules and what to do with the CmdLets provided. Here are my findings
1.) You need to define a SecretStoreConfiguration
In this step you need to define HOW vaults can be accessed. This is some sort of „policy“ on vault creation and management.
2.) Create Vaults
Now as we now have defined how vaults are created and accessed , we can create them. This works with CmdLets from the SecretManagement Module (Register-SecretVault).
3.) Create Secrets in vaults
Now the (scripting)party can begin, we can store secrets in vaults and access them from the commandline or in scripts.
I hope that brought some light into SecretManagement, more on this can be found in this blog:
PowerShell Secrets Management – Part 2: Installation and first steps.
Regards/Roman
Thanks for the header picture – Photo by Stefan Steinbauer on Unsplash
