Azure Resource Manager has a complete, but complex, set of role-based access controls that let admins create policies to manage who can access Azure cloud services.
Azure Resource Manager, the management portal for the public cloud platform, has a set of features for managing.
Azure roles, access controls and security policies. But because of the variety of Azure users, including service providers, central IT infrastructure managers, IT operations teams and application developers, Azure Resource Manager can be confusing especially when controlling service access and configurations.
Here's a closer look at the role-based access controls (RBACs) in Azure Resource Manager (ARM), including their relationship to underlying Azure provisioning concepts, security and identity management features and common use scenarios.
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.
- 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 provides isn't visible whenever using Azure public cloud because Microsoft defines these behind the scenes. The difference becomes important, however, when utilizing a third-party Azure service agency or, eventually, Azure Stack to create a private cloud. These may offer more granular service packages that focus on different groups, companies or workload requirements. The distinction can also be relevant for Azure role-based access control due to the relationship between subscriptions as well as the directory for managing user and group identities.
Admins define Azure RBACs from your free account directory, every subscription can trust merely one directory. A small team could use Azure and define users and groups in the Microsoft account system; all Azure roles and controls should be defined using Microsoft accounts. If the enterprise all together later adopts Azure, syncs the enterprise Active Directory (AD) to Azure and uses it to line policies, IT teams must recreate developer roles using AD identities. Because anyone or group might have more than one subscription, it is critical to ensure each subscription uses the identical user directory to keep a consistent group of policies.
Whether on Azure and other system, the guiding principle of RBACs belongs to least privilege: End users should just have the amount of access instructed to perform their jobs. Azure enforces least privilege by only allowing clients to perform actions on helpful which rights happen to be explicitly defined. There are no default permissions, unless a business applies an international group to a particular role for everyone resources.
On Azure, RBACs adhere to a hierarchical rule of precedence a lot like that found in AD with global, parent and child realms for users, groups and controls. Admins can assign Azure roles in an entire subscription, a resource group or even a single resource. Role access at the higher scope, for instance for a resource group, is applicable to all resources inside group, like 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 a full subscription or even for specific resources or resource groups. Admins define these custom Azure roles utilizing a JSON syntax. Whether custom or predefined, they could define role membership over 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 were not impressed with Azure's deficiency of role-based management, particularly for Azure Rights Management (RMS), a data loss prevention feature for Office 365, Exchange and SharePoint. Some mistakenly feel that Azure makes it necessary that an end user has to be a global admin to control RMS templates. However, Azure documentation states that, after activating RMS, admins can "use two default templates making it easy for these phones apply policies to sensitive files" to restrict having access to authorized users.
These two templates have rights policy restrictions that are included with read-only viewing for protected content and study or modify permissions for protected content. As mentioned, IT teams also can define custom roles and permissions for rights management and template creation.
It's feasible that Azure doesn't provide you with the granularity of access control companies want for each service. Nevertheless, that has a better perception 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 diverse range of users and job requirements.
