Clarification Around Unlock-SecretStore and DoNotPrompt

[mattallford]

Hi Team,

Great work on this module and the SecretManagement module.

I'm likely missing something obvious, but I wanted to clarify the usage around Unlock-SecretStore and automation scenarios where user interaction isn't available/possible.

From the blog post:

The user can provide the password through an interactive prompt or with the Unlock-SecretStore cmdlet. The Unlock-SecretStore is intended for automation scenarios where user interaction is not possible.

Given the password needs to be provided to Unlock-SecretStore in every fresh session of PowerShell (assuming the PasswordRequired is set to True), what are the suggested methods in being able to provide this password securely in automation scenarios? Would we typically fall back to using commands in the Microsoft.PowerShell.security module to get and securely store the password to be passed to Unlock-SecretStore at execution time? Or depending on where it is being used (maybe in deployment pipelines), a secure variable for the store password?

Cheers, Matt.

[PaulHigin]

Good question, but unfortunately there are no easy answers. It really depends on the scenario. A secure variable in deployment pipelines (as you mentioned) is one solution. Reading a SecureString xml file object (via Import-Clixml in a user context) might be another. One reason we allow 'no password required' configuration is for automation scenarios, but here you are relying on file system protections with less security. All solutions have potential security vulnerabilities.

I would love to hear other ideas. We wanted to make SecretStore configuration secure as possible by default, but with less secure options available for flexibility.

[mattallford]

Hi Paul,

My apologies for leaving this so long without a response, and thank you for your response.

I don't think I have any other ideas, I was mainly looking for clarification on usage of that particular parameter. I believe what has been implemented provides options to meet different scenarios, based on the particular scenario and environment, with regard to what other controls may or may not be in place to protect access to the store.

[SydneyhSmith]

Closing as answered