3.19 Introduction to Role-Based Access Control (RBAC)
18 hours 43 minutes
Welcome back. This is the first episode in our discussion on advanced identity and security where we're gonna talk about world based access control.
My objectives include understanding what is our back, distinguishing the difference between groups and rolls and then taking a look at our role components.
So first, as always, what is our back? Our backs stands for role based access control. It's a way to manage access to azure resource is and control. What someone could do with those. Resource is our back is a way to provide very granular control over resource is and objects inside of azure.
For this course, I've been doing the demos. Working with a global administrator account, which has access to all the resource is and can modify them in any way. However, you may have other administrators who don't require this amount of permissions are back, allows for giving these other administrators on Lee the access and control they need to perform their job role.
This is the idea of least privileged access where someone on Lee needs the permissions to do his or her job
over on the right. I have a screenshot of some other admin groups in addition to the global administrator, the global reader is a new one. It's basically like the global administrator. It can read everything inside of the azure tenant, but not before many of the actions.
And then you have other ones that you might be more familiar with if you've worked inside of office 3 65 like an exchange administrator group.
In addition of those groups, we have other roles that we can assign, such as owner, contributor and reader. Thes rules could be applied to an entire subscription, a resource group or even individual resource is like a virtual machine or storage account.
For example, you could allow someone on Lee to manage virtual machines across an entire subscription,
allow administrator to manage to sequel databases or a lot of application to access. Resource is inside a resource group.
One thing I want to point out, and we discussed a little bit on the last slide. We're gonna see it in the demos. Well, there's two different areas where permissions can be assigned.
The first is when managing Azure Active directory. They're built in roles that provide access to manage azure A D, like the global admin group building administrator or device administrator.
These air specialized admin roles that allow access to manage those objects, such as user passwords, licenses and domains inside of Azure a. D. You might have also seen examples of these in office 3 65 with rolls inside of specific products like Exchange, Skye for business, SharePoint or Microsoft teams.
The second area is controlling Access to Resource is like virtue machines, storage council networks, these air assigned through rolls named owner, contributor, reader or user access administrators.
These could be even more granular, like the ability to read data in a storage account, but not right. The data as your are back currently has over 70 built in roles to choose from.
So as we discussed, we'll use our back to control. Access to Resource is using different role assignments. And inside of these roll assignments, there are three different elements. We have a security principle, the role definition and then the scope. Let's look at these a little bit more in detail.
Security principle is an object representing a user group, service principle or managed identity inside of Azure. Let's break down what he did. These are a user is an individual inside of Azure A. D. With a profile. A group is a collection of these users,
and each user in the group will get the permissions that are assigned to the group through the role.
Next, we have a service principle, which is a security identity used by applications or service is to access as your resource is. You can think of it as a user identity for applications. Finally, we have managed identity, which is an identity automatically managed by Azure
and used by cloud applications as a way to securely retrieve credentials, secrets and other key stored in the Azure Key Volt.
Next, we have our role definition, or rolls, which is just a collection of permissions. The role defines what operations can and cannot be performed, such as read, write and elite operations. On our azure resource is these roles can be high level, like an owner or more granular, like a virtual machine reader.
Inside of Azure, we have four fundamental roles. We have the owner, which has full access to resources, including delegation, which means it can assign roles to other users. We have the contributor which can create and manage. Resource is but not delegate permissions are rolls to other users.
Next we have reader, which is pretty self explanatory. It can pretty much view the resource is but not make any changes or assign delegation to other users.
And finally, we have the user access administrator, which doesn't manage. Resource is or apply to Resource is, but it can manage user access to Resource is just like the owner can.
When looking at our role definitions, I've got an example here from the azure Power Shell module. Basically, we're looking at a role definition for the built in role of virtual machine contributor. Here we can see a list of actions that are available to the virtual machine contributor
and expanding that power shell property out. We can see how azure breaks down these roll definitions. For example, we have Microsoft dot compute, which assigns the scope of what it applies to. For instance, we have Microsoft Compute slash virtual machines and then a wild card, meaning all the actions under the virtual machine are available to this role.
But here in the bottom, we have Microsoft dot network slash public i p addresses slash Reed Reed is very specific, meaning it can look at the public I p address resource is, but it won't be able to modify them or create them, and looking at the one above it joined slash action just means it can assign the public i p
address resource to virtual machine.
But we're not allowing this role to actually manage our public I p addresses same thing above. When looking at network security groups, we can add network security groups to virtual machines and read them. But this role won't allow the user to create or manage network security groups.
And finally we have scope, and this is simply the resource that the role is being applied to.
You can take your role and a sign it at the subscription level to a resource group or even an individual resource like a virtual machine.
And the permissions don't just stop it. That resource they are inherited down to the child scopes. For example, if you apply permissions on a subscription, then the user assigned the role will have those same permissions on all the resource groups, and resource is inside the subscription.
Finally, one less thing to talk about our role definitions are deny assignments,
just as we allow access to resource through different allow actions we can also apply. Deny actions thes deny actions are actions that are not allowed as a part of the role assignment.
If you look at the screen shot on the right, we have not actions where we defined what we do not want to allow on that property.
And even if the role definition hasn't allow action to find in it, the deny action will block the ability.
And the deny actions always take precedence over allow actions.
So that does it for the basics of talking about are back in the components of it as well as our administrator groups.
Let's follow this up with a quick post assessment question. What are the four fundamental built in roles
we have owner, contributor, reader and the user access administrator
coming up next, we'll put some of this into action within our back demo by going back out to our azure portal. See you in the next episode.