<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=2012313439098820&amp;ev=PageView&amp;noscript=1">
Posted by Dana Epp

The deep dark secrets of role based access control (RBAC) in Azure

Did you know that if you look beneath the surface of Microsoft Azure, there’s a complex connection between resources, roles & permissions working hard for you? This kind of role based access is built-in to Azure and you can take advantage of it right now. In our most recent episode of #KnowOps, we dive into Azure CloudShell and shows you this with the Azure CLI.

Enjoy!

 

Video Transcript

Got an interesting DM on Twitter the other day. A friend of mine had reached out because they had figured out that a consultant that they were previously working with, still had access to some critical resources in Azure, simply because they weren't managing the access control correctly. And it's an easy mistake to make, because if you don't understand the differences between roles, permissions, and scopes it's quite easy to get that wrong. Let's talk about that.

Hey Dana here. Welcome to the channel that helps aspiring Azure administrators to know ops and well, master the Microsoft cloud. I really appreciate that you're here.

So, this episode might get a bit more techy than I'd like to go, but it's important that we really understand the deep dark secrets of how role-based access control works in Azure. There are relationships between the identity and access management system that tie to resource providers that define how resources can be operated on, and while these relationships are well defined, they aren't easily found in the Azure portal. So we're going to jump into the Azure Cloud Shell and explore this using a CLI, but before I do let's talk about how RBAC works in Azure.

The easiest way to see the RBAC system is to look in the access control blade of a resource in the Azure portal. Depending on your tenant, you have over 140 built-in roles that have been set up for you already, but they have been defined in such a way that you'll normally only see them in areas that they're allowed. If you look in the roles tab for a resource, you'll see a filtered view of those roles that can be assigned to that resource type. Role assignments are an important concept in Azure. They consist of three elements. First is the security principle, which makes up users, and groups, and service principles, and even managed identities. Then you have your role definitions, which are really a list of actions that you can or cannot do. And then you have scopes, and a scope can represent anything from a management group down to a subscription or a resource group or even right down to an individual resource. So let's jump into Azure Cloud Shell and explore some of the deep dark secrets behind Microsoft's RBAC system and help connect the dots on how access control works in the cloud.

Okay, so to get started, let's start by first taking a look and seeing the role definitions that are already in your tenant. So depending on what you have installed and configured, there may be different ones but, if we type in, this command, in the Azure CLI: az role definition list we can get a list of that, and I'm just filtering it so that I only show the role name because there's a ton of other data that it will show. So run that, and we can see there is a whole bunch of different roles that are available and if we were to just take a quick count, depending on the subscription you're in, so this one I have 142 for this tenant.

I guess the best way for us to look first, is just to take a look at what a role definition looks like.

There's three roles that are well known that are attributed to pretty much any type of resource and that is the owner role, the contributor role, and the reader role. An owner is the one when doing the management within an Azure resource that has the most amount of privileges. So if we were to go and take a look at that one, we can see the role definition for owner. So if you've never seen this before, the definition for the role has an assignable Scopes, which is where can we apply or use this role? So when you build your own custom roles, you can actually assign it to let's say a specific scope of a resource, a resource group, a subscription, or even a management group.

So in this case here, it's saying at the root, which means it can be used everywhere, and you can see the description that Microsoft already applied to it, let's you manage everything including access to the resource. You can also see, and what's more important, is the perms, and there's really four sections of this to look at. There are the actions, or the things that you are able to do from a management perspective. There is notActions, which are basically what you're not allowed to do, and if the provider supports it, they'll have data actions and notActions, which is the same type of permissions, but to the data itself. So as another example, if we were to take a look at the contributor role. Contributor has the same privileges as owner, except that they are not allowed to give other people access. So if we were to look at their- the action is a star, which is a wild card, just like the owner, which means they have full privileges, but then, there is some notActions here, which says in the authorization module, do not allow them to ever delete or to write in the authorization area and of course, we have some issues here with the blueprints as well. If we were to then look at reader, it has even less privileges.

So in this particular case, there's- when it comes to what we call an action, there are four major things to look at, so the asterisks, which means, you know, full privileges. Then there's read, write, delete, and then a special one called action, which is about specialty things that our resource type might permit or allow. So in our case here, the reader has only read access to anything in the system. So again, we're saying in the root of the tenant, we're permitting them to have read access to everything, and that's what the reader role actually does inside of that, but let's go and look at something with maybe a little more depth. So if we were to look at something like, let's use like a virtual machine contributor. So if we were to take a look at something like that, these are built-in roles Microsoft has provided, specifically for certain types of role types.

So if we were to go and look at Virtual Machine Contributor, you'll see that there is a lot more that's been applied into this definition, but what that is, is instead of giving Carblanch access to everything, it is limiting what actions are permitted. So in this case here, you can see they have the ability to deal with Compute for virtual machines and DevTestLab/schedules and the loadBalancers and the Network interfaces, and I'm not going to read each one of these, but what you can see, is that this specific role, that is dedicated for Virtual Machine Contributor, is giving them pretty much full access to be able to do the work that they need to for Virtual Machines, but again you'll notice that there's been not dataActions. So let's take a look at maybe a role that actually has dataActions to it. Maybe something like, what would be a good one? Storage Blob Data Owner, see if we have that as an example.

So in this case here, what you can see, there are actions on what they're permitted to do, so they're able to read inside a blob container, they have to access to do everything they want to, but they also have the permissions in a dataAction to be able to do everything inside of that blob. So the difference is, where actions are management focused activities, the dataActions are the ability to access the data, which is why you'll see, if you assign someone a role like owner, they won't actually have permissions to read the data directly, now there are ways that they can get through that, by getting SAS keys generated or doing other things, but by default, the owner doesn't actually have the ability to do that.

Whereas, if you gave someone Storage Blob Data Owner, now they have access to manage the data. Vice Versa, a role where they assign only the data owner, but not actual owner, means that they would be able to manage the data but not the configuration of the meta data or the resources themselves.

So that's kind of one way of helping understand how these different roles can have different sets of permissions. Now, we haven't actually assigned them yet, right? That is a key thing to think about is that because you need to assign it to the security principle like the users, or the groups, or the managed identity, we need to be able to think about, what are these actions themselves before we worry about how we apply them to people, and one of the ways to look at that, is by understanding where does this actually come from?

Though this comes from what are called resource providers, and its interesting that depending on what you have installed into your subscription, you'll see different things than what I'm about to show you here, but each one of these things are exposed from what's called a provider, and you can take a look at the provider, and we only want to just look at ones that have actually been registered in this particular tenant. So for this particular one, you can see here that we have a bunch of different things like containerInstances, logic apps, and containerRegistry, and web apps, and what not, keyVault, managedIdentity. These are the specific resource providers.

Now, if we were just to take a look, maybe at the first one that's there, the Microsoft.ContainerInstance, just to show you what it looks like, what you will see is a listing of the different types of resources that it's going to expose into the platform. So in this case here, containerInstances is doing things like exposing containerGroups, and in those containerGroups there are actions like Microsoft.ContainerInstance/containerGroups/read. You'll also notice a special thing in here, which is a flag of isDataAction. This is what defines when a provider registers which resource types are in Azure, defines if it has a dataAction, that we're able to explicitly set here. So when you're then defining your actual roles, you'd be able to understand what actions or dataActions are acceptable and are allowed for this type of resource, and it's important to look at that, so if we wanted to go and take a look at one, where we are talking about the data access as an example, we can look at something like Storage, since we were just talking about that Blob, data owner, if we go and take a look in the storage, we'll actually see that there are some examples, such as here, where we're exposing dataAction, for the Blob service for the read, and you can see different kinds.

There is read, write, and delete access, as well as things like delete automatic snapshots, et cetera, et cetera. So now you have an idea of how it all works together. Resource providers define the operations that facilitate what actions and dataActions are exposed by individual resource types. Role definitions define what permissions can and can not be applied, as well as what Scopes the role can actually be used in. You can then create a role assignment where you take the role definition, assign it to a security principle, and apply it to a Scope.

Does that make more sense now? It'll take practice, but if you explore this in the Azure Cloud Shell, you'll be amazed at how much you can uncover. The Azure portal masks a lot of this for you, but it's always good to understand how it works behind the scenes. I hope you found this useful, do me a favor and show me by hitting thumbs up and leaving a comment about what you thought. Smash subscribe, if you haven't already so that we can notify you when I publish more videos, and above all thanks for watching. We'll see you in the next episode.


 
There are relationships between the identity and access management system [in #Azure] that tie to resource providers that define how resources can be operated on. #knowops @auditwolf
 

 

  Tweet

 

Topics: Cloud Security, Cloud Operations (CloudOps), KnowOps

Comments