Azure - Service Principals v/s Managed Identities

#dataengineering #python #azure #azurecloud #accessmanagement #activedirectory

Any data engineer who works on azure would have come across the terminology "Service Principal" aka "Active Directory App" and at least some of data engineer would have come across the terminology "Managed Identity".

?

Managed identities and service principals are mechanisms to provide programmatic access to Azure resources. Both uses OAuth 2.0 standard for authorization

?

OAuth 2.0 is an open standard for authorization that provides a secure and flexible way for client applications to access protected resources, such as those in Azure, without having to reveal their credentials. Instead, the client application requests an access token from an authorization server (in this case, Azure AD), and uses the token to access the protected resources.

?

This includes a authentication and authorization phase. Whenever we write a program which needs to access an azure resource , you need to talk to the "Head of Department" - The "Active Directory" aka "AD" . If Active Directory authenticate your application , it will provide a time bounded token aka 'credential' for accessing a scope. This scope can be a subscription or a resource group or an individual resource. And within the time limit , the application can access the scope and perform operations that are permissible based on the RBAC (Role Based Access Control) policy.

?

Below are some key differences between a service principal and a managed identity :

Managed identities:

• A managed identity is a feature of Azure Active Directory (Azure AD) that automatically manages the creation, rotation, and revocation of credentials used to access resources.
• You don't need to provide a client secret for getting the credential from AD. So you don't have the overhead of?keeping the secret value for authentication safe in a key vault or some other way. You should be running your code from azure ecosystem within a resource (azure VM , azure functions etc.) where azure identity authentication is enabled.
• A managed identity can be assigned to a resource (such as a virtual machine , azure functions etc.) and the resource can then use the managed identity to authenticate to other Azure services or resources (aka scope) that support Azure AD authentication.
• The managed identity is tied to the lifecycle of the resource, so when the resource is deleted, the managed identity is also deleted.

Service principals:

• A service principal is a specific type of identity in Azure AD that represents an application or service that needs to access resources. You will create it through "AD application registration" process and you will get tenant id, client id and client secret for the same.
• A service principal is then assigned with a role (owner, contributor, a custom role etc.) and then applied to a scope (a subscription , resource group, individual resource etc.)
• ?You need to keep the Client secret safe for generating credentials from AD . You can use an azure key vault or any other encrypted mechanisms for keep it safe. And you can run your application from anywhere and get credential from AD using tenant id, client id and client secret for the scope
• ?Service principals are not tied to the lifecycle of a resource and can be deleted or rotated independently of the resources they access.?

Time bounded credentials:

The default lifetime for access tokens from Azure AD for a service principal or managed identity is 1 hour (60 minutes). This lifetime is defined by the token's "expiry" or "not-before" time, which is set when the token is issued.

It's worth noting that you can also configure the token lifetime using Azure AD's token configuration settings. You can configure the lifetime for access tokens, ID tokens, and refresh tokens, as well as specify different lifetimes for different applications or users. Additionally, you can use token refresh to obtain new access tokens without requiring the user to sign in again.

For a service principal , while getting the token from AD , you can optionally configure the life span of the token as well

For example , let's say I need to write a function in python for accessing secrets from a key vault. I can access key vault in two ways .

1. Register a service principal --> Add a policy under key vault with GET and LIST access for service principal --> Use ClientSecretCredential class from azure-identity package with tenant id , client id and secret as argument to get credential from AD --> Use the credential to access Azure key vault and get the secret
2. Create an azure function or VM resource with managed identity enabled --> Assign the Managed Identity of the Azure Function to the Azure Key Vault with?GET and LIST access --> Use ManagedIdentityCredential class from azure-identity package for getting credential --> Use the credential to access Azure key vault and get the secret

?

For getting the secret from key vault we can utilize azure-keyvault package.

The sample function with both the above method implemented can be seen in below screen shot.

Packages:

Functions: