Anyone who’s worked with Azure for a bit has encountered the need to create a service principal. If you are an IT Ops person, you probably equate an SP with a service account in local Active Directory. If you’re more of an application developer, then you may have created an SP as part of your application in Azure, because you want to give that application permissions to Azure resources. The purpose of this post is to tease apart what service principals are, how they interact with application objects, and all the myriad ways to create an SP on Azure.
This is the second and probably final post in this series. If you haven’t read the first post I would highly recommend it. When we last left our erstwhile heroes, they had successfully setup the Azure authentication method on a Vault server and created a policy associated with a role in the Azure auth method. The policy grants access to a key-value store called webkv. Now comes the fun part, how does an Azure VM go about using the Azure auth method to access the secrets stored in webkv? So glad you asked!
I am currently working on a Getting Started course for HashiCorp’s Vault product. There was a pretty cool demo I put together for using Azure AD as an authentication source for Vault, but unfortunately I had to cut it for sake of time. I didn’t want it to go to waste though; so I figured I’d write about it here instead. Here’s what we’re going to do. Use the Managed Service Identity feature in Azure to give an Azure VM permissions to access secrets in Vault. This is the sort of thing that could be applied to anything that can receive an MSI in Azure, including App Service, Functions, VMSS, and more!