Powershell Secret Store
Tags: powershell, secret, devops
Published: 2023-01-10 10:46:34

---
title: Powershell Secret Store
published: true
description: Devops practice for managing secrets on local machine
tags: powershell,secret,devops
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8lxol1rovhxspha8d3q8.jpg
# Use a ratio of 100:42 for best results.
# published_at: 2023-01-09 18:48 +0000
---
As devops I have to use a lot of secrets for managing my projects which are complex and requires several environments (dev,sit,uat,e2e,prod...), so the number of secrets to manage can grow quickly.

Where to store secrets Its important because are critical information and incorrect management can create huge problems for the security of the applications. When deploy the application we use a secret management service like Azure Key Vault, but what can we do with secrets saved on personal machine? If you are using a simple plain text file then you are making a mistake.

A better idea is also have Key Vault on personal machine, so I decided to use [Powershell Secret Store](https://github.com/powershell/SecretStore) which is an extension vault module for the PowerShell SecretManagement module. It stores secrets locally on file for the current user account context, and uses .NET crypto APIs to encrypt file contents. Secrets remain encrypted in-memory, and are only decrypted when retrieved and passed to the user. 

Next an example of use:
```powershell
# install secret management module
Install-Module -Name Microsoft.PowerShell.SecretManagement
# install extension vault to store secrets to the local machine
Install-Module -Name Microsoft.PowerShell.SecretStore

# register a new local secret store
Register-SecretVault -Name mySecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault

# add two secrets to mySecretStore 
Set-Secret secret1 -Vault mySecretStore -Secret "this-is-the-value-for-secret1" -metadata @{"envname"="dev";"varname"="var1"} 
Set-Secret secret2 -Vault mySecretStore -Secret "this-is-the-value-for-secret2" -metadata @{"envname"="dev";"varname"="var2"}

# show the list of secrets stored into mySecretStore
PS > get-secretinfo -vault mySecretStore | fl

Name      : secret1
Type      : String
VaultName : mySecretStore
Metadata  : {[varname, var1], [envname, dev]}

Name      : secret2
Type      : String
VaultName : mySecretStore
Metadata  : {[varname, var2], [envname, dev]}

# retrieve secret value
PS > get-secret secret1 -vault mySecretStore -asplaintext
this-is-the-value-for-secret1
```
As you noted Its possible define a set of metadata for each secret, so I decided to use this capability for improving the process of secret retrieve. For example, I defined an envname for better separation of contexts and varname to automate the process of the powershell variables creation to store the secrets in memory.

I implemented this logic into a function called *Set-VariablesFromVault* which is able retrieve secrets by envname and store them into variables with name format envname_varname. Below an example of use:
```powershell
# import my functions for loading secrets
Import-Module .\ADMsecret.psm1

# create powershell variables with secret values based metadata envname and varname
Set-VariablesFromVault -vaultname mySecretStore -envname dev

# check the results
PS > get-variable

Name                     Value
----                     -----
dev_var1                 this-is-the-value-for-secret1
dev_var2                 this-is-the-value-for-secret2
......................................................
```

The code of *Set-VariablesFromVault* is available [here](https://github.com/antdimot/devops/tree/main/powershell/secret)