Providing credentials for a PowerShell script in a secure way has always been challenging. One of the best ways of handling this challenge is to store credentials in a vault and then design PowerShell scripts that can access secrets from within the vault on an as-needed basis. In this article, I will show you how to do it.
Terms to know
Before I show you how this works, I want to take a moment and clarify a few terms. A vault is essentially just a secure repository for storing sensitive information — in this case, secrets. A secret can be thought of as a password. Technically, a secret could be just about anything, but secrets are often used as a password alternative.
A secret is generally made up of two parts — its name and the secret itself. Let’s suppose, for example, that I wanted to store my password as a secret. The secret name can be just about anything, but it’s usually something that reflects the secret’s purpose. In this example, I might name the secret after myself and call it Brien. I would then set the value of the secret to match my password.
Working with vaults
So now that I have explained a little bit about secrets and vaults, let’s look at how PowerShell works with these types of objects.
The first step in the process is to install the secret management module and the secret store module. Both modules are required for PowerShell to be able to interact with a secret vault. To install these modules, enter the following commands:
Install-Module Microsoft.PowerShell.SecretManagement Install-Module Microsoft.PowerShell.SecretStore
You can see how what this looks like in the image below.
Once the modules have been installed, the next step is to register a secret vault. This is done by way of the Register-SecretVault cmdlet, which is included in the SecretStore module that you just installed. To create the vault, you will have to specify the module name, but you will also have to assign a name for the vault. For the sake of demonstration, I am going to call the vault MyVault. Here is the command:
Register-SecretVault -Name MyVault -ModuleName Microsoft.PowerShell.SecretStore
Here is what it looks like when you create the vault.
Now that you have created a vault, you can associate a secret with the vault. To do so, you will need to provide the vault name, a name for the secret that you are creating, and of course, the secret itself. Here is an example:
Set-Secret -Vault MyVault -Name Example -Secret “TopSecret”
It’s worth noting that PowerShell’s wording is a little bit confusing because it makes it sound as though you are creating a vault within a vault. You are also prompted to provide a password for the vault. You can see what this entire process looks like in the figure below.
So now that we have added a secret to the vault, the big question is, how do you get it back out? Remember, for the purposes of this article, I am essentially treating a secret as a password. As such, let’s pretend that a PowerShell script needs credentials to perform some sort of operation and that the example secret that I created earlier contains those credentials. Here is one way of retrieving the secret from the vault:
$Secret = Get-Secret -Vault MyVault -Name Example -AsPlainText
As you can see, I have created a variable called $Secret. I then mapped this variable to the Get-Secret command. I also had to append the vault name and the secret name so that Windows knows which secret to retrieve and where to get it from. Finally, I am retrieving the secret as plain text just so that I can show you how this works. If you look at the figure below, you can see the Get-Secret command, as well as the contents of the $Secret variable. The variable contains the secret (TopSecret) that I wrote to the secret named example.
Another thing that you’ll notice is that when I retrieved the secret from the vault, I was prompted to enter the vault’s password. Occasionally you may find that this simply isn’t a good option. In fact, prompting for a password can cause some scripts to break. In those types of situations, you can use the Unlock-SecretStore cmdlet to unlock the secret store. This will cause the secret store to be unlocked for an hour or until the end of the session, whichever comes first. Because the Unlock-SecretStore cmdlet also prompts you for the vault’s password, you would generally want to run this cmdlet prior to executing a script that needs to retrieve a secret from the vault.
One last thing that I want to mention is that the techniques that I have discussed only work if you can remember the name of the secret that you want to use. If you need to be reminded which secrets are stored in the vault, you can enter this command:
This cmdlet will tell you the names of the secrets that you have created and which vault each secret is stored in. However, this command does not expose the secret itself. (Remember, you need the vault password to access secrets.)
If you have too many secrets in your vault, PowerShell can help
Occasionally, you may find that you start accumulating too many secrets to keep track of all of them. In those types of situations, you can append a metadata description to the secret. The technique works exactly the same as creating a secret, but you append the -Metadata parameter to the Set-Secret cmdlet along with a key/value pair (such as Description = “admin password”). The figure below shows how this works. The metadata is not shown by default, but if you append the Select-Object cmdlet, you can force PowerShell to show you the metadata for a secret.
And as you can see in the image above, I have appended metadata to a secret.
Featured image: Designed by Upklyak / Freepik