From time to time, developers need custom Identity and Access Management (IAM) roles in Azure—typically to perform a specific activity in the lower lifecycles that isn't covered by a built-in role.
Best Practices
Whenever creating custom roles there are a few things to keep in mind:
- Try to start with a built-in role and clone it.
- Least privilege - Define exactly what the role should be able to do.
- Create the roles at the same level, usually Tenant Root.
- Use Naming Convention for easy identification.
- If not using, delete.
- Document.
- Test, test, test.
Example - Service Bus Developer
We had a need for developers in the lower lifecycles to be able to create / delete / update topics and queues as well as peek messages. There are three different built-in roles for Service Bus (SB), but unfortunately the only one that allows you to peek messages is "Service Bus Data Owner" where you can do anything.
We wanted to keep Service Bus deployment executed in automated fashion by the cloud team, but enable these other functions for the devs so they could do their jobs effectively.
Defining the Role
With our clear expectation on what the devs needed to be able to do, we start working through the perms. Here is our list.
"Microsoft.ServiceBus/checkNamespaceAvailability/action",
"Microsoft.ServiceBus/checkNameAvailability/action",
"Microsoft.ServiceBus/namespaces/read",
"Microsoft.ServiceBus/namespaces/authorizationRules/read",
"Microsoft.ServiceBus/namespaces/authorizationRules/listkeys/action",
"Microsoft.ServiceBus/namespaces/eventGridFilters/write",
"Microsoft.ServiceBus/namespaces/eventGridFilters/read",
"Microsoft.ServiceBus/namespaces/eventGridFilters/delete",
"Microsoft.ServiceBus/namespaces/eventhubs/read",
"Microsoft.ServiceBus/namespaces/ipFilterRules/read",
"Microsoft.ServiceBus/namespaces/operationresults/read",
"Microsoft.ServiceBus/namespaces/skus/read",
"Microsoft.ServiceBus/namespaces/providers/Microsoft.Insights/logDefinitions/read",
"Microsoft.ServiceBus/namespaces/providers/Microsoft.Insights/metricDefinitions/read",
"Microsoft.ServiceBus/namespaces/queues/write",
"Microsoft.ServiceBus/namespaces/queues/read",
"Microsoft.ServiceBus/namespaces/queues/Delete",
"Microsoft.ServiceBus/namespaces/queues/authorizationRules/write",
"Microsoft.ServiceBus/namespaces/queues/authorizationRules/read",
"Microsoft.ServiceBus/namespaces/queues/authorizationRules/delete",
"Microsoft.ServiceBus/namespaces/queues/authorizationRules/listkeys/action",
"Microsoft.ServiceBus/namespaces/queues/authorizationRules/regenerateKeys/action",
"Microsoft.ServiceBus/namespaces/topics/write",
"Microsoft.ServiceBus/namespaces/topics/read",
"Microsoft.ServiceBus/namespaces/topics/Delete",
"Microsoft.ServiceBus/namespaces/topics/authorizationRules/write",
"Microsoft.ServiceBus/namespaces/topics/authorizationRules/read",
"Microsoft.ServiceBus/namespaces/topics/authorizationRules/delete",
"Microsoft.ServiceBus/namespaces/topics/authorizationRules/listkeys/action",
"Microsoft.ServiceBus/namespaces/topics/authorizationRules/regenerateKeys/action",
"Microsoft.ServiceBus/namespaces/topics/subscriptions/write",
"Microsoft.ServiceBus/namespaces/topics/subscriptions/read",
"Microsoft.ServiceBus/namespaces/topics/subscriptions/Delete",
"Microsoft.ServiceBus/namespaces/topics/subscriptions/rules/write",
"Microsoft.ServiceBus/namespaces/topics/subscriptions/rules/read",
"Microsoft.ServiceBus/namespaces/topics/subscriptions/rules/Delete",
"Microsoft.ServiceBus/operations/read",
"Microsoft.ServiceBus/sku/read",
"Microsoft.ServiceBus/sku/regions/read"
That seems like a lot, right? Arguably a few of the read perms could be removed but each write or delete was specifically needed.
Test, Test, Test
It’s important to remember that testing is crucial for any custom role. You have to strip down someone's perms so they only have access to this role and test empirically until you get it right. One thing you will quickly notice, if you get something wrong on the first pass (solid possibility) it can take some time for updates to filter out.
Here are the test cases we used for this role:
- Can't create new SB
- Can create new topics
- Can create new queue
- Can create shared access policies
- Can create new topic subscriptions
- Can't change any networking aspects
- Can't change geo-recovery
- Can't scale messaging units
- Can't create or edit existing diagnostic settings
- Can use Service Bus Explorer to interact and 'peek' messages
Summary
At times there is a natural push / pull to the relationship between cloud engineers and application developers. The important thing for cloud professionals to remember is the tools are there to safely deliver nearly any scenario if you put the time in. In this situation, we were able to develop clear requirements (always key), test fully, and enable the application devs to more successfully execute their jobs without depending on us. Win-win.
Have questions or comments? Feel free to contact us directly at ecms@eplus.com anytime. Be sure to check out the full ePlus Cloud Managed Services blog. Happy Clouds!