Sleep Worry-Free: The best tips for Local Secrets Management 💤

In this post I will share a couple of tips with regards to Secrets Management in your (local) dev environment. Personally I use these to prevent / limit leaking of secrets while developing Azure infrastructure. And I consider them as part of my security hygiene during the development process.

Use Case

When you are either building new Azure Infrastructure or debugging an existing configuration you will eventually need to use a secret or a password on you local (dev) environment. The most straightforward approach that is often used is to create a new variable and add the secret as a value to this variable. Effectively (temporarily) hardcoding the secret value into whatever you are working on. The following example sows such an approach, it should be quite familiar to everyone who worked with Azure and PowerShell in the past.

In this example the secret is part of a temporary or a one time use script created to establish a connection with Azure. Which is needed to for example carry out a deployment. What happens after such a script is used is where the risks lie. More often then not the secrets are left part of the script with the intent to remove them later on, however due to various reasons like time pressure this never happens and in some cases another debug snippet is added to the same or a new file with in some cases new set of secrets.

Secrets used in such way have become un-managed and pose a potential security security risk. Take the following scenario’s as examples of how this can cause the secrets to be leaked.

1. The script with the secret can ben accidentally checked in making it available to everyone who has access to the repository in question.
2. The engineer forgets about the secret leaving it hardcoded in the file which on a much later moment is shared with others as its just a simple draft.
3. The engineer shares his screen allowing for a screenshot to be taken or the whole thing recorded.

Thankfully there are a multiple actions that can be taken to reduce and even prevent this. The next chapter describes my method for Secrets Management.

How to manage your secrets - private config

This method is what I consider a structured approach to organizing a repository. In essence it is an implementation of the separation of credentials from code practice. To achieve this my repositories always have the folder set-up as shown in the next example.

The tools and references folders contain any tools and any reference material used by the code in the rest of the repo. The personalScripts folder is the folder that is used by the team and me for any temporary and one time use script. Such as snippets to connect to Azure, Azure DevOps or as a simplified controller to call external functions during debugging.
I always start by adding this folder .gitignore to ensure no accidental check-in’s which result in secret leaking. The readme.md in this folder is excluded from .gitignore and is part of source controlled files. It contains a description of how to use this set-up.

This is the .gitignore snippet for such a set-up:

jevs.private.config.json

This is the file I use to store all relevant credentials, secrets and other type of GUID and id’s which are relevant for the task at hand. I use json as it is really easy to work with when combining it with PowerShell. Putting all the sensitive information which is required for my task in a single file and combining it with .gitignore guardrails allows me have Managed Secrets.

Jevs-Playground.ps1

This is my throw away / one time use PowerShell script which a I modify to fit my task at hand. It contains a header region which is relatively static as this region loads the values from the just mentioned jevs.private.config.json.. The script can be seen next.

Wrapping up

And there you have it, the best tips I can share from my own experience about managing secrets in a local (dev) environment. As always, a big thanks for reading this post. If you liked it, don’t be shy and have a look at my other posts .