Role-Based Access Control and Azure Policies

As your Azure usage increases and you expand the number of users, Azure supplies a number of tools to ensure that users are able to complete their tasks with the minimum permissions required. This enables you to give the users autonomy without allowing them free reign in the subscription to do whatever they want.

Exam Tip - Microsoft expects you to fully understand this for many of the Azure certification exams including AZ-103, AZ-300, and AZ-301. Skills expected are as follows:

Manage role-based access control (RBAC)

• create a custom role

• configure access to Azure resources by assigning roles

• configure management access to Azure

• troubleshoot RBAC

• implement RBAC policies

• assign RBAC roles

Role-based Access Control 

The first area to investigate is Role-based Access Control (RBAC). By default, within RBAC, a user is denied access to all resources and access need to be granted explicitly. Access can be granted to specific users or groups at various levels within an Azure Subscription. RBAC permissions can be applied at component, resource group, or full subscription-level.

 There are several component-specific roles but there are three main roles that concern us initially:

 ·      Owner

·       Contributor

·       Reader

Owner:

Giving a user or group owner rights means they have full-access to all resources and configuration information within the subscription, resource group or component. They also have permissions to delegate access to other users as well.

Contributor:

A contributor has all the permissions an owner has in respect to managing Azure resources. However, they do not have the permissions to grant access to other users.

Reader:

The reader role allows a user read-only access to the Azure resources. Allowing users to see configuration and log information of the components but restricting the user from changing any settings.

There are many other built-in roles designed for specific tasks and roles, for example:

SQL DB Contributor is created to allow a user to manage the SQL Server but does not give the user access to the data contained with the databases.

All available built-in roles are listed within the Microsoft documentation here:

https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles

Whilst RBAC’s role is to grant the rights to your users to implement and manage the top-level Azure resources, they do not restrict users within the resource types. For example, RBAC controls whether a user can create VMs, but it doesn't stop them creating over-spec'd machines. This is where Azure Policies are used.

Azure Policies

Policies are sets of rules that specify what can and cannot be created in either a single resource group or a full subscription. These can be used to ensure users are able to create and work with approved resources without creating over-provisioned machines racking up major costs on your Azure bill.

Unlike RBAC, policies by default allow you to do anything within the subscription or resource group. You need to explicitly deny actions within the policy.

There are a multitude of built-in policies within Azure which can be configured and applied to the appropriate resource group or subscription. These built-in policies include but are not limited to:

·       Allowed storage account SKUs

·       Allowed virtual machine SKUs

·       Allowed locations

·       Enforce automatic OS image patching on virtual machine scale sets

·       Enforce tag and its value

·       Require specified tag

·       Require SQL Server version 12.0

For an example, we will apply an Allow Location policy to the subscription. In the portal, browse to the policy blade within the subscription details (similar blades appear at the resource group)

This will open the Compliance blade within the policy settings. Now click “Assign policy” and select the appropriate policy definition, searching for “Location” will filter the list down to find the “Allowed locations” policy:

Once selected, we can add in the allowed location from the drop down box in the parameters:

We can now add a helpful description and name that conforms to your naming conventions:

Although these steps are done through the UI, there are PowerShell commands that will achieve the same outcome:

PS C:\> $Subscription = Get-AzureRmSubscription -SubscriptionName "Subscription-Name" PS C:\> $Policy = Get-AzureRmPolicyDefinition | Where-Object {$_.Properties.DisplayName -eq 'Allowed locations'} PS C:\> $Locations = Get-AzureRmLocation | where displayname -like '* US*’ PS C:\> $AllowedLocations = @{'listOfAllowedLocations'=($Locations.location)} PS C:\> $Scope = "/subscriptions/" + $Subscription.Id PS C:\> New-AzureRmPolicyAssignment -Name 'RestrictLocationPolicyAssignment' -PolicyDefinition $Policy -Scope $Scope -PolicyParameterObject $AllowedLocations

Now if a user attempts to create any resource outside of the US regions, they will receive the following error message during the validation:

{"code":"InvalidTemplateDeployment","message":"The template deployment failed with multiple errors. Please see details for more information.","details":[{"code":"RequestDisallowedByPolicy","target":"example210","message":"Resource 'example210' was disallowed by policy. (Code: RequestDisallowedByPolicy)","additionalInfo":[{"type":"PolicyViolation","info":{"policyDefinitionDisplayName":"Allowed locations","evaluationDetails":{"evaluatedExpressions":[{"result":"True","expression":"location","path":"location","expressionValue":"northeurope","targetValue":["centralus","eastus","eastus2","westus","northcentralus","southcentralus","westcentralus","westus2"],"operator":"NotIn"},{"result":"True","expression":"location","path":"location","expressionValue":"northeurope","targetValue":"global","operator":"NotEquals"},{"result":"True","expression":"type","path":"type","expressionValue":"Microsoft.Network/networkInterfaces","targetValue":"Microsoft.AzureActiveDirectory/b2cDirectories","operator":"NotEquals"}]},"policyDefinitionId":"/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c","policyDefinitionName":"e56962a6-4747-49cd-b67b-bf8b01975c4c","policyDefinitionEffect":"deny","policyAssignmentId":"/subscriptions/e58f54c7-5174-4214-b458-25c5b378fc96/providers/Microsoft.Authorization/policyAssignments/RestrictLocationPolicyAssignment","policyAssignmentName":"RestrictLocationPolicyAssignment","policyAssignmentScope":"/subscriptions/e58f54c7-5174-4214-b458-25c5b378fc96","policyAssignmentSku":{"name":"A0","tier":"Free"},"policyAssignmentParameters":{"listOfAllowedLocations":{"value":["centralus","eastus","eastus2","westus","northcentralus","southcentralus","westcentralus","westus2"]}}}}],"policyDetails":[{"isInitiative":false,"assignmentId":"/subscriptions/e58f54c7-5174-4214-b458-25c5b378fc96/providers/Microsoft.Authorization/policyAssignments/RestrictLocationPolicyAssignment","assignmentName":"RestrictLocationPolicyAssignment","viewDetailsUri":"https://portal.azure.com#blade/Microsoft_Azure_Policy/EditAssignmentBlade/id/%2Fsubscriptions%2Fe58f54c7-5174-4214-b458-25c5b378fc96%2Fproviders%2FMicrosoft.Authorization%2FpolicyAssignments%2FRestrictLocationPolicyAssignment"}]}]}

To summarize, RBAC is used to set the high-level permissions for users and groups to access specific resource types. Policies add the additional layer of protection and auditing by ensuring only approved locations and SKUs are used.  When used in conjunction, RBAC and Azure Policy can provide governance around your environment ensuring users have adequate rights but adhere to the organization’s cloud policies

Matt Boyd