Creating Azure Service Principals or Managed Identities & Granting them Access
Welcome back! Time to get down to Part 2 of this series. In Part 1 we reviewed how to create an Azure Key Vault and add vault objects. If you need, you can also view my full tutorial here. Today we are going to create several resources that can act as identities, which we will use to access the Azure platform.
We also have to grant them permission by updating access policies and assigning them roles. Think of them as being artificial user accounts with varying levels of permission. This allows them to manage workloads, coordinate activities, and automate processes so you don’t have to. The information jotted down today will be needed for Part 3 of the series.
To create an Azure Service Principal or a Managed Identity you will need:
- A Microsoft Azure account
- An active subscription
- A resource group
- Have an Owner or User Access Administrator role on Azure
Step 1— Option 1: Create a service principal via app registration
Microsoft does a thorough job of explaining service principals in their documentation. But in layman’s terms, a service principal is a tool -with an identity- that is created and managed at the highest level in a directory, just like users. When you create a service principal, a one-way relationship of trust is established between the service principal and the Azure identity platform.
Hmm okay… but why does this matter? Partly because certain values created and gathered during this process will be used as environment variables in our code later on (specifically for identities 2 and 3 mentioned in Part 3 of the series). The values we will be generating/collecting are: AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID, and AZURE_SUBSCRIPTION_ID. By all means, there are multiple ways to collect the latter two values, but for arguments sake I am using the method below.
Login to the portal and navigate to Azure Active Directory via the search bar.
On the Azure Active Directory blade select App registrations and then + New registration.
Give your app a name and then select Register. I chose ‘it-eda-dev-platforms-sp’ for mine because I will be using it for my platform applications in my dev environment.
Under Manage on the service principal blade select Certificates & secrets , then select + New Client Secret.
Add a good description for the client secret, set an expiry date, and hit Add.
Microsoft will generate a client secret value and secret id for your service principal. Please copy both of them down (in a Notepad app for now), you will NOT be able to access the secret value after you leave the page. We will use the secret value as an environment variable later.
After you have copied those items down, go to the Overview blade of the service principal. Copy the Application (client) ID, Object ID, and Directory (tenant) ID values onto the same Notepad.
You can find your Subscription ID on the homepage under Subscriptions. Copy the value I have blacked out and store it on that Notepad again.
Step 1— Option 2: Create a user-assigned managed identity
Managed Identities — What are they? Long story short, they are a special (low-maintenance) type of service principal that does not require users/developers to manage credentials, such as the client secret value created in the last step.
For Azure resources that support Azure Active Directory authentication, like a key vault, managed identities automatically generate an identity in Azure Active Directory. There are two identity types, system-assigned and user-assigned. Microsoft explains the differences here, along with common applications. We won’t be using system-assigned managed identities but they are directly tied to one resource (VMs are the most common). User-assigned managed identities are their own resource and can be used by multiple resources in Azure.
Their documentation also gives pretty straight forward directions for creating a user-assigned managed identity so I don’t have to, yay for me.
I named my managed identity ‘it-eda-dev-platforms-mi’. After you create your managed identity, you will need to go to the overview blade and jot down the Client ID and Object (principal) ID on the notepad.
Step 2: Granting the service principal & managed identity access to the key vault
Navigate to your key vault and on the left blade choose Access Policies then + Create.
For the purposes of the demo choose Get and List for the secret permissions then select Next. Of course you can add additional permissions or choose use a template configuration but please, please please do so with caution.
Type the name of your service principal my service principal is named ‘it-eda-dev-platforms-sp’, select the service principal (ensure it is listed as selected down below) hit Next. On the Application blade hit Next again, and under Review + create, select Create. Unfortunately key vault access policies can only be assigned to one object, principal, or user at a time. Azure Active Directory Groups are a great way to overcome this limitation.
If you decided to create a managed identity, repeat the motions above to assign it the same access policy.
On the access policies blade of the azure key vault you will see that both the service principal and the managed identity have the associated permissions.
The last thing you need to do (or your Azure administrator needs to do) is assign the managed identity a Contributor role under access control .
Well Done. Looks like you are ready to put this stuff together.
Let’s connect on LinkedIn, otherwise share this article and follow me for additional content! In the last part of this series, we will get to coding so you can be well on your way to becoming an Azure integration wizard.
