Azure Security Fundamentals: Moving Co-Admins to RBAC

Anyone who has worked with Azure for long enough knows the raised eyebrow response you have gotten from security teams in the past when you describe how you can enforce separation of duties and least privilege when it comes to Azure subscription and service management. In a previously well-received blog post, one of my colleagues provided good guidance around subscription management as it applied to Azure at that time.

Essentially, the situation was:

• Any Azure service management required full administrator or co-administrator access to a subscription which provided the user with full permission to do anything provisioned there-in.
• This meant that a subscription typically became a security container. For example you could provision a subscription for an application or you could provide a subscription for an environment (such as Dev / Test / Prod).

Patently this situation is undesirable to say the least, and Microsoft has spent much of the last two years gradually bringing pieces together to rectify this. The components that have enabled these changes are:

• Role Based Access Control (RBAC) including custom-defined roles
• Resource Groups and the
• Azure Preview Portal.

In the remainder of this post I’m going to look at how you can move from the old world (many co-administrators with full control) to the new world (few administrators with fine-grained control). In a later post I will look at how we can use custom Roles and Resource Groups as a container for access control too.

Before I go ahead there are few items to note:

• Not every Azure service offering supports using RBAC or the Preview Portal. Ironically (at time of writing) this included Azure Active Directory. The other big one you may be using is Service Bus. If you have users who manage either of these then they must remain as co-administrators (or switch to PowerShell in the case of Azure AD).
• A resource (Web App, SQL Database) can only exist in a single Resource Group. This means you should plan how you want elements of your environment to be managed – by role (DB server, web server, etc); by application; or some other approach – and design an appropriate Resource Group (and therefore security group) hierarchy.

Audit your co-administrators

As you can assign up to 200 co-administrators the first step is to audit all the existing ones you have. Out of this audit you should determine what Azure services each user needs to manage or if they actually still require access. Taking the output you should hopefully be able to map many of the users to an appropriate built-in RBAC role.

Recommendation: leverage security groups in Active Directory or Azure AD as the way to assign users to RBAC roles. This will simplify management going forward. Avoid doing individual user assignments using the RBAC tooling at all costs.

Add security groups to appropriate RBAC roles

Utilising the PowerShell tooling (0.9.8.1 is the release I’m using) you can assign users and security groups to Azure RBAC roles as follows. In my example below I have existing Azure AD security group called ‘Database Security Team’ which contains all users that will be able to maintain Azure SQL Database Security configurations (and nothing else).

The ObjectId represents ‘Database Security Team’ which can be obtained from ‘Group’ page in Azure AD in the Portal, RoleDefinitionName comes from the standard RBAC roles available in Azure, and finally the Scope is the entire current Subscription.

[code language=”powershell” gutter=”false”]

# In v1.0 this is New-AzureRmRoleAssignment
New-AzureRoleAssignment -RoleDefinitionName ‘SQL Security Manager’ `
-ObjectId 13a9c31c-8457-xx1x-8cea-xx1250594e90 `
-Scope /subscriptions/c25b1c8e-711f-0000-9c8b-1cccc7012113

[/code]

Remove user as a co-administrator

As these users only need to maintain Azure SQL Database security configuration we can now remove them as co-administrators in the classic portal. This will mean they no longer have access to the classic portal at all and will receive a “no subscription found” page if they try to access it (see below).

If these users have previously bookmarked http://manage.windowsazure.com/ you should get them to delete it and create a new one to http://portal.azure.com/ instead.

Ideally you should try and reduce the number of co-administrators to the smallest group possible. Administrators can perhaps be split into those who manage Preview Portal services (and can be put into the RBAC ‘Owner‘ Role) and those who manage services in the classic portal and still require co-administrator rights.

But wait…

A user can still see a bunch of stuff they can’t use or access in the Azure Preview Portal!

Yes, they can.

The Preview Portal does not try to hide elements that a user isn’t authorised to use. A user added to the security group in our example can still attempt to create a Virtual Machine, but it will fail – see below.

The authorisation process occurs at the API layer at submission, and while not ideal, attempting to filter the Azure Preview Portal interface would be a substantial performance hit given the possible number of permutations and number of API calls that are made.

Recommendation: each user is able to customise their Dashboard (home page) to show what they want. Depending on the roles a user has been granted they may wish to pin different blades to their home page. In our example the user would likely pin Azure SQL Databases and / or Azure SQL Database Servers.

So there we have it – how you can start to reduce the number of co-administrators you have in your Azure environments. Hopefully this introduction has helped give you some clarity around how you can start to use RBAC in your Azure subscriptions. Happy days!