21 Feb, 2019

The Azure Security Model, Part 1 - Access Control Basics

by Alex Useche

Setting foot in the vast cloud kingdom of Microsoft Azure can be somewhat of a daunting and, at times, confusing experience. This is particularly true if you are used to relying on Amazon’s AWS products for developing and working with cloud applications. First off, there is a myriad of new concepts to learn and to map out: tenants, subscriptions, resources, services, etc. Then there is Azure Active Directory. Do you really need it? Can’t you just create Access Control (ACL)lists as you would in AWS? These are just some questions you may find yourself asking as you scroll (horizontally) through the Azure portal.

This first post in a series on Azure security aims to be a beginners guide to help you navigate Microsoft’s blue cloud kingdom. We will begin our journey by understanding how resources are organized in Azure. Next, we will dive into access control features that are available to us. We will provide you with the information you need to start adding users to your tenant and controlling access to resources. Lastly, we will discuss service principals and what you may need them.

The Lay of the Land

Welcome to the Microsoft Cloud kingdom, I will be your tour guide on this cyber occasion. Before we continue, I must warn you; if you have come here expecting to do things the AWS or Linux way, you will experience turbulence and confusion. Therefore, I suggest that you clear your mind, embrace adventure, and enjoy the ride.

Azure may seem complicated at first; however, you will have an easier time if you come with the understanding that you are setting foot in Microsoft’s land. If instead, you are constantly searching for AWS equivalents to every new concept you encounter in your journey, you will struggle. With that in mind, let’s start by undertanding some basic Azure concepts.

Azure Tenants, Subscriptions, and Resources

A tenant can be thought of as an instance of Azure Active Directory. A tenant can have the name of your company or even some something like yourname.onmicrosoft.com if you created an Azure account using a personal account. That tenant can hold multiple subscriptions, which you use to pay for resources. Those resources are organized using resource groups (unless you are using Classic model resources, which we won’t discuss this time around). Microsoft’s official description of this hierarchy can be found here.

A user may be a member of multiple tenants at the same time. For instance, I am part of the nVisium tenant, and I have two additional tenants that I have created for testing purposes and that have no connections to nVisium whatsoever. To see all your available tenants, you would click on the user icon on the top right of azure and select switch directory. A directory is just a logical way to separate tenants, so it helps to think of directories as tenants.

tenants

In the above image, we see multiple available tenants under “All Directories” (some of which have some pretty fancy names). The current tenant is called alexsupersecrettenant, and it has one subscription available. In the above case, I have a student subscription, as I get $100.00 of free credit. Also, notice how there are two other (disabled) subscriptions associated with that tenant. Even though the resources may be under the same tenant, they can be logically separated between subscriptions.

Some companies use only one subscription for the entire organization, while others may have multiple subscriptions under their tenant. In that case, they could allow different departments to use different subscriptions. A multi-subscription tenant could be beneficial if you wanted to get a different bill for each subscription, therefore allowing you to track spendings by subscription.

Each subscription within a tenant (or directory) has its own set of resources, which are in turn organized using resource groups. Resource groups allow you to group resources that are related in one way or another in logical containers (not the Docker type), thus allowing you to apply access control rules and policies to all resources within a group at the same time. For instance, let’s say that your developers need to deploy an Azure Function that processes log data and saves that data in Cosmos DB, a NoSQL database service offered by Azure. The developers need 3 different environments: Dev, UAT, and Production. To solve this problem in Azure, they can then create three resource groups, one for each environment. Though all environments would have the same resource types (1 Azure function, 1 application service, and 1 Cosmos DB database), they could manage them separately by assigning policies and restricting access to each environment. For instance, the QA department could have access to the UAT environment only, and the Production environment could include a policy that enforces strict encryption protocols.

There is no definitive guide on how to use resource groups. For example, you may want to grant a group of users access to only some resource groups. What is important is to have some sort of strategy in mind when creating resource groups, as it can be very easy to end up with multiple resource groups that only hold one resource. The reason for that is when you create a new resource, Azure assumes that you want to create a new resource group, so it selects the “Create new” radio button by default and it auto-populates the name of the resource group based on the name of the resource:

new resource group

If you are not careful, you may end up creating new resource groups for every resource you create.

Azure Active Directory

You create and add users to your Tenant using Azure Active Directory. Note however that Azure Active Directory is not the same as an on-prem domain controller. You do not need to fear the words “Active Directory” and worry that you need to make a more significant jump into the cloud than what you expected. Azure will not force you to move your entire on-prem AD to the cloud, though you may find it useful to do so at some point in time. How you configure Azure Directory depends on your business needs and on how much you wish to commit to Azure. If you are a small company that primarily uses Linux, you may want to create users as needed using Azure AD; however, if you are a bigger company that already relies on on-prem Active Directory for managing users, you may want to consider synching up your AD to Azure. This would result in what Azure calls a hybrid AD environment, as your on-prem AD is kept in sync with your cloud AD.

There are two main types of users that you can create in Azure Active Directory: a guest user and, for lack of a better term, a non-guest user. Regardless of the type of user you create, that user will be in your Azure Active Directory. Let’s demonstrate.

In Azure, click on “Users” on the left, and then on “Azure Active Directory.” Select “New User”:

new user

Now let’s enter a name and an email address for the username. After filling out the form, we get an error, as Azure does not accept the email we provided:

new user error

When we hover over the “!” symbol, we get:

'example.com' is not a verified domain.

We cannot add a non-guest user to our domain unless we have verified the email address domain. Remember when I mentioned that you are entering Microsoft’s territory? Users that get added to your Azure AD are assumed to come from an organization that you own. To verify a custom domain, follow the steps in this document.

Ok, I do have a fancy domain name that I have registered with Azure (I will not let you see it though, because of reasons) and that we can use to create an account:

new user success

When you add an email address from a verified domain, we can create a new user without any issues. Notice also how we are given a password. You must, as an Azure admin, share the password with that new user in a secure manner so that they can log in. If on the other hand, Azure AD was in-sync with your on-prem AD server, the user would use his/her existing AD password.

Now let’s create a new guest user. According to Microsoft, a guest user is a user that you can invite into your organization so that they can collaborate with you. That may sound like a different way of saying “a user account you create for a contractor or consultant.” However, guest users can be setup just like any other user in your Azure AD (with a few exceptions, as we will see in a moment), as you can assign them the same roles that would assign to any non-guest user. The advantage for us in this case is that the user can have any email address, as opposed to an email from a verified domain. Let’s go ahead and add a new guest user.

Back in the Active Directory “Users” section, click on “New Guest User,” fill out all required fields, and click the “Invite” button.

new guest user

There is a significant difference to note between the two types of users we have created. The first (non-guest) user we created will access your Azure tenant using a Microsoft work or school account that they can create (if they don’t have one) using the password that Azure gave you when you created the account. On the other hand, the guest user will access your tenant using their personal Microsoft account. What happens if a user has an email address associated with both a work/school account and a personal account? Even though the account may be associated with the same email address, the accounts are entirely different. Furthermore, while you can reset the passwords of non-guest users, you cannot do the same for guest users. The guest user must create a Microsoft personal account to log in to your tenant, even if they already have a work/school Microsoft account. When they log off and log back into https://portal.azure.com they will see a screen like this, asking them to select the type of account they want to log in with:

new guest user

Directory and IAM roles

Great, so we have created a user account. Things are looking great so far, or so we think. Then, the users that we created decide to log in to your tenant, they try to create a resource, and then they see this:

new user issue

What did we miss? For users to do anything in your tenant (e.g., create and view resources) you need to assign them roles scoped to a subscription. After all, Microsoft needs to know what subscription to bill to when your new users start creating resources.

There are two types of roles that you can assign a user: Directory Roles and IAM roles. Directory roles are assigned at the AD level, and grant users access to managing tasks such as sharing accounts and using policies. However, directory roles are not sufficient, as users who need to create and destroy resources also need IAM roles assigned at the subscription level.

Let’s assign roles to our users at the subscription level. To do this, first type “subscriptions” in the Azure Portal search bar, and click on it once it appears on the screen.

new user issue

Next, we select the subscription that we want to grant users access to, and click on “Access Control (IAM).” From here we select “Add” and click on “Add Role Assignment.”

IAM

Now we select the user and desired role, in this case, “Owner,” and we click on “Save.” We can verify the role assignment by selecting the “Role Assignments” tab. We can also click on the role name if we wanted to know what permissions that role has. You can also find a comprehensive list of roles here.

owner

Ok, I know what you are thinking, “that role seems very permissive.” You are right. We can solve this problem by creating custom roles, though we will explore that in a future blog post.

The owner role will allow the user to create new resources. The same role will allow the user to create role assignments at the subscription level. This is important, as developers may need to register service principals and assign roles to app registrations to use automation tools such as Terraform for provisioning resources.

Note that, while we have assigned a user the owner roles at the subscription level, we can also assign roles at the resource group, and even resource level. Nevertheless, roles are inherited in Azure, so if a user has “owner” roles assigned for a subscription, then they will be able to perform “owner” tasks for all resource groups and services under that subscription.

If instead, you want to assign a user contributor roles scoped to one resource group, you would do the following: In the Azure portal, select “Resource Groups” from the left-hand menu and click on the desired resource group name.

rg list

This group has only two resources. An app service called “fancy-schmancy-api” and a service plan. Notice the “Access Control (IAM)” option on the left. You will see that option whether you are looking at a subscription, a resource group, or a resource. This allows us to assign roles that restricted to various scopes. From here, you can follow the same steps shown above for assigning subscription level roles, only this time they will be added at the resource group scope. Assigning user roles at the resource group level only will not allow them to create new resources.

User Groups

Instead of directly assigning roles to users, we can create groups, create group level role assignments, and add users who need to share the same roles to those groups. This gives us yet another way of keeping track of role assignments.

To create a group, click on Azure Active Directory from the Azure portal and select “Groups.” Click on “New Group” and follow the prompts on the screen, making sure to add group members during the process.

rg list

Next, you need to assign roles to the group. For subscription level roles you can just follow the same instructions we followed above. Instead of selecting a user during the role assignment process, search for and select the group that you created. All users assigned to that group will then inherit the group roles at the subscription level.

Service Principals

Service principals allow you to manage Azure resources using application registrations with roles associated with them. For instance, instead of using the Azure CLI with your user credentials, you can create an Azure service principal and use the Azure CLI with the credentials associated with that principal, which may have only the right set of roles assigned to conduct specific tasks. You can create a service principal in a number of different ways, but by far the easiest one is to do so from the Azure CLI, which you can find here.

Once you have set up the Azure CLI, you can do the following:

Login to you azure tenant

az login

Once logged in, the tool will output a list of the subscription that you have access to. Set the right subscription by typing the following:

az account set --subscription="SUBSCRIPTION_ID"

Now let’s create the service principal:

az ad sp create-for-rbac --name="MyServicePrincipal" --role="Contributor" --scopes="/subscriptions/${SUBSCRIPTION_ID}"

This will output the value you need to configure your application to make use of a Service Principal.

{
  "appId": "00000000-0000-0000-0000-000000000000",
  "displayName": "MyServicePrincipal",
  "name": "http://MyServicePrincipal",
  "password": "00000000-0000-0000-0000-000000000000",
  "tenant": "00000000-0000-0000-0000-000000000000"
}

If you wanted to start using the Azure CLI using the service principal, you would type the following:

az login --service-principal -u APPID -p PASSWORD --tenant TENANT

Wrap Up

There is a lot more to explore: policies, o365 accounts, managed identities, etc. We will continue sharing information regarding Azure security, and will dive deeper into securing specific resources. Hopefully, this post can give you an idea as to how to approach user access control in Azure and hopefully things are a bit less confusing. Happy cloud adventures!