SPN & MI

Overview

• Azure AD is a trusted ‘Identity Object store’
• Object types are
  • Users
  • Groups
  • Enterprise Applications
    • SPN & MI are in this category

Service principal

The official description of an SPN is

“…An application whose tokens can be used to authenticate and grant access to specific Azure resources from a user-app, service or automation tool, when an organization is using Azure Active Directory…”

• On-premises AD an SPN is known as a service account which is essentially just a user account
• Azure AD uses SPN instead which is not a user
• An SPN can be assigned rights to Azure resources in RBAC
• A use case for an SPN would be an application/service needs to access an Azure resource
  • For example, an Azure Service Connection in Azure DevOps Pipelines
  • For example, creating resources in Azure using TerraForm

When an SPN is created you are returned the following values

appId
displayName
name
password
tenant

To setup an Azure DevOps service connection you would map

• Service principal name > appId
• Service principal key > password
• Tenant ID > tenant

In TerraForm you could define the values in a variable file

Terraform subscription service principal vars
  client_id       = appId
  client_secret   = password
  tenant_id       = tenant

The negatives/risks with an SPN are

• A user needs to specifically create them
• It’s still username and password which has to be known to the creator and the consumer of the SPN

Managed Identity

The official description of an MI is

"…Managed identities provide an identity for applications to use when connecting to resources that support Azure Active Directory (Azure AD) authentication. Applications may use the managed identity to obtain Azure AD tokens…"

• An MI is 100% functionally identical to an SPN
• An MI actually is an SPN under the covers
• However, they must be linked to an Azure resource instead of an application
• When you create a resource the MI can be created
• Nobody knows or needs to know the credentials (username/password)

Examples

Grant a VM access to a key vault You can create an MI for a VM and then assign it permissions in a Key Vault access policy to retrieve a storage account access key.

1. On the VM itself go to the Identity blade
2. Create the system managed ID
3. Go to the key vault and add a new access policy that uses the new Vm managed ID as the principal

AZ CLI commands

References

https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli?msclkid=1965b595c6df11ec87e0840f794729a6 https://docs.microsoft.com/en-us/cli/azure/ad/sp?msclkid=b86bc167c6e811ec806b704a52c12dbb&view=azure-cli-latest https://devblogs.microsoft.com/devops/demystifying-service-principals-managed-identities/?msclkid=1a5574d8c6ec11ec8558478e9d1a7a3e https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview?msclkid=cee097f2c6f411ec81c4bf35e09cffa1 https://docs.microsoft.com/en-us/azure/container-registry/container-registry-authentication-managed-identity?msclkid=62c93c92c6fd11ec8b50b1f595ef34e9