Bruno Lucas Azure Blog

The path to complete automation and the end of sharing secrets through unsafe channels. Renew Secrets whenever you need without breaking environments or manually updating config files

Azure Key Vault reference is pretty popular around the world but there are still a lot of Azure developers adding secrets to config files or Devops secret variables.

Case you never heard about Key Vault Reference, this is a convenient way to pull the secret from the Azure Vault by pointing to where the secret is in the Vault. This way, you only add that once to your code, and when you update the secret, your code will be able to use that without config file updates or redeployment. Read more here: Use Key Vault references – Azure App Service | Microsoft Docs

When you work on a microservice project that involves several services, the Vault can be very handy to simplify connection string management and security. Another Challenge for this type of project is to automate everything into a nice DevOps pipeline. Nothing against ARM templates, but terraform makes DevOps more straightforward and cleaner for this type of task.

The Terraform Code

We start by creating the vault (#1). With the vault created we can now create resources that require access keys\connection strings (#2) and store the secret in the vault (#3)

Result: The Resource was created and the secret is now in the Vault. You could open the vault, copy the secret and paste on your azure function or web api but there is a better way without ever exposing the secret. Will discuss that further down.

The azure hub and many other resources don’t force you to renew secret. But sometimes secrets expire, like on the case of a Service Principal and you can run this script before functionality is interrupted.

The secret will be renewed and you won’t need to touch code or manually paste de secret on Devops.

One tricky part is the Vault Policy. This is when you tell the Vault who can access the secret. On our case, for the script, let’s add a policy to allow the Service Principal Account that runs this script. Of course you can add other accounts, like any other service account that needs access.

The Catch here is, that there is a delay between applying this and reflecting on the Vault. Most of the time, this script will fail on the first run, saying you are not authorized to add secrets to the Vault. If you wait five minutes and run again, it will succeed. There are ways to improve that when adding this to DevOps. May discuss that in a future post

code for the above can be found here: https://github.com/blucas2016/blucas2016-TerraformVaultSecret/blob/main/main.tf

Azure Functions

To start using the above in an azure function, you need to pass the Key Vault Reference with the path to the key to the “App Setting” and start using that on your code

When developing, you can also use the Vault path on your config json, but you will need to add it to terraform to deploy.

resource "azurerm_function_app" "example" {
  name                       = "example-azure-function"
  location                   = azurerm_resource_group.example.location
  resource_group_name        = azurerm_resource_group.example.name
  app_service_plan_id        = azurerm_app_service_plan.example.id
  storage_account_name       = azurerm_storage_account.example.name
  storage_account_access_key = azurerm_storage_account.example.primary_access_key
  os_type                    = "linux"
  version                    = "~4"

  app_settings {
    FUNCTIONS_WORKER_RUNTIME = "dotnet"
    ServicePrincipal         = “@Microsoft.KeyVault(SecretUri=${module.lookup.key_vault.vault_uri}secrets/ServicePrincipal/)",
  }

Now with the Key Vault Reference (highlighted above) on the code config file, you can run the Terraform script many times, and the azure function will pick up any new secret.

Suggested dev process:

1. Add a new Azure Resources to terraform

2. Pass the resource’s secret to the vault. Make sure you update the Vault Access Policy to allow a user to “set” secrets

3. Run Terraform

4.Confirm secret is in the Vault.

5.Add the vault path to the Key Vault Reference and the Key Vault Reference to the Azure Function Terraform “app settings” section.

6. To debug the code in Visual Studio, Add the Key Vault Reference to app.setting.json

There is much more to add to the Terraform script to make it DevOps ready, but the idea here is to share a core concept. Using this approach I could run my DevOps without disturbing the developers. All the deployments beyond the Dev environment are also much more straightforward. You want to be able to deploy complex cloud infrastructure anytime with minimum impact disturbing the least amount of people.