If you read my previous post, you might remember Richard Inc., our beloved (though make-believe) Nigerian food delivery startup that recently made it to the cloud. Well, status update: business is booming! Orders are now coming in from all over the country, the app is running smoothly, customers are happy, and Richard (the founder in this story) has hired 200 staff. This includes a few developers writing code, a few managers approving budgets, interns doing God-knows-what, and maybe automated robots handling food deliveries outside daylight hours. Now every single one of these people (except maybe the robots) need access to the company's cloud resources on Azure.
To provide access as quickly as possible, he provided a master login — one username, one password. Once logged in, he figured all members could then navigate the platform. Big mistake! Just 3 days after this, an overexcited intern, thinking he was in the test environment, accidentally deletes the entire production database on a Friday at 4:55 p.m., just before the weekend rush! Richard nearly had a stroke! It is to prevent strokes for founders like Richard that Azure has an entire system built around who you are, what you are allowed to touch, and how far that permission reaches — kind of like a well-run company organizational chart.
At the top are Management Groups, kinda like Richard Inc.'s business divisions — one division handling deliveries, another for acquiring groceries, another perhaps handling the logistics of expansion. Policies and permissions set at this level can be inherited by everything underneath.
Below Management Groups are Subscriptions, almost like departments within the business divisions. Subscriptions in Microsoft Azure are essentially containers within which most cloud resources are created and managed. Also, because they tie resource usage to a billing account, when assigned to departments within the divisions of Richard Inc., each department gets its own invoice, providing cost visibility (a neat business trick very useful in planning).
Next are Resource Groups, kinda like project folders within which the actual cloud tools live: logical containers that organize related cloud resources together — Virtual Machines (cloud computers running Richard Inc.'s software), Databases (storing every order, every customer, every delivery record), Storage Accounts (holding receipts, images, invoices), and Load Balancers (which distribute incoming traffic across multiple backend servers or computing resources so that no single server bears a disproportionate share of the workload — like traffic wardens making sure that when ten thousand people order "jollof rice" at the same time, no single server has a breakdown).
Now, how do we solve the intern problem? Simple! Microsoft Entra ID (formerly called Azure Active Directory/Azure AD). Microsoft Entra ID is essentially like a smart staff register and assigns identities in four ways — User Identities, Groups, Service Principals, and Managed Identities. Identities assigned to real people such as Richard the founder, his developers, managers, and yes, the intern, are User Identities. If there are maybe 50 developers requiring permission, creating individual user identities can be exhausting. One way around this is putting everyone involved in a Group and assigning permissions to the group that every identity within the group instantly inherits. Once permissions are assigned to the group, every member of that group inherits those permissions automatically. Service Principals and Managed Identities are slightly more technical (we'll talk about these another time).
All identities and access rules for Richard Inc exist inside a dedicated private identity space in Microsoft cloud called Azure Entra Tenant associated with one or more unique addresses/domains
Now, what happens when a User attempts to log in? First, Authentication — basically the bouncer at the door who checks if you are actually who you say you are. To prove your identity, you provide a username, password, and even multi-factor authentication (where you also have to confirm via your phone or a secondary device).
Next is Authorisation, where Azure decides, "Okay, we know it's you — but what rooms are you allowed to enter?" The single most important safeguard that would have prevented the intern from deleting production files.
Still, this is a lot! How does Azure handle authorizations for, say, 10,000 employees? Yikes! The poor Cloud Engineer, huh? Lol, not quite.
Using something called Role-Based Access Control, or RBAC, authorizations can be done at scale — not by writing a custom set of rules per individual, but by assigning roles to individuals, each role coming with a predefined set of powers.
For this Role-Based Access Control model, there are four roles worth knowing: Owner, Contributor, Reader, and User Access Administrator. The Owner can do everything — create, delete, modify, and hand out permissions to others. This is Richard himself (the founder), or maybe his Chief Technology Officer. Contributors can build and manage resources but cannot grant permissions to anyone else, e.g., senior developers. The Reader can see everything and touch absolutely nothing. Perfect for an investor who wants visibility or a compliance auditor reviewing the system. And then there's the User Access Administrator, who can only manage permissions — can't create a single resource, just handles who has access to what. Great for an operations manager who onboards and offboards staff regularly.
In all of these roles, however, one golden rule applies — Least Privilege, which essentially means: "Give every person and every system the minimum access needed to do the specific job, nothing more."
Another important idea in Azure RBAC is Scope. Beyond the assigned Role, how widely does it apply? The wider the scope, the more powerful the role. A Contributor at Management Group level can touch everything in every department. A Contributor at Resource Group level can only touch one project folder. Same role, very different levels of power.
Oh, by the way, the intern was reassigned to Reader access only. He's doing great!
