Microsoft.PowerShell.SecretManagement 1.1.0-preview

The next 1.1.0 version of SecretManagement has a number of minor fixes, but also two significant changes, one of which is a potentially breaking change for extension authors. For more information on the changes in this release, see the CHANGELOG document. This blog discusses the primary changes, why one is potentially breaking, and is especially relevant for extension vault owners who may want to test their vault and make any changes while these updates are in a preview state.

SecretManagement extension vault modules hosting change

SecretManagement extension vaults are PowerShell modules that conform to a special format. Currently, when SecretManagement loads an extension vault module for use, it loads the module into the current user session. However, this method of hosting extension vault modules prevented SecretManagement from running in ConstrainedLanguage (CL) mode. To fix this problem, v1.1.0 of SecretManagement now hosts extension vaults in a separate runspace session. Changing how the extension module is hosted, has the potential to break existing extension vaults.

What are the effects of the hosting change?

This change mostly affects extension vault authors because they can no longer assume their loaded vault module has access to current user session state. Generally, extension vaults should never rely on shared user session state. But if an extension did have this dependency, it would no longer work with this next version of SecretManagement. We tested some extension vault modules on the PowerShellGallery, but found only one module that was affected by this change (SecretManagement.KeePass).

SecretManagement.KeePass extension vault

The SecretManagement.KeePass extension vault currently relies on its module being loaded in the user session in order to support its vault unlock operation via the Unlock-KeePassSecretVault command. With the new SecretManagement version, the Unlock-KeePassSecretVault cmdlet is no longer effective, and the user is always prompted for a password when required by the vault. This can be problematic for scripts being run unattended that do not support user interaction.

The KeePass vault needed to use this user shared state approach due to a deficiency in SecretManagement. SecretManagement did not support a vault unlock operation, and required vaults that needed it to implement their own. So one of the changes in this release is to add a new extension vault function, Unlock-SecretVault, that allows extension vaults to provide this functionality directly through SecretManagement. With this new function, the KeePass vault no longer needs to leverage shared state with the user session.

New Unlock-SecretVault command

SecretManagement now supports a new Unlock-SecretVault command. Extension vaults that require unlocking can optionally support this by implementing the Unlock-SecretVault function in their extension. SecretManagement.KeePass extension vault module will be updated to use this new function, mitigating the problem. For more information see SecretManagement Readme and Design documentation.

Other differences you may notice

Since the extension vaults are no longer loaded in the user session, you will no longer see them listed when you run the Get-Module command, which lists the currently loaded modules in your session. This is arguably a good thing, since users generally don’t want or need to know about extension vault modules, and don’t need to see them in their current session. Seeing extension vault modules unexpectedly loaded in their sessions may be confusing to users.

Some extension vault modules, such as Microsoft.PowerShell.SecretStore and SecretManagement.KeePass, include additional commands for the user. The Microsoft.PowerShell.SecretStore vault provides additional commands for configuring the vault. The SecretManagement.KeepPass vault provides additional commands for unlocking and registering the vault. These commands will continue to work. When these commands are run, the extension vault module will be visible from Get-Module because the commands are run in the current user session. But that is the only time the extension vault modules will be loaded in the user session.

What is a runspace?

A PowerShell runspace encompasses the session context in which PowerShell scripts run, and can be thought of as an individual PowerShell session. The PowerShell command shell usually has just a single session, but can support any number of sessions via multiple runspaces. The runspace isolates multiple running scripts from each other within a single process.

What is CL mode?

Constrained Language is a PowerShell language mode that restricts language elements which can be used to invoke arbitrary APIs. It is commonly used within a system wide application control policy, such as Windows AppLocker or Windows Defender Application Control, that restricts what applications are available and what scripts are trusted on the system. Untrusted scripts run in ConstrainedLanguage while trusted scripts run in FullLanguage mode.

Feedback and Support

Community feedback has been essential to the iterative development of these modules. Thank you to everyone who has contributed issues, and feedback thus far! To file issues or get support for the SecretManagement interface or vault development experience please use the SecretManagement repository. For issues which pertain specifically to the SecretStore and its cmdlet interface please use the SecretStore repository.