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?
1 Reply
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