On Twitter, there was some noise about a new Logic Apps connector for Azure Key Vault. As I love both of these Azure services, I was tempted to give it a try. You can read here my first impressions.
The available operations are quite impressive. I can’t think immediately of anything that is missing. It’s very positive that you have the option to point to a specific version of a key/secret or to just use the latest one.
It’s very important to understand how access is granted to the vault. Unfortunately, it goes via Azure AD user interaction, instead of using Managed Service Identity.
It’s required to explicitly grant the selected user the necessary access rights, by adding an access policy to the Key Vault.
In case you forget about it or you assign insufficient permissions, you’ll get an error with clear details.
One of the popular use cases for this connector is retrieving secrets at run-time. This is very straightforward to set up. Unfortunately, the secret value is shown in clear text, which is often unacceptable for production workloads.
I understood from the product team that they are working on an obfuscation feature, that will allow to configure sensitive data in such a way that it is not visible in the monitoring view. This would be a perfect fit for this scenario.
Another popular use case is data encryption / decryption. In order to test this, I’ve created an encryption key in the Key Vault.
Via the Logic Apps connector for Key Vault, we can easily encrypt data and decrypt it again. Also here, the obfuscation feature would come in handy.
Being aware of service limitations is of vital importance within Azure. It’s good to know that Key Vault throttles most of its operations at 2000 transactions per 10 seconds. All details can be found here.
Luckily, Key Vault returns a 429 HTTP Code (too many request), which is automatically retried by the Logic Apps engine.
Of course, under high load, a retry is not always a guarantee for success.
Very useful connector, but some aspects to be aware of:
- No authentication via Managed Service Identity. One could use this workaround.
- Sensitive data is shown in clear text. The obfuscation feature that is on the roadmap will be helpful.
- Take into account the Key Vault throttling limits. Out-of-the-box secret caching in the connector would be great. You can overcome this limit by storing the secret value in a secure parameter at deploy time, as discussed here. This has the downside that a new secret value, requires a redeployment.
Hope this clarified the capabilities of the Key Vault connector!