is important. Here I'll discuss on how to make your bicep code more secure.

1. 📌 Useful links
2. 🔑 Managed identity in Bicep
3. 📜 Securing your parameters without managed identity

• Securing parameters with Azure KeyVault
• Quickstart Azure KeyVault with Bicep
• How to set up your key vault and best practices.
• Basic template for setting up Azure Key Vault and a secret.

Instead of putting secret values (like passwords) in your Bicep file or parameter file, you can retrieve the values from a Key Vault during a deployment.

If you're new to managed identities, I'd recommend reading this first. A shorter read can be found here.

I will be focussing on Azure KeyVault (AKV).

Start with setting up your key vault and taking a look at best practices.

When using a key vault with the Bicep file for a managed application, you must grant access to the Appliance Resource Provider service principal.

(For more information, see Access Key Vault secret when deploying Azure Managed Applications).

When a module expects a 'string' parameter with 'secure:true' modifier, you can use the 'getSecret' function to obtain a key vault secret. The value is never exposed because you only reference its key vault ID.

Below example comes from MSFT docs.

The 'sql.bicep' file is already there, which creates a SQL server. The following code consumes 'sql.bicep' as module. It will:

1. references an existing key vault,
2. calls the 'getSecret' function to retrieve the key vault secret
3. passes the value as parameter to the module.

Code:

param sqlServerName string
param adminLogin string

param subscriptionId string
param kvResourceGroup string
param kvName string

resource kv 'Microsoft.KeyVault/vaults@2019-09-01' existing = {
    name: kvName
    scope: resourceGroup(subscriptionId, kvResourceGroup )
}

module sql './sql.bicep' = {
    name: 'deploySQL'
    params: {
        sqlServerName: sqlServerName
        adminLogin: adminLogin
        adminPassword: kv.getSecret('vmAdminPassword')
    }
}

Protecting sensitive values, like passwords and API keys, in your deployments is important. The best approach is to avoid credentials entirely with managed identities, as described above.

If you don't want to use managed identities, you can use the @secure decorator. This can be applied to string and object parameters. Azure won't make the parameter values available in the deployment logs.

Example:

@secure()
param sqlServerAdministratorLogin string

@secure()
param sqlServerAdministratorPassword string