Azure Role-Based Access Control (RBAC) - Simply Explained

0:00 Azure role based access control is really just a keycard, not a light switch. A light switch is either on or off for a whole room, while a keycard opens specific doors for a specific person. Most of us learned permissions the light switch way, which is why access so often ends up wider than anyone planned. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Today, we're breaking down how access works in Azure, and it comes down to three moving parts you can hold in your head. By the end, you'll be able to look at anyone's access in your subscription and know exactly why it exists. What RBac actually does. Role based access control answers three questions about every resource you own, and it asks them again on every single request.

0:40 Those questions are who can get in, what they're allowed to do once they're inside and how far their reach stretches. That sounds like a lot of machinery, and it isn't. Microsoft describes it as an authorization system built on Azure Resource Manager, the service that receives a request and decides whether to carry it out. Authorization is simply the decision about what a person who already signed in is allowed to do. Picture a building with one shared front door and plenty of locked rooms. Everyone comes through the same entrance since signing in proves who they are, and then each person carries a keycard for the rooms. They need some cards, open one storage closet and some open an entire floor. Nothing in Azure is open. By default. Access exists because someone created a role assignment and it disappears when someone deletes that assignment.

1:20 No switch flips on a person and no permission turns itself on while you're not looking. So when a teammate can suddenly see a resource they've never touched, the explanation is almost always the same. Somewhere in the hierarchy, an assignment exists, and finding it tells you the whole story. One thing worth clearing up early is that this isn't a paid extra or a premium feature. Microsoft states that Azure RBac is free and included with your subscription. You meet it in the portal on a page called Access Control, where the IAM label shows up at every level of the hierarchy. The payoff is that you can hand someone exactly the access their job requires and nothing more. One person manages virtual machines, another looks after the networks, and a database team manages the databases, all without tripping over each other.

2:00 Those three pieces are what deliver it, so let's open them up. The three pieces of every role assignment, every assignment in Azure is built from the same three parts, and Microsoft treats that structure as the core of how permissions get enforced. Miss one part and the assignment stops meaning anything. The portal walks you through all three whenever you add an assignment asking for a member, a role, and a scope before it saves. First comes the security principle, which is the formal name for whatever is receiving the access. That could be a user, a group, an application identity, or a managed identity that Azure creates and rotates on your behalf. Second comes the role definition, which is the bundle of actions a role allows. The list runs from read and write through to delete. With a few hundred variations on those three roles come in every size, from the enormous owner role down to something narrow like Virtual Machine Reader.

2:45 Third comes the scope, which is the set of resources the role applies to. Scope is the part that decides how much of your environment a single mistake can reach, so it deserves the most care when you're setting things up, only the combination carries meaning, which is the peace beginners usually miss. Contributor on one resource group. Let someone manage everything inside that folder and nothing outside it. Contributor on a whole subscription lets that same person manage every resource you own, which is a completely different outcome from the same word. Two items on that list sound strange if you've never administered a cloud environment, a service principal is a username and password for an application, so software can sign in and do its job without a human sitting there and managed identity works the same way with the password removed, because Azure holds the credential for you, and no secret ever ends up sitting in a config file.

3:29 The first two parts are the easy ones. You either pick the right person or you didn't, and you either picked the right role or you didn't. And both of those decisions tend to sort themselves out quickly. Scope is where the real trouble hides. So that's where we're going next. The four sizes of scope scope comes in four sizes, and Microsoft lists them from the widest down to the narrowest. They are the management group, the subscription, the resource group, and the resource. A management group is a container that sits above subscriptions, and it exists so large organizations can arrange many subscriptions into one tree. Most beginners never touch one, and you still need to know it's there, because access granted at that level reaches every subscription underneath it. Next in the hierarchy comes the subscription, which is usually the first boundary you meet.

4:10 It holds your billing, your service limits, and a set of resources that belong together. And for most people, it's the only boundary they ever think about. Below that sits the resource group, a folder inside a subscription that holds related resources. So teams tend to organize them by project, by environment, or by department. The smallest unit of all is a single resource. And it means one thing. It can be one storage account, one virtual machine, or one database. The portal shows this as a drop down, and the level you pick there decides how much of the tree a single assignment covers. Inheritance is the rule that makes this hierarchy matter, and it runs in one direction only. Access given at a parent level flows down to everything underneath it. Assign reader at the management group level, and that person can read every resource in every subscription inside that management group.

4:51 The reverse never happens because access given deep in the tree doesn't climb back up. The additive rule surprises even more people. Azure works out your effective permissions by adding up every assignment you hold, so a broad assignment cancels out a narrow one. Take someone who holds reader at the subscription level and contributor on a single resource group. Their effective access for that subscription is contributor, because the sum of the two roles is contributor, and the reader assignment changes nothing at all. That's why adding a small role to fix a big problem so rarely works. Group membership adds one more layer. Since assignments made to groups are transitive. If you sit in a group and that group sits inside another group holding an assignment, you inherit those permissions whether anyone meant you to or not. Once you can see how far a scope reaches, the next question is the one you came here for, which is the role you should put on it, the roles you'll actually meet.

5:38 Microsoft ships more than one hundred built in roles for Azure, and five of them form the foundation of the whole system. You'll meet the rest one service at a time as your work takes you into them. Owner is the biggest of the five. It grants full control over every resource at the scope, and it also grants the ability to hand out access to other people. That second power is the part that changes how you should use it. Contributor grants the same full control over resources with one difference that matters. A contributor can't assign roles to anyone, so they can build things and delete things, but they can't open doors for other people. Reader is exactly what it sounds like. Someone with reader can look at resources and can't change a single thing, which makes it the safest starting point on any project. The last two are the Access Managers, user access administrator, and role based Access Control administrator.

6:20 Both manage who can reach what Microsoft groups them with owner as privileged roles, because either one can grant the owner role to themselves or to someone else. Beyond those five sits the long tail of job function roles, each aimed at one service or one kind of task. Virtual machine contributor let someone create and manage virtual machines without touching your network or your data storage blob. Data reader lets someone read files in a single storage account with no write access at all. There's one subtlety in those job function roles that catches people early, and it's worth understanding before you assign anything. Managing a resource and reading the data inside it are two separate permissions in Azure contributor on a storage account lets someone create and configure that account, and it doesn't let them read a single file inside it. Reading the data takes a separate role aimed at the data itself.

7:03 When you go looking for the right role, start from the service category instead of the top of the list. Microsoft's built in roles page is arranged by service, so searching for a word like blob or virtual machine narrows hundreds of options down to a handful. Microsoft's guidance for choosing between them is refreshingly simple. Start with the most restrictive role that still lets the person do their job and step up only when the work can't happen any other way. If someone needs to read blobs, the reader role does the job, and the contributor role hands them far more than they asked. For least privilege is the whole point. Least. Privilege is the name for that habit, and it means giving someone the smallest role at the smallest scope for the shortest time that still lets them do their work. The reason it matters isn't tidiness or paperwork.

7:45 Limiting the role and the scope limits what an attacker can reach if that account ever gets compromised. So a small assignment means a small blast radius. Microsoft's own guidance puts it plainly avoid assigning broader roles at broader scopes, even when the broader option is more convenient in the moment, because convenience today becomes blast radius tomorrow. One number from Microsoft's documentation is worth remembering. Microsoft recommends a maximum of three subscription owners, because every extra owner adds another path for a compromised account to spread. Least privilege isn't a project you schedule, and it's a habit you apply at the moment, you create an assignment. Someone who needs access for a two week migration gets a role for two weeks, not a role forever. Taking it back afterward is a single delete, not a hunt through a spreadsheet.

8:26 The other reason teams stick with it is that small assignments are easy to explain. When a manager asks who can touch the finance subscription? A handful of group assignments take a minute to explain four hundred individual assignments. Take an afternoon of digging for the privileged roles. The patent gets tighter still. Use the narrower scope that works, such as a single resource group instead of the whole subscription, then turn on just in time activation through Microsoft Entra privileged identity management so the privilege exists for a short window instead of forever. That last option needs a paid entry ID tier, so treat it as something to grow into instead of a default you're missing out on. And if the built in roles genuinely don't fit your situation, that's the one case where building your own starts to make sense, which is exactly where we're headed.

9:06 Built in or build your own built in roles are ready made and Microsoft maintains them, which is the main reason to start. Their custom roles cover the gap where no built in role matches what a team needs, and they can be shared across subscriptions that trust the same tenant. Microsoft keeps the built in list current as services change, and that upkeep is exactly what you inherit the moment you build your own. A role is just a written list of allowed operations, so a custom role means your team owns that list. From then on. The process itself is less scary than the name suggests. You usually begin by cloning the closest built in role and trimming out the permissions you don't need. From there, you give the role a set of assignable scopes so Azure knows where it can be used. Then you test it against a real task before handing it to anyone.

9:47 The trade off is his ownership. The moment you build a custom role, it becomes something your team has to maintain. Services, add new permissions over time. So a role that fits perfectly today can drift out of shape. Microsoft has a specific warning about how people write custom roles using an asterisk instead of naming the actions you want means the role also picks up permissions Microsoft adds later, and that is access nobody chose or reviewed the limits. Keep the model honest to. You can hold up to five thousand custom roles in a tenant and a custom role that includes data. Actions can't be assigned at management group scope. For beginners, the practical advice is short reach for a built in role first and treat a custom role as the exception. You can explain, not the default you reach for Azure roles are not entry roles.

10:29 There's one more source of confusion, and it has nothing to do with custom roles. The word role shows up in two places in Microsoft's world, and they're separate systems with separate assignments. Azure roles control access to Azure Resources, which means virtual machines, storage networks, and databases. Microsoft Entra roles control access to directory resources, which means users, groups, domains and licenses. The scopes don't line up either. An Azure Role can be assigned at management Group, subscription resource group, or resource scope. An entry role is assigned at the tenant level, at an administrative unit, or on a single object, such as one application. If you're ever unsure which system you're standing in, ask what the person needs to change. Changing people, groups, or licenses puts you in Microsoft Entra and changing virtual machines, storage or networks puts you in Azure.

11:14 Plenty of people hold roles in both systems at the same time. Then comes the consequence that catches people most often. A global administrator doesn't automatically get access to Azure Resources because that badge manages your directory and not your subscriptions. That person can change the situation, and the mechanism is worth knowing. A global administrator can flip a switch in the portal that grants them the User access administrator role across every subscription in the tenant. It's a deliberate action instead of a default, and plenty of organizations never notice until an audit asks who holds what. One more piece of history sits behind all of this the old classic subscription administrator roles are fully retired, the ones named Account Administrator, service administrator, and Co-administrator. That means every access decision in Azure today runs through role based access control.

11:57 When you can tell those two systems apart, the habits that cause trouble become much easier to spot the mistakes everyone makes. Most of the trouble in real subscriptions comes from a short list of habits, and every one of them is easy to fix once you know what to look for. This part sounds like advice for large companies, and it applies just as much to a subscription with three resources in it. Start with the habit almost everyone picks up first. Owner sits at the top of the role list, so it becomes the default choice because owner can hand out access, one owner account turns into a way of creating more owner accounts while nobody is watching. Then there's the habit of assigning roles to people instead of groups. Group assignments collapse dozens of individual assignments into one.

12:37 And when Microsoft explains how to fix a subscription that has run out of room, this is the first move it recommends. Another one is easy to miss because it isn't a mistake you make on purpose. Permissions inherit and add up, which is how someone ends up reaching a resource nobody remembers assigning, and the assignment usually sits further up the tree than anyone bothered to look. The assumption that costs people an afternoon is that an office wide admin role unlocks Azure. It doesn't. Not by default, and administrators regularly end up staring at an access denied message on a subscription they thought they controlled. Writing a deny rule sounds like the obvious fix, and Microsoft states that you can't directly create your own deny assignments because Azure creates and manages. Those. Access goes away when you remove the assignment that granted it, not when you write a block. Some teams find the sealing the hard way.

13:19 Azure allows five thousand role assignments per subscription and five hundred per management group, and both limits are fixed. The usual cause of hitting that ceiling is thousands of individual assignments handed to individual people. Nested groups carry permissions further than most people expect. A person sits in a group. That group belongs to a bigger group, and the assignments attached to the bigger group land on the person without anyone announcing it. The last one shows up in automation rather than in the portal Microsoft recommends using a role's unique ID instead of its display name. Names change preview roles get renamed when they release, and anything automated against the old name breaks without a warning. Every one of those comes back to the same small decision. Pick the smallest role that does the job.

13:59 Put it on a group instead of a person, and set the scope as low in the tree as the work allows. Do that consistently and most of these problems never get the chance to start. Recap and one open question. So let's collect what we've covered. Every role assignment in Azure is a who, a what and a how far and nothing is granted until someone creates one. Permissions flow downhill, they add up and they disappear. When you delete the assignment, instead of blocking it, keep the habit and the rest. Stay simple. The rule is the smallest role at the smallest scope assigned to a group. If this made Azure feel a little less intimidating, subscribe to M365 FM because we take one part of the stack at a time and explain it in plain words. Before you go, I'll leave you with one question to sit with. If you opened your subscription today and walk through every assignment on it, would you be able to explain why each one is there?