Microsoft Releases Alpha Version of PowerShell Secrets Management Module
PowerShell secure strings are encrypted objects that have been converted from plaintext. Secure strings protect secrets, like passwords, while they are being processed in memory. You can pass secure string objects between PowerShell scripts or .NET apps. But secure strings don’t solve the problem of how to securely store passwords that your scripts might need to access.
PSKeystore is a third-party PowerShell module that encrypts secrets using a certificate. It supports Windows PowerShell 5.1 or later, but it doesn’t currently support PowerShell Core. PSKeystore uses ‘keystores’ to store ‘items’. Keystores are simply folders on the local disk that hold one or more items. And items represent encrypted objects.
PSKeystore is relatively easy to use but it isn’t officially supported by Microsoft. There are also several other third-party modules in the PowerShell Gallery that can be used to manage secrets.
PowerShell Secrets Management Module
First announced at Ignite in November 2019, the PowerShell Secrets Management Module is now available as an alpha developer release in the PowerShell Gallery. What that means is that the module shouldn’t be used in a production environment and that it is not yet feature complete.
The new module is based on an abstraction layer in PowerShell that will help customers manage secrets in heterogeneous environments and across different cloud platforms. As it stands today, writing advanced scripts to orchestrate operations requires using multiple secrets and custom code if different platforms are involved.
During the Ignite presentation, Sydney Smith – Program Manager on the PowerShell team at Microsoft – said that the module will support multiple secret types in the form of PSCredential, SecureString, String, HashTable, and Byte. Smith said that PowerShell will work with the local user context to store credentials in a local vault, which by default is Credential Manager (CredMan) for Windows users. CredMan encrypts and stores secrets using the local user context. On Linux, the plan is to use Gnome Keyring, although it will be possible to add other local vaults using the extension model.
PowerShell will use the local vault to authenticate into any remote vaults using an extension model (SecretsVaultExtension). The vault extension model will allow you to register additional local vaults, or remote vaults. When you register a new vault, only the currently logged in user can access it. Vault extensions are implemented as PowerShell modules and can be script or binary based.
At Ignite, Smith demonstrated using Azure Key Vault as a remote vault to store secrets using the new PowerShell module. When using a remote vault, the remote provider determines who has access to the secrets stored in the vault. So, the remote vault provider is responsible for managing secret security, not PowerShell.
Smith also showed how it’s possible to use a remote and local vault in one script. As far as I’m aware, the only remote vault currently supported is Azure Key Vault. Microsoft is expecting other remote vault providers to create their own extensions to provide the necessary support for their vaults to work with the PowerShell Secrets Management Module.
An easy way to manage passwords using PowerShell
It appears that Microsoft is finally providing a simple, supported, and extensible way to manage secrets directly from PowerShell. While it’s still early days, the demos look promising and I’m looking forward to seeing this reach general availability in late spring or early summer 2020. At this point, I will take another look on Petri and show you how to manage secrets using the new module.