Tips and tools to manage Azure roles, access controls

The basics of RBACs in Azure

Before diving into RBACs, it's important to understand the basic constructs of Azure service provisioning and usage, particularly the distinction between plans, offers, subscriptions, quotas, services and roles.

• Admins can assign Azure roles to an entire subscription, a resource group or a single resource.

  Service: The fundamental unit of consumption in Azure. Services include resources such as virtual machines (VMs), object stores or relational databases.
• Plan: A collection of services offered to users, such as a set of VM instances, storage and database types, plus any usage restrictions, like region availability or resource quotas. Plans are often tailored for specific IT roles, such as a developer or data scientist, or workload requirements.
• Offer: A collection of one or more plans available for subscription. Offers are the actual set of products from which users choose to subscribe.
• Subscription: An agreement between a company and a cloud provider, granting the right to consume one or more services as defined in the subscribed plan. Organizations may have one or more subscriptions.
• Quota: Service limits as defined as part of a plan. For example, Azure's free tier, which is essentially a plan, is limited to 14 VMs, 40 SQL databases and 8 TBs of storage for a month.
• Role: A set of access, management and use rights assigned to an individual or group.

The distinction between plans and offers isn't visible when using Azure public cloud because Microsoft defines these behind the scenes. The difference becomes important, however, when using a third-party Azure service provider or, eventually, Azure Stack to build a private cloud. These will likely offer more granular service packages that target different groups, companies or workload requirements. The distinction is also relevant for Azure role-based access control because of the relationship between subscriptions and the directory for managing user and group identities.

Admins define Azure RBACs from an account directory, and each subscription can trust only one directory. A small development team could use Azure and define users and groups within the Microsoft account system; all Azure roles and controls must be defined using Microsoft accounts. If the enterprise as a whole later adopts Azure, syncs the enterprise Active Directory (AD) to Azure and uses it to set policies, IT teams must recreate developer roles using AD identities. Because an individual or group may have more than one subscription, it's important to ensure each subscription uses the same user directory to maintain a consistent set of policies.

Whether on Azure or any other system, the guiding principle of all RBACs is that of least privilege: End users should only have the amount of access required to perform their jobs. Azure enforces least privilege by only allowing end users to perform actions on resources for which rights have been explicitly defined. There are no default permissions, unless an organization applies a global group to a particular role for all resources.

On Azure, RBACs follow a hierarchical rule of precedence similar to that used in AD -- with global, parent and child realms for users, groups and controls. Admins can assign Azure roles to an entire subscription, a resource group or a single resource. Role access at a higher scope, such as for a resource group, applies to all resources within the group, such as VMs, websites and databases.

A look at standard Azure roles

Microsoft defines three fundamental Azure roles:

• Owner: has full management rights
• Contributor: has full management rights, except for user management
• Reader: can view resource rights

Microsoft also has an evolving list of more specific, built-in Azure roles. For example, the Automation Operator role allows members to start, stop, suspend and resume jobs. A DevTest Labs User can view everything and connect, start, restart and shutdown VMs.

Azure also supports custom roles that admins can assign to users, groups or applications across an entire subscription or for specific resources or resource groups. Admins define these custom Azure roles using a JSON syntax. Whether custom or predefined, they can define role membership through the ARM web portal. However, admins can automate large-scale assignments using PowerShell, the Azure command-line interface (CLI) or REST API.

Microsoft supplies PowerShell cmdlets for the following actions:

• Get-AzureRoleAssignment: retrieves the roles assigned to a user.
• Get-AzureRoleDefinition: lists the Actions and NotActions for a role.
• New-AzureRoleAssignment: assigns a role assignment to a user or group.
• Remove-AzureRoleAssignment: removes a role assignment from a user or group.

Role-based management for Azure RMS

Some IT teams have complained about Azure's lack of role-based management, particularly for Azure Rights Management (RMS), a data loss prevention feature for Office 365, Exchange and SharePoint. Some mistakenly believe that Azure requires that an end user must be a global admin to manage RMS templates. However, Azure documentation states that, after activating RMS, admins can "use two default templates that make it easy for them to apply policies to sensitive files" to restrict access to authorized users.

These two templates have rights policy restrictions that include read-only viewing for protected content and read or modify permissions for protected content. As mentioned, IT teams can also define custom roles and permissions for rights management and template creation.

It's possible that Azure doesn't provide the granularity of access control companies want for every service. Nevertheless, with a better understanding of RBAC implementation, use and customization -- both within ARM and through automated PowerShell or CLI scripts -- admins can fine-tune their Azure security policy for a broad range of users and job requirements.