Keep your secrets secret!

Posted by Matthew Bradley

If I was to ask whether you wanted your passwords to be kept secure, I’m certain there would be a 100% response rate of ‘yes’. It seems a silly question to ask really doesn’t it? Of course you want your passwords to be secure. Yet, I see a worrying number of instances where this just isn’t the case!

Now, I’m not talking about making sure you have a strong password or not using the same password to access all resources and accounts…blah blah blah (but how many people are guilty of that!).

This blog post will be focused on keeping passwords safe by using Azure Key Vault when deploying Azure resources with ARM templates.

If you ask anyone how you should create resources in Azure, very few people will tell you to use the portal. It makes the process longer, you risk having non-standard builds and it increases the risk of human error. The best way to deploy resources is with ARM templates (JSON scripts to declare what you want your environment to look like), that you run rather than clicking options for half an hour.

Azure make the process of manually creating basic templates really really simple. All you need to do is go through the portal once as if you’re creating a resource…then rather than clicking ‘deploy’ at the final stage, you have the option to download the template files to create that resource. This template can then be used as a ‘cookie cutter’ to deploy multiple resources in future. Simples.

When you download these template files, the default value for the admin password is set to null, which is secure. Great. You just manually type the password in when you execute the deployment. However, the whole point of templates is to remove the need to manually enter information, so really you want credentials to be set as part of the template. This is the stage where a little knowledge can be dangerous!

Here are a few of the things that I have actually seen that keep me up at night:

Building your own template files:

NO! JUST NO! This makes baby Jesus cry! Never ever ever store passwords in plain text. And setting the parameter type as ‘securestring’ does not make your password secure. Get in the bin!

Using pre-built template files from online repositories:

Places like git are an amazing place to get templates from and, in some instances, you can build entire environments with a single copy and paste. After all, if you’re trying to build something, the chances are that someone else has already built it. You should definitely make use of repositories like this, but PLEASE check how credentials are being generated and try not to leave them too generic.

If you set the password to your Subscription ID then someone who has read-only access to your account will be able to guess your passwords and access your systems. Always change the default value for the password any time you’re using a template that you haven’t written yourself!

So what do I use? If you’re going to take security seriously then you need some type of secret store to maintain account passwords. Having passwords in someones head or stored in a password protected spreadsheet isn’t something that should even be considered. There are plenty of 3rd party tools for this, but if your builds are done in Azure then you should aim to use Azure products….enter Azure Key Vault!

Key Vault can store keys, secrets and certificates for IaaS and PaaS, however we’ll just be looking at secrets here. Secrets are really simple to add and it is just a key-value pair. You give the secret a friendly name (which is how you will reference it) and set the password as the value. Access to Key Vault should be restricted to ‘owners’ and it gives others the ability to set passwords on products without actually knowing what that password is! They just reference the name of the secret and never see what the value of that is.

And its really easy to implement!

You create the Key Vault by searching the list of services in the Azure portal, enable it to be used for deployment (tick boxes) and add your secrets to this.

Then you simply need to reference the Key Vault and secret name in your JSON files:


The KeyVault ID can be copied from the ‘properties’ section of your Key Vault. So when this executes, it connects to your Key Vault store and uses the secret that you have set for the name ‘SQLAdminPassword’.

You can also dynamically generate Azure Key Vault secrets as part of the deployment. However, that uses nested JSON and I don’t want to go that deep into JSON for this blog.

If you’re interested in implementing this and have any trouble with the setup then drop me a message.

Back to Blog