Managing Custom Roles in Azure

While using Azure role-based access controls, Microsoft provides a set of built-in roles to meet the needs of providing least privileges. These roles work sometimes and you can add users/groups to multiple roles, but often times they do not define what you are using for roles of your architects, engineers, administrators, developers, and others. If these built-in roles provide too much access for individuals in certain roles, you can create custom roles that you can manage.

Custom roles provide the flexibility to be very granular in the privileges you assign to certain individuals and groups. With custom roles, you can control what services and/or features people can access; users can only access what you put as actions in the roles and are not automatically updated for new services like they are with built-in roles. As new services and features are released, you will need to update customer roles to allow users to take advantage of those new services and features but this gives a chance for those new services to be vetted before used. Custom roles can be difficult to manage and keep updated as new services are released frequently. In addition, the number of managed subscriptions can increase over time. You can use Azure Automation to help simplify some of the management complexities associated with manually updating and resetting custom roles. The below steps talk through the setup of the process to managing custom roles easily.

There are pros and cons to using custom roles, here are a few of them:

• Store all of the role definitions in source control to ensure change control.

• Limit access to the storage container where the roles are stored to only the deployment process. This prevents unapproved changes.

• Secure access to the runbook. The runbook needs access to download the role definitions.

• Investigate having Azure Key Vault manage the storage account keys and also provide the SAS tokens for access. This gives an audit trail of who is accessing the SAS tokens and when.

• This solution will work on a single Azure AD tenant. Create additional automation accounts if you need it to work across multiple tenants. Alternatively, you can create other service principles that can access those subscriptions in the other tenant.

• This process may become a little easier as Microsoft releases Management Groups but most of this will still hold true.

Initial framework setup

• Create a new automation account to manage this process. It is important that access to this automation account is limited to only a select number of privileged users as runbooks executed within this automation account will have access to modify privileges on subscriptions.

• Create a new custom role that only provides the "Microsoft.Authorization/roleDefinitions/write" action. This new role, which should only be used for the new RunAs connection, is created by the new automation account. If you have multiple subscriptions, this new role needs to be scoped to all of the subscriptions for which you want to manage roles.

• After the role definition is created, you will need to use the New-AzureRmRoleDefinition PowerShell command to create the new role. Once that is done, take the Id provided in the console output and insert that as the “Id:” property in the json definition for the role.

• In the Azure portal, add the RunAs connection to the new role that you just created for each subscription for which it should have access.

• Create a storage account that will be used to hold the production certified roles. Each time the script runs, it will download each role and update the role with the current json definition. It is important that you limit access to this automation account to only a select number of privileged users.

• Create a runbook in the automation account which should do the following things.

• • Read the list of role definitions in the storage container.
  • For each role definition, download the definition and then update role with the current definition.

The above setups will help you setup the initial framework. To add new roles or update existing roles, follow the below steps.

For a new role

• After building the custom role definition, you will need to manually create the role using New-AzureRmRoleDefinition the first time so that Azure will give that role a new unique Id.

• Once that is done, take the Id provided in the console output and insert that as the “Id:” property in the json definition for the role.

• Upload that role definition to the storage container where the roles are stored.

• Either execute the runbook or have it run on its next scheduled time.

To update an existing role

• Take the existing role definition and make the necessary changes.

• Upload that role definition to the storage container where the roles are stored.

• Either execute the runbook or have it run on its next scheduled time.