#1 Azure role-based access control (RBAC)

By Christopher Melendez

Starting a business can be a daunting task, never mind building a business on bleeding edge technology.  Managed Service Providers are unique in the aspect that their businesses are built on technology that is not yet widely adopted as a culture.  This can be a problem with finding skilled workers that are knowledgeable in the platform, as well as finding good resources to help architect your practice and build good operational habits.  With all this in mind, I felt it would be of help to come up with a starting point for any brave souls looking to go to market with Microsoft Azure.  So, here’s my list of the first 10 steps or concepts you should be thinking about, once you’ve procured your Azure CSP subscription.  This article goes over the concepts at high-level, so I’ve provided links to labs and documents that will help you begin your journey on the right step.

Manage access to your Azure Subscription with RBAC

The first thing that is critical when deploying and operating an Azure environment, is identity management and governance.  Identity management is the creation, deletion, and granting, removing of permissions to Azure resources.  These Azure resources will be deployed into your Azure Subscription leveraging the Microsoft Azure Portal. Each Azure subscription is tied to a single Azure AD directory. Users, groups, and applications that are granted the appropriate permissions, can manage resources in that subscription. Azure AD is the identity provider for this subscription and provides sign-on (SSO) and access management.  Azure resources and Azure Active Directory have independent permissions.  Azure role-based access control (RBAC) roles are used to managed access to Azure resources like virtual machines, and storage.  Azure AD roles are used to managed Azure AD resources, such as users, groups, and passwords.

Role-based access control (RBAC) provides the access management needed to adjust permissions to Azure resources with granularity.  This allows you to grant the exact access needed for the user to perform their business functions.  For an MSP, this could be delegating access to a group of users to manage Azure Virtual Machines across 5 different subscriptions, while another group of users cannot manage VMs, but can view all Cost Management and Billing.  Azure provides a lot of built-in roles, and you can create custom roles if needed.  Here are 4 built-in roles, Owner, Contributor, Reader, and Billing Administrator.

Some of the main terms that you’ll have to become very familiar with are Scope, security principal, role definition and role assignment. The Scope is at what level you’re granting the access. It could be at the Subscription level, where you’re granting access to all resources under the subscription, or it can be at the specific resource level, say a storage account. A Security principal is a fancy term for a user, group, or application that you want to grant the permissions to.  Role definition is the collection of permissions that you will be granting to the user.  A role for short, can consist of read, write, delete; they can also be higher level, like Owner, or more granular, like Billing Reader. The combination of the role definition and the security principal is role assignment.  It’s the actual process of binding the permissions to the user, group, or application.