Role-Based Access Control- Azure-topic

 Role-Based Access Control

In this section, we’ll take a look at Role-Based Access Control (RBAC) to understand how you can use it to manage the security for your Resource Manager resources.

What is it?

In addition to the Resource Manager deployment model that allows you to group and manage your related resources, Microsoft introduced RBAC, providing fine-grained control over the operations and scope with which a user can perform a control-plant action. The previous methodology (classic) only allows you to grant either full administrative privileges to everything in a subscription or no access at all.

With Resource Manager, you can grant permissions at a specified scope: subscription, resource group, or resource. This means you can deploy a set of resources into a resource group and then grant permissions to one or more specific users, groups, or service principal. Those users will only have the permissions granted to those resources in that resource group. This access does not allow them to modify resources in other resource groups. You can also give a user permission to manage a single VM, and that’s all that user will be able to access and administer.

In addition to users, Azure RBAC also supports service principals that formally are identities representing applications, but informally are used by RBAC to allow automated processes to manage Resource Manager resources. To grant access, you assign a role to the user, group, or service principal. There are many predefined roles, and you can also define your own custom roles.

Roles

Each role has a list of Actions and Not Actions. The Actions are allowed, and the Not Actions are excluded. See https://azure.microsoft.com/documentation/articles/role-based-access-built-in-roles/ for the full list of roles and their Actions and Not Actions.

For example, there is a role called Contributor. With this role, a user can manage everything except access. This role has the following Actions and Not Actions:

 Actions: *  Can create and manage resources of all types

 Not Action: Microsoft.Authorization/*/Write  Can’t create roles or assign roles

 Not Action: Microsoft.Authorization/*/Delete  Can’t delete roles or role assignments

 

Let’s take a look at some of the most common roles.

 Owner A user with this role can manage everything, including access. This role has no Not Actions. This is synonymous with Co-Administrator in the classic deployment model.

 Reader A user with this role can read resources of all types (except secrets) but can’t make changes. This role will allow someone to look at the properties of a storage account, but it won’t let that person retrieve the access keys.

 SQL DB Contributor A user with this role can manage SQL databases but not their security-related policies.

 SQL Security Manager A user with this role can manage the security-related policies of SQL Servers and databases.

 Storage Account Contributor A user with this role can manage storage accounts but cannot manage access to the storage accounts. This means the user with this role can’t assign any roles to any users for the storage account. Note that the user with this role can retrieve the access keys for the storage account, which means they have full access to the data in the storage account.

 Virtual Machine Contributor A user with this role can manage virtual machines but can’t manage the VNet to which they are connected or the storage account where the VHD file resides. Note that this role does include access to the storage account keys, which is needed to create the container for the VHD files as well as the VHD files themselves.

These are only a few of the many roles that can be assigned to a user, a group of users, or an application.

Custom roles

If none of the built-in roles and no combination of the built-in roles provides exactly what you need, you can create a custom role. You can do this using PowerShell, the Azure CLI, or the REST APIs. Once you create a custom role, you can assign it to a user, group, or application for a subscription, resource group, or resource. Custom roles are stored in the Azure AD and can be shared across all subscriptions that use the same Active Directory.

For example, you could create a custom role for monitoring and restarting virtual machines. Here are the Actions you would assign to that role:

 Microsoft.Storage/*/read

 Microsoft.Network/*/read

 Microsoft.Compute/*/read

 Microsoft.Compute/virtualMachines;/start/action

 Microsoft.Compute/virtualMachines/restart/action

 Microsoft.Authorization/*/read

 Microsoft.Resources/subscriptions/resourceGroups/read

 Microsoft.Insights/alertRules/*

 Microsoft.Insights/diagnosticSettings/*

 Microsoft.Support/*

Note that as requested, this role can only start and restart virtual machines. It can’t create them or delete them.

A convenient way to create a custom role is to download the definition of an existing role and use that as a starting point. When you create a custom role, you also need to specify in which subscriptions it can be used—at least one must be specified. In the next section, we’ll see how to assign roles to users for a resource group and how to give full administrative privileges for a subscription to a user.