Why Use Role Based Access Control in Azure?

Share this post:
Have you ever had someone come along and interfere with your work?

Dealing with this sort of problem, whether intentional or accidental, can be a major buzzkill. Let me tell you about Carol from Finance. We all know Carol. She is constantly meddling in everyone’s business and reminding us how she saved nearly one hundred grand last year due to her savvy budgeting. Well, last night Carol decided it would be a great idea to turn off some Azure resources to help reduce the cloud bills. She powered off a VM that was temporarily serving as a SQL server during database migration. The next thing I know I’ve got tickets coming at me in every direction.

What if I told you there was a way to keep the Carols at bay?

Fortunately, Azure offers a type of Role-Based Access Control, powered by Azure Active Directory. Azure RBAC is a feature that helps manage who has access to Azure resources, what areas they have access to and what they can do with those resources. The process of restricting or granting access is an example of implementing the principle of least privilege, allowing users access to what they need without giving unnecessary access. When admins implement role assignments, users can still get their work done but by the grace of governance, Carol can’t sabotage your efforts.

Is Azure RBAC necessary?

You may be thinking, “I’m already using Azure Policy. Is Azure RBAC really necessary?” Well, let me ask you… when ordering a cheeseburger is the bacon and jalapeno ranch necessary? Of course not! Does is it make for a delicious treat? ABSOLUTELY!

Azure RBAC works best in conjunction with a variety of governance methodologies based on organizational needs to tailor a custom fit. Azure Policy is resource-centric while Azure RBAC is mostly user-centric. I know this seems like a fine line, but you can read more about it here.

How Does Azure RBAC work?

Azure RBAC assignments consist of three main components, defining the scope, defining the role and assigning a security principal.

First, let me explain scope. If you have ever had to manage Windows permissions, then Azure RBAC should translate well for you. The most common Azure roles (Reader, Contributor, and Owner) remind me of NTFS permissions read, write and full control.

If you are familiar with the Windows File System Structure, you may understand how those NTFS permissions propagate downward via inheritance. If you are not familiar with this concept of inheritance, just think of inheritance in the literal sense. Typically, if a parent passes away the belongings or personal items will be given to the children of the family. Instead of children, Windows has child objects such as nested folders and files that receive the permissions inherited by their parent objects.

When moving to the cloud permission enforcement is similar. Scope can be assigned at the Subscription level but child objects such as Resource Groups and Resources also receive the role assignments. Understanding this will help you determine at what level to assign the role.

Next, you need to know what you want to assign. You can select from pre-configured built-in roles or create a custom role definition. Role definitions are composed of one or more role permissions allowing or not allowing certain actions. I could, for example, allow Carol to log into the VM but not allow her to shut it down.

Lastly, I need to know who I want to assign this role to. I should start by clarifying the “who”. In this context “who” is referring to a Security Principal. Security Principals could be in the form of a user or user principal (Carol), a group of users, a service principal (like a username and password or certificate for an application) or a managed identity (an automated way for Azure to manage the credentials for authenticating to Azure services).

If you are new to working with Azure RBAC, I recommend using the Azure portal although configurations can also be made via Azure PowerShell and Azure CLI. Go ahead, try it out. To give user access at the subscription level, use the portal and navigate to your Azure Active Directory page. On the left-hand pane under Manage, select Roles and administrators.

On the next page, you can select from a list of predefined roles or create a custom role.

The following page is where you can select who you would like to assign the role to.

This can also be done at various scope levels by selecting Access control (IAM) on the left pane of the Resource Group or Resource page.

Explore all the settings options so you feel comfortable prior to configuring this in a production environment. Remember, once you define the scope, define the role and assign a security principal you can say “Eat that Carol!”

Leave a Reply

Your email address will not be published. Required fields are marked *