Introduction to Azure Resource Manager
Template Deployment & Advanced Concepts
The course is part of these learning pathsSee 3 more
During this lecture, we'll explore the two core access control features in Azure Resource Manager (ARM). Using Policy and Role-Based Access Control (RBAC), we can control what operations can be performed against cloud resources, and who is authorized to perform those actions. Policy and RBAC are not exclusive access control features, and are designed to be used in conjunction with each other. ARM Policy enables specific actions to be allowed or denied, based on properties from the request, such as tags, the specified Azure region (location), and others. On the other hand, ARM RBAC enables you to explicitly authorize an Azure Active Directory (AAD) user or group to have access to an Azure Subscription, Resource Group, or individual Resource.
Hello, and welcome to Microsoft Azure Resource Manager, Access Control.
In this lecture, we're going to talk about Role-based Access Control in Resource Manager as well as Resource Manager Policy. Let's start by talking about Role-Based Access Control.
In the Azure Resource Manager API, you can define your own custom roles, and then assign that role to a user or security group in Azure active directory. The role can have a name to refer to it by, a description field to help other administrators understand the purpose of that role, and also an assignable scopes that allows you to restrict which scopes such as subscriptions, resource groups, and individual resources that role can be assigned to. A role is made up of actions and NotActions. Actions are operations that can be performed against a given resource and NotActions is an exclusion rule that allows you to exclude specific actions from the role. It's important to understand that the NotActions property is not an explicit deny like in NTFS. This is the PowerShell code that we can use to create a custom role.
First, we start off by creating a PS role definition object. We assign the properties such as the name, description, actions, NotActions and assignable scopes, and then finally we call the New-AzureRmRoleDefinition command and pass in the role object that we created into the role parameter. Next, we need to create an assignment for that role. To do that, we use the technique called PowerShell Splatting, which allows us to define the input parameters for a command in PowerShell using a hash table. This is a very simple concept, but one that you want to get familiar with as you use the Azure PowerShell module more and more. So the New-AzureRmRoleAssignment command is used to assign a role to a user or group. As you can see, we're passing in several parameters. First, we specify the sign in name that we want to assign the role to. Next, we assign the resource group that we want to associate the user with. And then finally we have the RoleDefinitionName, which is the role that we created in the first step. Next, let's talk about Azure Resource Manager Policy.
When a user attempts to perform an operation against a resource in the Resource Manager API, it can either be allowed or disallowed based on a policy. We can create policies to restrict different types of properties such as a location, a type of resource, the tags that a resource has or the action that the user attempted on a resource. And to do this, we can use PowerShell. The New-AzureRmPolicyDefinition command allows us to create a new policy. In this example, we're creating a rule that denies the user access to the Microsoft storage operations. So as you can see, we're giving the policy a friendly name, a friendly display name, a description and then finally the policy object, which is declared using a JSON syntax. We call the New-AzureRmPolicyDefinition command to instantiate the new policy inside of our Azure subscription.
To assign that policy, we use the New-AzureRmPolicyAssignment command and we specify the name of the policy rule, the scope that that policy will be applied to and finally the policy definition itself. So in this case, when a user tries to perform a storage operation such as creating a storage account, or deleting a storage account, that user will be denied access to that particular policy. It's important to understand that Role-Based Access Control and Resource Manager Policy can be used together and are not mutually exclusive concepts.
About the Author
Trevor Sullivan is a Microsoft MVP for Windows PowerShell, and enjoys working with cloud and automation technologies. As a strong, vocal veteran of the Microsoft-centric IT field since 2004, Trevor has developed open source projects, provided significant amounts of product feedback, authored a large variety of training resources, and presented at IT functions including worldwide user groups and conferences.