Shhhh, it’s a secret – Azure DevOps to KeyVault

Firstly I can’t quite believe this is the first blog going live here, it’s not what I planned initially but you can’t turn down an opportunity when it springs up!

We’re going to cover a simple and secure process for getting Azure DevOps library secrets and variables into Azure KeyVault and how to do some life cycle management.

The problem statement, I was working with a strategic partner who had the use case, that was “Users and Developers shouldn’t have access to KeyVault as standard, and support teams need to be able to rotate as required, we are also behind private endpoints so we have a no portal access policy”

So with that brief I went away and wrote a thing (Azure Pipeline), that did a thing (Ran a CLI PS script) and worked, solving the initial problem statement nice and quickly.  However, it’s not the first time I’ve had a request like this.  So I thought a longer term solution might be needed.

I started refining the deployment I’d built, also this time factoring in other important aspects like secret lifecycle management (deleting secrets), keeping the KeyVault tidy and maintained when a project might be done with a secret etc. 

What I ended up with was the GitHub Repo available for you, It will deploy any secrets in a specific ADO Library simply by adding it to the YAML mapping file and then if you remove it from the library and YAML mapping it will delete it for you.  Simply rerunning the pipeline will update all the secrets again with what is in the ADO Library.

It’s important to note this could be enhanced further and added complexity created to make this a “Best in Class” but one of the highest priorities in my eyes is adding efficient value for partners, clients, customers and anyone you’re working with.  Complexity can often cloud that.

With that a couple Gotchas have come out:

If your code deployment deploys secrerts to KeyVault and they’re not in the ADO Library and deployed through this pipeline it risks deleting them. 

The code as it stands in v0.1, doesn’t make sure the Service Principal has KeyVault secrets officer RBAC that it will need to run.  This may have changed in a future release, please see any notes.

With that head feel free to head over to the GitHub and clone the code and have a play.  Let me know any thoughts you have on LinkedIn and I hope this at very least helps you with a basic but useful tool if you’re working within Azure DevOps.