What are the good options to manage sensitive info in Azure Bicep?

Hello Cloud Marathoners,

Every seasoned IT professional knows that sensitive information should not be exposed as a clear text on any code. This is especially true for infrastructure-as-code (aka, IaC) scenarios where passwords and keys are part of the deployment.

One way to stay compliant in accomplishing this goal is the integration of an Azure Key Vault service into your deployment code. This Azure security service is primarily intended to store sensitive information like password, keys, certificates, connections, etc.

In this post, we will look into two different ways how we could integrate Azure Key Vault services in our Azure Bicep code.

Option – 1: Using getSecret() function

Our first option is to delegate this important work to a getSecret() function. This option could be used with an existing Azure Key Vault resource that is declared in your Azure Bicep code.

Let’s look into an example where an existing Azure Key Vault service is referenced to provide administrative password for SQL server deployment.

Deploying Azure SQL instance with Azure Key Vault

This sample Bicep code is using sqldb.bicep file as a module, where parameters; such as sqlServerName and adminLogin are passed through with a secret name of ExamplePassword.

The ExamplePassword secret name should be already set and ready in the referenced Key Vault service above. Here is the view of this secret on Azure portal.

Azure Key Vault with secretes in portal

Let’s have a quick view into the sqldb.bicep file, as it is referenced in the main Bicep file.

sqldb.bicep file

Now, let’s deploy these resources with a secret value from Key Vault resource that has a secret name ExamplePassword.

What happened? I am getting an error on my first deployment execution 🙁

Error on deploying Bicep code with SQL server provisioning

Upon carefully analyzing error, I see the following reason for this error:

At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.”,”details”:[{“code”:”RegionDoesNotAllowProvisioning”,”message”:”Location ‘East US 2’ is not accepting creation of new Windows Azure SQL Database servers at this time.

Azure deployment error

Based on the error message, we change the location to eastus and re-run the script. Now, we got the following positive result in console and portal:

Deployment results in Azure Portal RG

Next, we will attempt to login into a SQL Server instance.
A successful login will look like the following screen:

Successful login into the SQL instance

Important Note:

If you are getting an error during the login then try to check the following steps:

  • adminLogin name is entered correctly
  • your IP address is added to the SQL server firewall rules
  • grab a cup of coffee and check back in 5 minutes

Description of a typical login error into a SQL server instance is provided below. I checked the firewall rules and made a cup of coffee => before getting a successful log-in 🙂

Requires your location IP activation

Option -2: Referencing as a secretName in parameter

The second option is pretty straightforward, if you have already used it on ARM template deployments.

Note: Please check out the following post – Four parameterization options for your Azure Bicep deployments for detailed information on available options.

We just need to reference Azure Key Vault secret like in the following example:

Using a parameter file and referencing the Key Vault secretName will do the trick in extracting the value and provisioning your resource.

Let’s run the bicep file that deploys multiple RGs and an Azure VM that uses VMPassword secret.

Running deployment with Bicep parameter file

A successful deployment provisions following RG with the VM resources:

Next, we should smoke test our deployment by locating the resource group “rg-demo-vm-1116” and using deployment parameters to RDP into Windows server:

Finally, we are able to see that secret and admin user name pair worked as expected

Azure VM deployed using Key Vault secret


In this post, we looked into two available options that harden our infrastructure code by removing hard-coded sensitive information and replacing it with Azure Key Vault reference. Thus, avoiding any potential leaks of passwords, secrets, etc.

IMHO, first option is better than the later one, because it does not expose subscription id and other small details.

What will be your choice? Please, share on LinkedIn post comments section.

Thank you for your interest my #cloudmarathoner friends!
Please, check other Azure Bicep posts and let me know your feedback.

What is next?

All code samples and presented Bicep files are placed in “Learn-Bicep” GitHub repo 👉 https://lnkd.in/ds-h9VQx

Please, join me to learn more about Azure Bicep 💪 on an Omaha Azure User Group meetup scheduled to happen on November 17th.

 2,443 Reads

Leave a Reply

Your email address will not be published. Required fields are marked *