Concept of Azure Service Principal(Azure SPN)

An Azure service principal(Azure SPN) is an identity created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level.

Multiple Level Service Principal

1. Subscription Level

      It is Parent level service principal through which you can access 
      all azure resources which are under subscription.
   

   • Deploy Service Principal :

      As name suggested custom application will be deploy on 
      azure resources through this SPN. 
     

   • Runtime Service Principal :

      As name suggested custom application can access other 
      azure resources through this SPN.
     

2. Application Level(AASP)

     It is custom made service principal which can be used to access 
    azure resources from on premises application or from other subscription. 
    To access this Azure resources need to provide proper role. 
   

HOW Service Principal and Service Account are different OR is it close?

1. A service account is privileged user account used to authenticate using a username and password. And, if used with automation, a service account is most likely excluded from any conditional access policies or multi-factor authentication.

2. An Azure service principal can be set up to use a username and password or a certificate for authentication. Think of it as a user identity without a user, but rather an identity for an application.

Primary Considerations for Creating Azure Service Principals

you should know the basic details that you need to plan for. These details may seem simple. Still, they will make creating an Azure service principal as efficient and as easy as possible.

Display Name It all starts with a name, and an Azure service principal must have a name. There’s no rule here, but your organisation might have a prescribed naming convention.

Type of Credential You could choose to create an Azure service principal that will use a password or certificate for authentication. You can only choose one or you can use both. For service principals, the username and password are more appropriately referred to as application id and secret key.

Validity Period Whether you’re assigning a password or a certificate credential, you have to define a start and end date for its validity. How long a credential will be valid for typically depends on how often you’re willing to rotate/renew certificates and passwords.

Scope of Access Creating an Azure service principal that will have access to a subscription, resource group, or selected resources.

Role There are several roles available, such as Contributor, Reader, and Owner, to name a few. You need to define which role is “just enough” of the service principal.

Conclusion

Above are basic understanding of Azure Service Principals who are new to cloud world. It is the security principal that must be considered when creating credentials for automation tasks and tools that access Azure resource. The scope and role to be applied can be picked to give “just enough” access permissions.

Upcoming blog we will learn how to create Service Principal and set up secrets.