If you’re like me when granting permissions, you want to do it according to least privilege. This is not always possible, but in Azure you have complete control over access given to custom RBAC roles.
Custom RBAC role management is now also available in the portal, which I think is great. Hopefully this generates more use of the feature!
In this post I want to show you a couple of RBAC templates, more precisely a custom RBAC role for Notification Hub Reader and Notification Hub Administrator. I searched for a role like this, but couldn’t find it, so why not attempt to create one myself.
First of all, here is the definition for Notification Hub Reader, and here is the definition for Notification Hub Administrator. Feel free to download and use as you want.
If you’re new to the Azure Custom RBAC Roles, I recommend reading here first to get some fundamental information. PowerShell is the tool of choice for me, so I will be using this in my examples. You can find all the resource provider operations here for reference.
There isn’t really much to creating these roles. Just download the definitions from my github, update with your own subscriptions guid(s) and run the PowerShell cmdlets provided below. After you have done this, the role can be assigned at the scopes you defined.
After the custom role has been created, you can update the role with Set-AzRoleDefinition. You need to add the definition id, but make sure all the required settings are there, or they will be removed from the role.
New-AzRoleDefinition -InputFile “\NotificationHubReader.json” Set-AzRoleDefinition -InputFile “\NotificationHubReader.json”
I will now explain some of the definitions of this file. I will not go into the actual structure of Custom RBAC definition files, as this is already noted in the Microsoft docs.
“AssignableScopes”: [
**"/subscriptions/",
“/subscriptions/”,
“/subscriptions//”
**]
Replace the values with your subscriptions/resource groups. You do not need to add resource group if it is not relevant for you. I just add all the subscriptions where this custom role should be assignable.
“Microsoft.Resources/subscriptions/resourceGroups/read”
This one grants list permission on the resource group itself. Without it it seems like you can not even see the resource group Notification Hub is connected to.
“Microsoft.Notificationhubs/*/read”
This one grants all the possible “read”-actions on all Notification Hubs and Notification Hubs Namespaces in the resource group. Note that there are other actions which can be considered “read”, but are instead “action”.
“Microsoft.NotificationHubs/Namespaces/authorizationRules/action”,
“Microsoft.NotificationHubs/Namespaces/authorizationRules/listkeys/action”,
“Microsoft.NotificationHubs/Namespaces/NotificationHubs/pnsCredentials/action”,
“Microsoft.NotificationHubs/Namespaces/NotificationHubs/debugSend/action”,
“Microsoft.NotificationHubs/Namespaces/NotificationHubs/authorizationRules/*”
I haven’t added the */action, because there could be actions I do not want readers to perform. In short, these grant some specific operations not covered by Microsoft.NotificationHubs/*/read.
“Microsoft.NotificationHubs/Namespaces/NotificationHubs/authorizationRules/*”
This one merits a specific mention, as it grants all sub-operations on NotificationHubs/authorizationRules. I tried doing only read and listkeys, but the Access Policies section in the portal was greyed out. Ended up just adding all the authRules operations here, but added a “NotAction” to remove delete operation. The user granted this role can regenerate, write and update keys. Maybe it is possible to list keys from PowerShell or Az CLI, but I did not test.
If you want to limit the operations possible for the reader role, you can just play around with it to test what fits or not. E.g. the permission to read and regenerate keys can be removed, and the user will not be able to see them. This fit my use case, and it does not grant too much permissions on the relevant resources at the moment.
This role is somewhat easier, as there are fewer but more generic actions allowed.
“Microsoft.Resources/deployments/write”
This operations grants permission for creating a new deployment in the resource group. Necessary if the admin needs to create new Notification Hubs or Namespaces.
“Microsoft.Resources/subscriptions/resourceGroups/read”
This operation grants access to list the resource group, same as reader role above.
“Microsoft.Notificationhubs/*”
This one grants all possible operations on the NotificationHubs resource provider. You can limit this as much as necessary with the “NotActions” setting. For now this role is good enough