Forum Discussion
Azure RBAC Custom Role Best Practices or Common Build Patterns
As a platform admin, I want to grant application admins Contributor access while removing their ability to write or delete most Microsoft.Network resource types, with a few exceptions such as Private Endpoints, Network Interfaces, and Application Gateways.
Based on the effective control plane permissions logic, we designed two custom roles. The first role is a duplicate of the Contributor role, but with Microsoft.Network//Write and Microsoft.Network//Delete added to notActions. The second role adds back specific Microsoft.Network operations using wildcarded resource types, such as Microsoft.Network/networkInterfaces/*.
Application Admin Effective Permissions = Role 1 (Contributor - Microsoft.Network) + Role 2 (for example, Microsoft.Network/networkInterfaces/, Microsoft.Network/networkSecurityGroups/, Microsoft.Network/applicationGateways/write, etc.)
I understand that Microsoft RBAC best practices recommend avoiding wildcard (*) operations. However, my team has found that building roles with individual operations is extremely tedious and time-consuming, especially when trying to understand the impact of each operation.
Does anyone have suggestions for a simpler or more maintainable pattern for implementing this type of custom RBAC design?
2 Replies
managing this type of custom permission is always a challenge at specially in future when MS is going to add new features or more granular controls. it better to do the segmentation at RG level. Make one RG like APP RG and give Contributor Role ( no clone, built-in) there. Make another RG for keeping your crictical network resources like VNets, Route Tables, Firewalls, DNS Zones, ExpressRoute and assign no role to this RG. Then Create a third RG and keep your app related networking resoruces like Private Endpoints, Network Interfaces, and Application Gateways and here you can use your Custom role with ONLY allowed network writes like Microsoft.Network/networkInterfaces/, Microsoft.Network/networkSecurityGroups/, Microsoft.Network/applicationGateways/write, etc.
Would suggest keep two‑role model (Contributor minus Microsoft.Network + Add‑Back for specific resources). It can avoid wildcards while remaining maintainable. To reduce effort, script role creation with Azure CLI or PowerShell and maintain a JSON template library for reuse across environments.
https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles
https://learn.microsoft.com/en-us/azure/role-based-access-control/best-practices
