Azure Service Prinicals

Suresh_Godaba, imagine a task where you need to automate some process, like deployment from Azure DevOps to Azure Cloud, i.e., you have to build and release your app and have enough 'power' to deploy it to a specified Azure service. Definitely, you can do that with your own account, but would it be good if automated tasks will be executed under the most privileged account in your subscription? Your security team would argue, it breaks all security principles (including the 'least privilege'). Everything is volatile, people leave companies, and you can guess what happens when those accounts are getting suspended 🙂

The other option would be creating so-called service users. The problem is - these are still Active Directory users and if you have restrictive policies in the company, it's not an option. You would need to exclude them from MFA, and they suddenly become a good target. Security wouldn't be happy about those as well.

This is where Service Principals (SP) come into play. It's a privileged account type that doesn't need to be excluded from MFA and has a very limited scope as well as the expiration time. Basically, scoping is entirely up to you. You can make it create a VM and only have access to a specific resource group, or you can widen the scope through the role-based access to the entire subscription - depends on the task.

There are tons of ways you can create SP as well as a wide variety of different usage scenarios. I tend to think of them as special accounts, detached from the identity, and scoped just enough to perform a specific task (like automation, scripting, resource allocation, etc.), and yet very secure.

Hope that clarifies things a lot better 😉