Configure Custom RBAC Roles in Azure
Security-oriented companies should focus on giving employees the exact permissions they need. Too many permissions exposes an account to attackers. Too few permissions means that employees can't get their work done efficiently. Azure Role-Based Access Control (RBAC) helps address this problem by offering fine-grained access management for Azure.
This Article explains the detailed steps to implement and configure custom RBAC Role definitions to allow or deny actions based on specific requirements.
Using RBAC, you can segregate duties within your team and grant only the amount of access to users that they need to perform their jobs. Instead of giving everybody unrestricted permissions in your Azure subscription or resources, you can allow only certain actions. For example, use RBAC to let one employee manage Virtual Machines in a subscription, while another can manage Virtual Networks within the same subscription.
For the purpose of demo, we would be implementing the following roles:
- Deny access to Classic VNET Creation and Deletion
- Deny access to VNET Gateway Create, Upgrade and Delete
- Deny access to Add, Modify and Delete Subnets in a VNET
- Deny access to Create, Modify and Delete Point-to-Site and Site-to-Site VPNs
- Allow access to all other Azure Services
The following procedure mentions the steps taken to ensure that a certain user is denied the access to the above mentioned roles and services. At the same time, the user would be able to access the other Azure Services and support them
Prerequisites:
The user, if already added, should be removed as a co-administrator from the Azure Portal.
Procedure:
- Create a new JSON based Definition for a custom RBAC Role
- According to the requirements, specify the roles which needs to be given access
- Also specify the roles which needs to be denied
- In the above snap, the rules are created under the "Deny" Category. All the other actions are allowed by Default. Save this JSON File and name it "VNETDeny"
- With the help of Azure PowerShell, create a new Azure Role Definition and import this JSON File
- Go to the Portal and observe if the new Role Definition has been imported
- Now the desired user "xxxxxx@outlook.com" needs to be added to the custom RBAC role “VNETDeny”
- After the user logs on to the Azure Portal, the user won’t be able to perform the functions that have been denied
Test Cases:
- Test Case 1 : If the user tries to create a new VNET, it would be denied
- Test Case 2 : If the user tries to delete or add a Subnet to an existing VNET, it would be denied
- **Test Case 3 : **If the user tries to delete a Gateway, it would be denied
- **Test Case 4 : **If the user tries to connect or disconnect a Gateway, it would be denied
- **Test Case 5 **: Creation & Deletion of a new VM, Cloud Service, Storage Account is allowed
Drawbacks:
There are various drawbacks while implementing RBAC or any custom RBAC role:
- Not able to access Classic Management Azure Portal
After implementing RBAC, the user would be removed as a co-admin which would protect the user from accessing the Management Portal
- Not able to access Backup Vault Services
Classic Backup Vaults can only be managed through the Classic Management Portal. Any Azure services which are managed
- Not able to access Azure PowerShell
While the users are not a part of the co-administrator list, they won't be able to access the Classic Azure services through Azure PowerShell (Not even Login)