In last week’s learning, I mentioned that I’d figured out how to utilize Azure Key Vault secrets in a bicep deployment. This isn’t exactly earth shattering, but I thought it was fun. The practical applications are numerous. In last week’s case, I was building an IPSec VPN tunnel and wanted to have the pre-shared key available in key vault as I built the VPN tunnel and the rest of the infrastructure.
Getting there takes a couple steps…
To start, let me just say that Microsoft does have good documentation around this, but I found it took some hands-on to truly understand what I was doing, and how the darn thing was supposed to work.
For this example, I’m going to provide the bare minimum code necessary to show the process. I’m going to extract a secret from Key Vault and use that secret name to build a virtual network. Ludicrous, right? What we do with the secret doesn’t really matter though – it’s how we get that secret and leverage it in code that matters.
To start, I have a basic key vault named kv-vault01 with a secret named ‘networkname'
Be sure you’ve allowed ARM deployments to the vault – you’ll find that setting below. Failing to do this will result in your code unable to pull secrets.
That’s all the pre-requisite work. Now we’ll build two bicep files, and I’m going to describe them in reverse order from how they’re called.
The role of this file is to build a virtual network using a minimum set of parameters. Line 1 and 2 combine to create the secure parameter called name, the value of which will ultimately come from the key vault secret. This seems to be the only way to actually use a secret from key vault. It must be declared as a secure parameter.
So how do we get to this file? Think of that as a separate function or module, and we’ll call it from a main bicep file that will be used in the deployment.
In the first block (lines 1 through 3), we’re simply making a reference to an existing key vault named kv-vault01.
On line 5, you can see that instead of using the 'resource' identifier, we’re using 'module' and calling the name of a bicep file. Lines 7 through 10 you can see the parameters that the 'vnet.bicep' module wants, and line 8 is how we get the key vault secret.
It’s important to state that the getSecret() function can really only be used in this context. You can get the secret only when passing that secret as a parameter to a module. So anytime you may want to use a secret, be sure to split out your bicep code so that you’re getting the secret and passing it off to a module.
If you’re not familiar with how to run the above, it’s actually quite straightforward:
New-AzResourceGroupDeployment -Name "deployment-name" -ResourceGroupName "rg-tester" -TemplateFile .\main.bicep
The deployment name (“deployment-name” in my example) can be anything and the resource group name (“rg-tester” in my example) needs to be a pre-existing resource group. If you’re following along, and have the pre-requisites taken care of, you should get a successful deployment:
In this example the value of the key vault secret was indeed secretnetwork, so that worked precisely as expected. It’s not fancy, it’s not flashy, but it works. #BattleFaction.