Category: Infrastructure as Code (IaC)

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.

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.

Let’s have a quick view into the sqldb.bicep file, as it is referenced in the main 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 🙁

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:

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

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 🙂

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.

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

Summary

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.

 3,496 Reads

Hello Cloud Marathoners,

In my last posts, I wrote about Azure CL and a Bicep language. The Azure Bicep language, helps to author and manage Azure resources more cleanly and easily on your Azure subscription.

The parameterization of infrastructure deployment files is an important skill where true power of automation and code reuse comes forward.
Let’s learn about different parameterization options that you could use in your Azure Bicep deployments. As an example, we will examine the following parameterization options on an Azure Bicep web app deployment file.

✔️ Using Bicep file as is

✔️ Using default parameters on your bicep file

✔️ Simply adding parameters into your command line

✔️ Using a separate file for parameters, per environment

Option 1: Using Bicep file as is

This first option is the most straightforward way to declare your parameters. However, you would have to enter each parameter name, every time you are deploying the Azure resources.

Following screenshot is a default Bicep web app declaration with parameters. Check the Learn Bicep repo here 👍

Now, let’s declare an Azure CLI command that will deploy our Azure Bicep file into a Resource group.

# Create a rg-test-deploy RG
az group create -l eastus -g 'rg-test-deploy'

# Option-1: Run deployment file as is
az deployment group create -g 'rg-test-deploy' -f .\param-files\webapp-service-w-param.bicep

# List all webapps in the subscription
az webapp list --query [].name -o table

Option 2: Using default parameters on your bicep files

The second option will allow us to deploy our Bicep file without entering the default values each time. However, it would require an update on file each time you want to change parameter values 😢

Now, we can take the previous webapp-service Bicep file, and add its default values. The updated Bicep file will look like the following screenshot:

Our Azure CLI deployment script would just get a new file name

# Option-2: Run deployment with default values
az deployment group create -g 'rg-test-deploy' -f .\param-files\webapp-service-default-param.bicep

# You could also add preflight check with "-c" at the end of each deployment script

Option 3: Simply adding parameters into your command line script

If you would prefer to type parameters and values on a terminal then third option can deliver it for you. That script will look like the following sample:

# Option-3: Run deployment with inline parameters
az deployment group create -g 'rg-test-deploy' -f .\param-files\webapp-service-w-param.bicep -p location='eastus' appServiceAppName='param-demoapp18' appServicePlanName='asp-param-demo'

Option 4: Using a separate file for parameters, per environment

The last option has multiple advantages over prior options. As you could create separate environment parameters in their own dedicated files and manage them accordingly.
For example: You can create a separate param file for “Dev” environment deployments; like in the following screenshot.

Note: parameter files for Bicep language are using a JSON notation, similar to the way how ARM JSON declares parameter files with a following schema.

"https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#"

And our deployment script will look like the following sample:

# Option-4: Run deployment with a separate parameter file
az deployment group create -g 'rg-test-deploy' -f .\param-files\webapp-service-w-param.bicep -p .\param-files\webapp-service-parameters-dev.json

# List all webapps in the subscription
az webapp list --query [].name -o table

# Clean all resources from RG
az group delete -n 'rg-test-deploy' --yes

Summary

Thank you 🙏 for reading this post and learning about four different options to deploy your Azure Bicep files using Azure CLI.

Please check out the Learn Bicep GitHub repo, and follow it.
Thanks 🙏 🙌 !

Stay tuned for more Azure automation & Azure Bicep posts.

Fᴏʟʟᴏᴡ ᴍᴇ 🎯 ᴀɴᴅ become ᴀ #cloudmarathoner ⛅🏃‍♂️🏃‍♀️ – 𝐋𝐄𝐓’𝐒 𝐂𝐎𝐍𝐍𝐄𝐂𝐓 👍

 2,982 Reads