Previously, in my last post, I went about creating an automated onboarding app in Azure using the Logic Apps resource. Looking back at the app, I wanted to figure out how to make it more secure, outside of just having an administrator enable the user, so I turned to key vault.
In my first build, the password was hard coded into the application, which as we all know, is a huge security risk and bad practice in the industry. Enter Azure Key Vault, a cloud service that is used to securely store and access secrets, such as our new user password. Once the key vault is created and our password securely stored, I granted permissions to the logic app to access and use the stored secret, which I will be taking you through the steps to integrate key vault into your own logic apps.
Project Steps
- Create key vault.
- Create a secret in the key vault.
- Activate the system assigned identity of the logic app.
- Grant permissions to the logic app.
- Add the key vault api connection.
- Integrate the secret into the user creation.
- Test the new app.
The first thing that needs to be done in this process is to add our key vault resource. There are a few different ways that this can be done, either in the portal, by using the Azure CLI, Azure PowerShell, or by deploying through IaC such as bicep, ARM template, or Terraform. For this step, I created the key vault through PowerShell by running,
New-AzKeyVault -VaultName 'KeyVaultName' -ResourceGroupName 'ResourceGroupName' -Location 'Location' -EnabledForDeployment
Once that key vault was created, the next step is to add the secret to the key vault, which is our password, that will be used for our new users. To create the secret, this can also be done in the portal, or over the Azure CLI, or Azure PowerShell. To accomplish this task, I once again used PowerShell by running the command to create a new key vault secret.
$Secret = ConvertTo-SecureString -String 'Password' -AsPlainText -Force
Set-AzKeyVaultSecret -VaultName 'KeyVaultName' -Name 'SecretName' -SecretValue $Secret
With the key vault created and secret added to the vault, we now need to grant permissions to the app to use our secret using least privilege access. The first step in doing this was to enable the system managed identity of the logic app. To do this step I hopped into the portal and went into the logic app. Once inside of the logic app, on the left hand side under the settings menu, open the identity option, and change the status from off to on.
Now that the logic app has an identity, we can grant it access to the key vault using RBAC with least privileges. To use least privilege, we need to first understand what we need the logic app to do, which in our case, is to be able to read secrets in the key vault and use the secrets. With that noted, I went ahead and assigned the key vault secrets user role to the onboarding app.
With the key vault set up and permissions to the logic app granted, the next step is to connect the key vault api connection to the logic app workflow. Since we need the password secret from the key vault before we create the user, we'll insert the get secret connection between the HTTP request trigger and create user connection. With that in place, we'll go ahead and select our secret that we created for the new user password.
Since our logic app has now grabbed the secret in the previous step, in the create user connection, password creation, we can input the value from the secret without exposing or hard coding our password.
The final step with our new logic app integration is to test. Again, I used thunder client in VSCode to send the HTTP request to the app, making 2 different accounts and signing in with those accounts to make the password was the one stored in the secrets. With 2 successful runs, the Key vault integration was working as planned.
Key vault should always be your go to for storing your secrets passwords, certificates and any other sensitive information that you may need to use. Azure makes integration of key vault very easy through RBAC with either user accounts or managed identities. It's a great practice to help secure your sensitive data from falling into the wrong hands, that should always be integrated when possible.
Top comments (0)