Using Azure Key Vault Secrets in your ARM Templates

Keeping your cloud infrastructure secure starts with some basic password hygiene practices. Now there are loads of opinions out there about passwords and how they should be used when it comes to infrastructure as code.
I’m, however of the opinion that if you have an opportunity not to use a user name and password combination then you should take it. If it’s unavoidable then generate a random password with a decent length (a 30 character complex password is generally my go-to) and stick it in an Azure Key Vault you should be safe. And NEVER EVER REUSE A PASSWORD!!!

The Problem:Developers, Application Support and Infrastructure Teams are high-value targets when it comes to the dark world of hacking. Typically because these individuals keep the keys to the proverbial castle. And therefore they need to take extra precautions when it comes to password management. I have seen loads of public repositories containing passwords in the ARM template or parameter files. Now in most of these cases, it was probably done to simplify the deployment example that they are trying to illustrate.
So my advice is not to just deploy these without changing these passwords. And also when you add these templates into your private repository don’t add passwords in there.
When developing your infrastructure using ARM Templates requires some patience when you start out. It is a really good practice to start securing your password early on and get into the habit of doing it.

The Solution: Using Azure Key Vault to store your usernames and passwords for these credentials is a really neat way to keep passwords out of your ARM templates. There are several techniques that can be used to achieve this, the one that I will be showing you will reference secrets using a static ID. Prerequisites:
You need an Azure Key Vault in your Azure Subscription. To create one follow this article.
Ensure the service principle deploying the Azure resources has, get and list permission on the Key Vault’s access policy. In the example below shows a couple of code snippets on how you go about achieving this. In the example, we have the password for a VM that we are deploying.
First, in your parameter file you define a password parameter that references your key vault: <SubscriptionID> refers to the ID of the subscription your Key Vault is deployed in. <ResourceGroupName> refers to the resource group that your Key Vault resides in. <KeyVaultName> refers to the Key Vault containing the secret value that is your password. Lastly, secretName is the secret’s key name.


Screen capture of template file (Credit Azure Docs)

Now when the template is parsed it will go and reference the secret in the defined Key Vault. Now, all we need to do is construct the parameters in our template file.

Screen capture of template file (Credit Azure Docs)

With this, configured you can call this parameter in your resource section of the template. When the template is parsed it will reach out to your Key Vault and grab the secret value and use that in the deployment.

A Good reference site for this: https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-keyvault-parameter

Happy Deploying!

Using Google Chrome Profiles to keep your single sign on accounts separate

Over the years I have accumulated my fair share of login credentials. Currently, I have four Microsoft accounts that I work with on a daily basis; all attached to different Azure directories. I had some issues in the past switching between different accounts, just because of Single-Sign-On and the way common browsers cache logins. The way I was doing it was by opening “incognito tabs” through which I was continuously logging in and authenticating. This approach did help a bit, but there was still some conflicting sticky credentials that slowed me down. I discovered a feature in Google Chrome called Profiles, which turned out to be the game changer I was looking for. I could now use this approach on a daily basis without any issues. I decided to put this blog together, although not deeply technical, to hopefully save you the time and effort in finding a resolution.

By using this feature you will be able to:

  • Share Chrome with others
  • Keep all your Chrome information separated (bookmarks, history, passwords, settings, etc.)
  • Keep your work and personal accounts separate

So here is the setup:

  1. Install the Google Chrome browser.
  2. Add a new person by following these instructions. I named my “person” with the name of the account I use to log into the Azure portal. Use what works for you.
  3. After adding a new person/profile, log into the Azure portal.
  4. Repeat steps 2 and 3 for the other logins, naming each person/profile accordingly.
  5. You now have the option of using a specific account when you need it by clicking on the profile button next to the browser bar and selecting the appropriate profile.

Ensure that you keep the logins isolated to the profiles they are meant to run in. Do not use multiple accounts for the same profile.

Have fun!