Azure RBAC 101
I’m getting started with Azure. After a couple of years playing with GCP and Azure, I thought it’s time to play with Azure. I hope I can reach a good depth and be able to compare the 3 cloud providers in future posts! I don’t promise anything but I’ll do my best :)
What the heck is Azure RBAC ?
RBAC stands for Role-Based Access Control. In short it’s used to manage access to ressources. In our case we will look into how we can manage access to Azure ressources effectively.
We need to understand a couple of concepts that Azure uses to implement RBAC:
1. Security Pricipal
A Security Principal can represent a user, group, service principal*, or managed identity*. Let`s keep our examples simple for now with users and groups. We will dig what are service principals and managed identities later on.
2. Role definition
This is where we say what actions are allowed by the role. Azure provides a lot of built-in roles. And a lot of people end up using those built-in roles even if they carry a lot of permissions and it’s not necessarily a good decision. On the other hand, we can define custom roles, where we define exactly what we need in terms of permissions by following the principle of least privilege.
3. Scope
Azure has a defined hierarchy for resources. There is 4 levels:
- Management group
- Subscription
- Resource group
- Ressource
The lower we go, more explicit we will be in our scope definition, which is better in terms security best practices.
4. Assignement
The assignement is the glue between the “Security principal”, the “Role”, and the “Scope”. A role definition alone will not grant a user, for example, any permissions if we don’t assign the role to the user on a defined scope.
Next steps
In the following posts, we will see some practical examples of defining scopes depending on what we want to achieve. And we will look into Service Principals and Managed Identities in Azure.