March 19th, 2020

Secret Management Preview 2 Release

Note this blog post is the third in a series on the releases of this module:

We are excited to release a second preview of the Secret Management Module. Thanks to the tremendous feedback we received from the first preview release of this module, you will notice a number of breaking changes to the module. This release is still a preview release meaning that it is not feature complete, future releases will face breaking changes, and we are still iterating based on your feedback. It is important to also note that this version of the module is still Windows only as we are currently implementing Linux support which we hope to make available in the next preview release (and MacOS support after). Please note that because of the breaking changes this release requires a complete replacement of the Secret Management module and any extension modules. Additionally, any existing built in local vault secret can no longer be retrieved and must be re-saved.

How to Install Secret Management Preview 2

If you did not install our first preview release, open any PowerShell console and run:

Install-Module Microsoft.PowerShell.SecretManagement -AllowPrerelease

If you installed our first preview release you will want to first remove any secrets from the LocalDefaultVault. Based on feedback we changed the naming convention for secrets stored in CredMan, therefore previous secrets stored in the local vault will no longer be visible after the new version of the module is installed. (Although the user can still view/remove the old secrets via CredMan UI.) Next you will want to run Uninstall-Module Microsoft.PowerShell.SecretsManagement, this extra step is a result of the change we made to the name of the module. Finally you can run the above command Install-Module Microsoft.PowerShell.SecretManagement -AllowPrerelease to install the latest preview release of the module.

Changes in Secret Management Preview 2

New Module Name

We have removed the plurality in the module name to Mirosoft.PowerShell.SecretManagement in order to be consistent with the cmdlet name and to align with PowerShell naming conventions.

New Cmdlet Names

In addition to renaming the module, we have also removed plurality in the cmdlets. The available cmdlets in the module are now:

# Registering extension vaults 
Register-SecretVault
Get-SecretVault
Unregister-SecretVault 
Test-SecretVault # new cmdlet in this release 

# Accessing secrets 
Set-Secret # this cmdlet replaces Add-Secret 
Get-Secret 
Get-SecretInfo 
Remove-Secret

 

You will notice we renamed the Add-Secret cmdlet to be Set-Secret. This change was based on user feedback that this name better conveyed the intention of the cmldet.

You will also notice that we have added a Test-Vault cmdlet, this change allows vault extension owners to check that the vault is properly configured at registration time.

Other Changes

  • Set-Secret now has a default parameter set that takes SecureString secret input type. This way Set-Secret will always prompt safely for a SecureString. String secret types can still be passed via parameter or pipeline, but default will be SecureString.
  • PS> Set-Secret -Name MyStringToken
    cmdlet Set-Secret at command pipeline position 1 Supply values for the following parameters:
     SecureStringSecret: ********** 
    
    # Set string secret directly 
    Set-Secret -Name MyStringToken -Secret $token 
    Set-Secret -Name MyStringToken -Secret 'MyToken' 
    # Set string secret via pipeline 
    $token | Set-Secret -Name MyStringToken -NoClobber

     

  • Added SecretInformation class used to return information from Get-SecretInfo in a uniform way.
  • Changed CredMan naming prefix to ps:SecretName.
  • Added vaultName to all vault extension functions.
  • Fixed additionalParameters parameter in SecretManagementExtension abstract classes.
  • Fixed return byte[] bug in example test script extension.

In coordination with these changes we have also updated our tests and example scripts.

Next Steps

As we move towards a GA release later this year, we are using a GitHub Milestone to track issues we plan to fix. The two major work items that we are currently working toward are:

  • Linux Support (via keyring)
  • MacOS Support (via keychain)

Support and Feedback

For support on the module, feedback, or reporting a bug, please open an issue in the PowerShell/modules repo with “(Secrets Management)” specified in the issue title.

Sydney Smith, PowerShell Team

 

 

Category
PowerShell

Author

PM on the PowerShell team at Microsoft.

10 comments

Discussion is closed. Login to edit/delete existing comments.

  • Jeffrey McClain

    Just a heads up, you made a small typo in the word “Microsoft” when typing the module name:

    “We have removed the plurality in the module name to Mirosoft.PowerShell.SecretManagement”.

    Otherwise I love the article and am excited for this module to be released for general availability!

  • B. Onur Okutucu

    Thanks Sydney! It’s pretty useful indeed.
    Just one thing around Test-Vault. Shouldn’t it be Test-SecretVault or am I missing something?

    • Sydney SmithMicrosoft employee Author

      You are correct (and so is the implementation) I am updating the blog

  • J S

    If I wanted to run a script on a bunch of computers, and it mounted a network share, would I use something like this with a remote secret to retrieve the password?

    • Wil Wilder Apaza Bustamante

      this comment has been deleted.

    • Sydney SmithMicrosoft employee Author

      Thanks for pointing that out, I will update the module with links to the previous blog posts!

  • Manuel

    Cool stuff – Thanks!

  • Josh King

    This is a great update, especially the SecureString interactive input! 👍

  • Ron Howe

    Code blocks aren’t rendering properly.