Azure RBAC Role Assignment FAQ

03 Feb 2024 🔖 security tutorial
💬 EN

Below are a few frequently asked questions about Azure RBAC Role Assignments.

Many thanks to colleagues who helped me a lot with editing the wording when I wrote a similar document for internal training.

What is an Azure RBAC Role Assignment?

An Azure RBAC Role Assignment, not to be confused with an Entra RBAC Role Assignment, grants a given identity (that is, one that exists within Microsoft Entra ID) permission to perform specific types of actions against a specific “scope” of Azure resource(s).

The 3 components of an Azure RBAC Role Assignment

An Azure RBAC Role Assignment is a named Azure resource whose purpose is to describe a junction of three other Azure or Entra resource IDs:

1. An Azure RBAC “role” (whether “built-in” and maintained by Microsoft or “custom” and maintained by your company) that authorizes actions such as “write files to Azure Blob Storage.”
2. A target Azure resource ID (or resource group ID or subscription ID) “scope” upon which the role’s actions are allowed.
   • (Often simply set to “/” to represent the entire Entra tenant.)
3. An Entra identity serving as the “principal” capable of performing such actions upon the target-scoped resource(s).
   • Usually, the “principal” with Azure RBAC would represent a non-human.
   • That said, needing to frequently drop files into a Storage Blob would be a good reason to specify a group of humans.
     (Or, if a meaningful group cannot be determined, an individual human.)
     • Protecting the human’s Azure RBAC Role Assignment with Entra Privileged Identity Management (“PIM”) is an excellent practice in this case.
   • Furthermore, adding an additional layer of protection to Azure resources with resource locks may offer useful protection above and beyond the protection offered by carefully creating Azure RBAC Role Assignments.
     • Consult with colleagues before requesting resource locks, because locking resources may impede productivity in unexpected ways.
     • Also note that if you are having trouble performing actions you expected to be able to perform, given your existing Azure RBAC Role Assignments, check if existing resource locks might be the obstacle.

Create an Azure RBAC Role Assignment

See “Assign Azure roles” on Microsoft Learn.

In a corporate environment, you might not be allowed to do it yourself. Hopefully, your help desk ticketing system has a ticket type that you can open to request that an Azure RBAC Role Assignment be created/edited/deleted on your behalf.

Best practices

Follow the principle of least privilege when requesting the creation of Azure RBAC Role Assignments when choosing all 3 components (role, target scope, and principal).

When in doubt, create more role assignments, not broader Role Assignments.

Examples

Roles

Carefully look through Microsoft’s “built-in” Azure RBAC roles to find the least-powerful role that can perform a necessary task. For example:

• “Website Contributor” instead of the more powerful “Contributor” for deployment automations that need to deploy code onto Azure App Service, Azure Static Web Apps, Azure Functions, etc.
• “Data Factory Contributor” instead of the more powerful “Contributor” for deployment automations that need to deploy Azure Data Factory configuration from a “lower” nonproduction environment into a “higher” nonproduction or production environment.
• “Storage Blob Data Reader” instead of the more powerful “Reader” for Azure resources, deployment automations, or humans that need to read files out of Azure Blob Storage resources.
• “Storage Blob Data Contributor” instead of the more powerful “Contributor” for Azure resources, deployment automations, or humans that need to perform “write” operations against Azure Blob Storage resources.

Target scopes

Once an appropriately capable Azure RBAC role has been selected, it can be assigned to work against the following scopes in Azure:

1. Least privilege: Capabilities apply against a single specific Azure resource ID.
   • Preferred when resources are stable.
2. More privilege: Capabilities apply against all Azure resources residing in a specific Azure resource group ID.
   • As long as capabilities are tightly scoped – e.g. “Website Contributor” – this might provide a good balance between safety and convenience if a resource group encapsulates a single workload where appropriate target Azure resources – such as Azure Functions – are constantly being added and/or removed, and waiting for RBAC role assignment against each new function would critically impede productivity.
   • With a slow rate of change, however, individual resource-by-resource assignment may still be preferred for the comfort of knowing explicitly which Azure resources are targets of which Entra identities’ capabilities, rather than guessing based on each RBAC role’s documentation.
   • Questions about infosec tradeoffs between the context of “least privilege” and “ease of maintenance” / “governance?” Colleagues helping you design your solution, and staff on your company’s infosec team, are excellent resources for striking the correct balance amongst various infosec concerns.
3. Most privilege: Capabilities apply against all Azure resources residing in all resource groups in a specific Azure subscription ID.
   • By default, avoid this. “Subscription” is likely far too broad for common corporate approaches to grouping Azure resources.

Source principal identities

Once an appropriately capable RBAC role and narrow target scope has been chosen, the assignment must be attached to a specific Entra identity. Examples include:

1. A single Azure resource’s System-Assigned Managed Identity (“SMI”)
2. An Entra App Registration’s corresponding Service Principal
   • (Only when SMI is not available, and preferably using Federated Identity Credentials to log into it over OIDC if being used with Azure DevOps Pipelines or GitHub Actions code deployment automations.)
3. A group of humans (recommended by Microsoft), or, if necessary, an individual human.
   • (Either way, preferably only allowed while privileges are elevated through PIM.)

Combining several Azure RBAC Role Assignments to fulfill a task

To adhere to the security principle of least privilege, more than one Azure RBAC Role Assignment may need to be created to fulfill the permissions requirements of a given workload.

For example, a workload’s design may require the creation of:

1. A “Website Contributor” Azure RBAC Role Assignment allowing the Entra App Registration representing a code deployment automation to deploy code onto a nonproduction Azure App Service resource.
2. A “Storage Blob Data Contributor” Azure RBAC Role Assignment allowing the SMI of a nonproduction Azure App Service resource to read and write against a nonproduction Storage Blob’s files.
3. A “Storage Blob Data Contributor” Azure RBAC Role Assignment allowing the Entra group ID representing humans in a certain department to manually read and write a nonproduction Storage Blob’s files.
4. 3 more Azure RBAC Role Assignments as listed above but scoped for production target resources.
5. Etc.