How to manage Azure RBAC in Code
What is Azure role-based access (RBAC)?
Azure role-based access control (RBAC) helps you manage who has access to Azure resources.
For example you can use RBAC to:
- Allow the network team to manage virtual networks
- Allow the database administrator group access to manage SQL databases
- Allow a project team access to all resources in the project's resource group
A role assignment consists of three elements: security principal, role definition, and scope.
For example, to allow the network team to manage virtual networks in the "Network-01" resource group:
| Element | Example |
|---|---|
| Security principal | "Network Team" AAD Group containing members of the Network team |
| Role definition | "Contributor" builtin role |
| Scope | "Network-01" resource group containing vNets and subnets |
How is it applied in Azure?
1. Assign Azure RBAC in the Portal
A role assignment can be added manually in the Azure Portal.
2. Deploy Azure RBAC via Code
Role assignments can be defined in code and deployed via an Azure DevOps pipeline.
Below is a snippet from an ARM template. It is verbose, and the use of ids makes it less user friendly. Read on for a better way.
{
"type": "Microsoft.Authorization/roleAssignments",
"apiVersion": "2020-04-01-preview",
"name": "09df4e6b-faf1-448d-91ec-c6124c78a2c2",
"scope": "/subscriptions/2e891e5a9-8953-491d-997a-23f4cc38fe28/resourceGroups/NETWORK-01",
"properties": {
"roleDefinitionId": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"principalId": "33e18778-4916-4977-86b8-199734b7d8f3"
}
}
Manage Azure RBAC centrally in code
In any enterprise the number of RBAC settings can easily be in the thousands.
Manual configuration of so many settings in the Azure Portal is clearly not sustainable.
Having individual teams deploy RBAC as code along with their resources is also less than optimal as access configured by multiple people with varying degrees of awareness of security will lead to a proliferation of standards, pipelines and repositories.
The ideal method for central management of RBAC could be as simple as one repository and one pipeline.
- All the configuration in one git repository is great for visibility and auditability
- Approval methods available in Azure DevOps can be used to control who can configure And deploy RBAC changes
- New projects/teams wouldn't have to develop their own pipelines.
Even with one repository and pipeline, there are several possible implementations that enable centralised or distributed configuration:
- have all RBAC for the enterprise created, approved and deployed by one central security/architectural team
- have all teams able to create RBAC and submit changes via PR, with approval and deployment done by one central security/architectural team
While one repository and one pipeline is an idealised version of central management or RBAC, depending on the structure of the organisation, this could also be done as one per Management Group or Subscription.
Why isn't everyone already doing this?
Firstly, automation takes time and effort to implement.
It is normally the case that Azure RBAC configuration starts of being done manually in the portal and it is only later that this starts being done in code.
And unfortunately, it is often more difficult to start deploying from code after settings have already been applied via other means.
Secondly, the "You build it, you run it" idea can mean that many teams are expected to handle Azure RBAC themselves along with everything else.
They can implement their own solution for their smaller number of RBAC configurations and move on without consideration to the bigger picture.
Thirdly, it's scary.
You don't want to redeploy one thousand RBAC settings every time you need to deploy one new one, especially for something as important as Azure RBAC.
What is the solution
The Azure DevOps extension called "Osservante RBAC" is available in the Azure Marketplace.
It deploys resource groups, their tags, and role-based access assignments from code using a human readable folder structure and file format with display names in place of Ids.
It Includes a plan mode which compares code with the state in Azure at runtime so changes can be reviewed and approved before being applied.
And best of all, it has an export mode so you can not only get started any time, but also synchronise any on-going changes made in the portal back to code quickly and easily.
for more information: