Azure Active Directory and Resource Groups

Resource groups are a key part of separating workloads and managing content created in your subscriptions. We’ve helped many customers with their resource group strategy while working on data warehousing projects with Azure.

In this post, I’ll talk about resource groups and the advantages of separating workloads into resource groups such as the ability to manage access controls with Azure Active Directory. There are 3 things you need in place to make this simple and easily repeatable:

1. Have Azure Active Directory set up in your subscription. Every Azure and Office 365 sets this up, so in reality, it’s already done. In Azure Active Directory (AAD) you need to set up groups to match the security context you plan to use. You can initially use generic groups like Dev or Test, but more finite groups will be required as you move along.

If you’re syncing with your on premises Active Directory, you may be able to reuse existing groups within your resource groups going forward.

2. Create the resource group. Everything you create in Azure should be done in a resource group and I’ve seen many variations on how to do this. Some use this to provide levels of separation for development, tests or production areas in their subscriptions. Others separate by function such as networking or databases. I prefer to do it by workload. If you want to manage access via resource groups, you may want to combine some of these concepts.

For example, you may have your development and BI resource group, but you need to use a good naming convention to understand the purpose of the group you’re creating, as well as tags to support what you’re using the resource group for.

3. Marry the two. Go to your access group and on the right option panel you will see the access control option. Here you can add users or groups to the roles that are in context with the resource groups you’re working in, so it’s limited to that resource group.

Below are the top 3 general use cases we see people use until they get more familiar or want to create their own rules:

• Owners – Owners can fully manage a resource group, add users, add content and have access to some of the security protocols within that group. They have a lot of permission and control so be careful with this one.
• Contributors – This is the most common that we see used because they’re the group that you want to be able to interact with the group, add content, work with resources, etc. without having to tightly manage it.
• Readers – These people can see the resource group but can’t fully implement any changes – a ‘read only’ type role. They can audit or look at what you’re doing but cannot effect any changes on the resource group or the resources within it.

As your needs grow, you’ll probably need custom roles and more fine-grained permissions to limit access to your group as you move forward. When you hit the drop down when you set up permissions there are a whole myriad of roles that you can add. You’ll want to get a plan in place to manage how you want to do it.

Using resource groups in Azure Active Directory has the added advantage of supporting guest users. If you have contractors or consultants that need to work in a resource group, you can create a group in AAD with the level of access that you want to allow and use the Azure B to B functionality to create guest users for that group. Once a consultant(s) leaves, you can just kill all those users and they’ll no longer have access to that resource group.

This gives you the opportunity to expand what your doing and better tie down your environment and allow for more access to the workloads that need to be handled by other people.

Again, we’ve helped many customers to put a resource strategy together. If you have questions or would like help with this or anything within Azure, we are your best resource. Click the link below or contact us—we’d love to help.