I'm working in AWS security but now I'm stepping into the Azure world due to a vacancy at my company. I'm curious about how development teams in your organizations are creating custom roles in Azure. Specifically, I'm looking for best practices or sane approaches to do this. For instance, if I need my application to read data from storage account 1, send messages to a service bus queue, and trigger a specific function, how should I go about developing tailored IAM roles? In AWS, IAM roles are local to the subscription, allowing flexible development and testing, but Azure's global IAM tied to Entra seems to complicate things. I want to avoid using overprovisioned managed roles and would appreciate any tips or experiences on how teams manage this process effectively.
1 Answer
In Azure, RBAC roles can be scoped at various levels: individual resources, resource groups, subscriptions, or management groups, with permissions inheriting from higher levels. Custom roles are generally a last resort since built-in RBAC is preferred. To follow the least privilege principle, consider granting access at the specific resource level using system-managed or user-assigned identities. Each application can either use multiple identities for service-to-service access or a single user-assigned identity. However, keep in mind that Azure limits the number of RBAC assignments per subscription, so this might not be as straightforward as in AWS, especially regarding resource groups' significance which differs between the platforms. Teams transitioning from AWS might find it tricky to adapt to this structure.
Don't you think that might lead teams to give contributor or admin permissions at the resource group level? How can we ensure access is scoped down to individual resources instead?