AZ-104 Microsoft Azure Administrator Associate – Manage role-based access control (RBAC)

1. Overview of RBAC

So talking about Active Directory, really we’ve been talking about identity, right? This is identity as a service. Also it could be authentication as a service. Basically we have users, those users have passwords. If we have MFA enabled, then they have to provide a code. And those three pieces of information basically prove to us that they are who they say they are. And that’s the authentication aspect. But once they’re authenticated, what can they do? What is their authority? What is their authorization? And so we haven’t to this point talked about authorization. To do that. We’re going to get out of Active Directory and we’re going to go into, in this case, a resource group. Now when you go into any particular resource within Azure, you will see typically this access Control setting only is it there for the resource group level.

But if we were to go down into a resource itself, which hopefully this won’t take too long, so even within a virtual machine level, we do have this access control setting, go back to the resource group level, but go into Access Control. This is where it allows us to control whoever’s going to be able to get into this resource group, who’s going to be able to see the resources, who’s going to be able to modify anything, add new resources, or even in the case of owners, create new users who can then access those things. So check access, right? So we can basically say, let’s see if John Doe, I’ve got a user named John Doe. Let’s see what John DOE’s permissions are. John Doe has no permissions. He’s not denied. Basically, he would not be able to see any of these resources because it allows him to do it.

But what if we wanted John Doe to be able to access those virtual machines or to access the logic app? In this case, what we want to do is we want to add a role assignment. Now go into this role assignments here by default, you’re going to have some role assignments. Some of them are going to be inherited from the subscription level. So we can actually go into the subscription level and look at the access controls in there and see them all here inherited. I don’t have any access that’s been specifically granted. This resource group that is not just inherited from above. My main account is in there. Cloud Dan is a cost tracking application. These are automatic. So the service principal and things like that, automation accounts that create accounts for themselves.

So let’s say we want to add a John Doe to have access. Now first we have to decide what role we want to give John Doe. The three main rules that you need to understand are owner, Contributor, and reader. You can see that there are dozens of other roles and we’ll get into them in a second. But top three owner, Contributor, and reader are arpson the reader as the name suggests just gives you read only access to those resources. That means that if you logged into the portal, you can see the resource group. You can go into the resource group, you can see the resources there, you can click into the resources and you can see them. But you can’t make changes, you can’t stop them, you can’t edit them, you can’t delete them, read only accesses.

The reader Role now the contributor role is like a set of permissions. You can go into a resource group, in this case create sources, delete resources, edit resources. You just can’t give that permission to other users. So you’re one manager of these resources, but you can’t make your friend a manager as well. The owner permission is the most powerful and this more than anything is the castle. So do not hand out owner permission to your account or to specific resource groups unless you really know what you’re doing. But the owner permission basically allows you to manage everything just like a contributor and you can also grant access to others. And so your friend can also get contributor access and your other friend can also get owner, et cetera.

So that’s reader, contributor and owner. Now as we scroll down these of other predefined roles you can see very similar naming like backup, reader, contributor, backup operator, CDN endpoint, contributor, CDN endpointer, et cetera. There’s a lot of contributor in reader roles against many of the services inside of Azure event grid, document, DB Log, analytics, et cetera. So we basically have the ability to give very fine grained prints to individuals using world based access control. I’m to give our friend contributor access John Doe. So contributor and I’m going to say I’m going to assign it to a user and that user is John Doe and elected John Doe. So once I save it, it’s going to do a deployment that basically adds John Doe and we can see John Doe.

A user has been given contributor access only to this resource group. So if we go back to check access and we check John DOE’s access now we can see he’s got contributor permissions specifically assigned to this group. And so that’s a rule based access control. Now we could obviously go in here if we wanted to ensure that somebody, no matter what permissions they have that could be inherited. Let’s say that I want my other account specifically to be denied access, okay? My account here is denied access as a contributor. It’s almost an opposite of users from performing specific actions even if they’ve got access through some other way. Scott Duffy was added contributor. So that’s basically role based access control.

It can happen at the resource level, at the resource group level I talked to Bootsaw, basically going into a subscription. We’ve got access control options at the subscription level. In this case, I don’t mind showing you someone who works for me has contributor access to my entire account and they can create resources, and I’ve given them permission to do so. We can see that basically this is one way of ensuring that people can either have access or be denied access, so that’s the authority essentially do things as opposed to the authentication, which is taken care of by Azure Active Directory.

2. Creating Custom RBAC Roles

Now we’ve seen that the Microsoft Azure dozens of what’s called builtin roles and again it covers all of those that are individual Azure services. And so you can basically assign users very specific and granular permissions, maybe reader permissions to some set of horses and then contributor permissions to other sets of resources. But what if these roles are good enough for you? Because you’ve got these extremely rules owner, contributor and reader and then you’ve got dozens of very granular roles. So what you might need is what’s called a custom role. Now there is not an add role button within the portal here, but we can go and create a custom role in either PowerShell or CLI. Now, the technique that Microsoft recommends is that you take the role and basically save it to a JSON. Take an existing role.

Let’s say you take the reader role and then you then modify it. So it’s easier to edit an existing role than to sort of come up from scratch with a role definition. So it’s showing you the example here on the Microsoft way of putting a reader role into a JSON file and then editing the file to allow Microsoft Support services within that. For instance. So you create this new Reader Support Tickets role and you granting Microsoft Support Action Star, which means focus to that set of services. Okay? So now you basically modify single, giving it one more additional permission and you’re calling it Reader Support Tickets. And so from that point forward you can assign users that role.

You can list roles, you’ll see these roles listed in the portal. When you go to assign people into roles, you’ll see it, you can update it, you can delete. So custom roles really are a way of very specific permissions for your specific circumstances. Instead of being forced into Microsoft’s extremely granular roles, you can say, well, this is what a developer is, what a customer service representative, this is what DevOps does, et cetera, and create a complete package of permissions into a single role. And then you assign those roles to people. And that’s why it’s called role based access control.