adaptive.run TECH BLOG

Cloud can be tricky sometimes. Find out what scenarios we've ran into that are worth being mentioned and explained.

Securing Your Azure Infrastructure with Bicep: A Guide to Assigning Access Policies to KeyVault

Level: 200
Publishing date: 07-Feb-2023
Author: Catalin Popa

Bicep is a high-level language that allows developers to declare Azure infrastructure as code. One of the key benefits of using Bicep is the ability to manage access policies to KeyVault with ease. In this article, we'll take a look at some lessons learned from deploying access policies to KeyVault with Bicep.
Scenario:
In this scenario, we have a development environment where multiple developers need access to the Key Vault. However, each developer should only have access to the secrets they need to perform their job. To accomplish this, we will use Bicep to assign access policies to the Key Vault.
Lesson 1: Understanding Access Policies in Key Vault
Key Vault access policies define which operations a user, application, or service principal can perform on secrets, keys, and certificates. There are several predefined policies available in Key Vault, such as "get" and "list", but you can also create custom policies.

Lesson 2: Understanding Bicep
Bicep is a new language for writing Azure Resource Manager (ARM) templates. It's designed to make it easier to write, understand, and maintain ARM templates. Bicep is similar to Terraform, but it's more focused on Azure resources.

Lesson 3: Assigning Access Policies in Bicep
To assign access policies to Key Vault with Bicep, we first need to create a Bicep file. In this file, we will define the Key Vault and the access policies.

Here's an example of how to create a Bicep file:


// Define a KeyVault resource
resource keyVault "Microsoft.KeyVault/vaults" = {
name: "myKeyVault",
location: "West Europe",
properties: {
sku: {
name: "standard"
},
tenantId: "",
accessPolicies: [
{
tenantId: "",
objectId: "",
permissions: {
keys: [ "get" ],
secrets: [ "get" ]
}
}
]
}
}
// Define a KeyVault access policy
resource keyVaultAccessPolicy "Microsoft.KeyVault/vaults/accessPolicies" = {
name: "myKeyVault/readAccess",
properties: {
keyVaultId: keyVault.id,
tenantId: "",
objectId: "",
permissions: {
keys: [ "get" ],
secrets: [ "get" ]
}
}

Lesson 4: Deploying the Bicep File
Once we have created the Bicep file, we can deploy it using the Azure CLI. 

Here's an example of how to deploy the Bicep file:

az deployment create --template-file keyvault.bicep --parameters key

Lesson 5: Assigning Access Policies to KeyVault with Bicep across multiple Resource Groups

When working with multiple resource groups, the process of assigning access policies can become more complicated. When multiple resource groups are involved, it's important to ensure that the correct policies are assigned to the correct KeyVault and resource group. This can be accomplished by creating separate Bicep files for each resource group and referencing the correct KeyVault in each file.

Scenario:

In this scenario, we have a development environment where multiple developers need access to the Key Vault, but the secrets they need to access are in different resource groups. To accomplish this, we will use Bicep to assign access policies to the Key Vault.

Here's an example of a Bicep file for assigning access policies to Key Vault across multiple resource groups:

module keyvault {
resource keyVault 'Microsoft.KeyVault/vaults/@{variables("keyVaultName")}' {
name : variables("keyVaultName")
location : resourceGroup().location
properties: {
tenantId: subscription().tenantId
sku: {
name: "standard"
}
accessPolicies: [
{
tenantId: subscription().tenantId
objectId: "developer1@contoso.com"
permissions: {
secrets: [
{
actions: [
"Microsoft.KeyVault/secrets/list"
]
excludeScopes: []
keyId: resourceId("ResourceGroup1/Microsoft.KeyVault/secrets/secret1")
}
]
}
},
{
tenantId: subscription().tenantId
objectId: "developer2@contoso.com"
permissions: {
secrets: [
{
actions: [
"Microsoft.KeyVault/secrets/get"
]
excludeScopes: []
keyId: resourceId("ResourceGroup2/Microsoft.KeyVault/secrets/secret2")
}
]
}
}
]
}
}

In this example, we have defined two access policies for two developers. The first developer (developer1@contoso.com) has "list" permissions for the secret "secret1" in resource group "ResourceGroup1", while the second developer (developer2@contoso.com) has "get" permissions for the secret "secret.
It is also important to note that when modifying access policies in KeyVault, it is necessary to redeploy the infrastructure as code for the changes to take effect. This is because Bicep only applies changes to the infrastructure that have been declared in the Bicep file.

In conclusion, assigning access policies to KeyVault with Bicep is a straightforward process that can help developers control who has access to sensitive information. However, when working with multiple resource groups, it's important to ensure that the correct policies are assigned to the correct KeyVault and resource group, and to redeploy the infrastructure as code for changes to take effect. By following these best practices, you can ensure that your infrastructure as code is secure and properly managed.

We hope you found this helpful!

adaptive.run

Transform your business.
Run adaptive.

Contact

Phone: +40 73 523 0005
Email: hello@adaptive.run

© Copyright  2019-2024 adaptive.run- All Rights Reserved