There is some good documentation out about Role Based Access Control (RBAC) for Azure Stack and Azure. I would love to share my thoughts and plans on how we will manage RBAC for Azure Stack. What I am currently doing is still in the planning stages and may change as we move forward with more stamps and more regions. However, this is a baseline that I am setting for our Azure Stack deployments. I would also love feedback from the community. I would love to know what others are doing, what I can do to improve on or change if necessary.
At this time our identity will be Azure Active Directory. So everything I am going to write about today will be based on AAD. I am pretty sure the same idea can be done when using ADFS for identity. This is also a brand new Subscription and the Subscription is dedicated only to this specific Azure Stack deployment. I am also focusing my RBAC roles on the Subscription level. At this time I have not decided if we are going to dig deeper and apply the RBAC roles on the resource groups. You can read more about Resource hierarchy and inheritance on the link below. I am also not going to dig too deep into assigning specialty roles at this point. Since specific roles are Azure Cloud related only and the only three roles in Azure Stack are Owner, Contributor, and Reader.
For my reference, I used the following Microsoft document located on docs.microsoft.com. https://docs.microsoft.com/en-us/azure/azure-stack/user/azure-stack-manage-permissions
So I want to start in Azure Active Directory. Every deployment of Azure Active Directory will start with at least one User Account. This user account should be the Owner of the Azure Subscription. This account also by default is a Global administrator for the directory.
Azure Active Directory
So within Azure Active Directory, I will be creating several groups that will be used for RBAC roles within the Azure subscription we are in as well as the Default Provider Subscription on Azure Stack. These groups will be Security groups and they will be Assigned. So to keep it simple for now since we are only focused right now on RBAC for Azure Stack I am keeping our groups to a minimum. For our security groups within Azure Cloud, we are will name them based on the Role. For the Groups within Azure Stack, we will do the same for our Owners of the Default Provider Subscription but change it up for the Operators and Architects. We can plan to add more groups moving forward for various other roles but at this time it isn’t needed. For instance, we can create application based groups that can be assigned at the Resource level for developers and various other ideas. We can create separate groups based off of User Subscriptions as well. However, at this time we are keeping each User Subscription under the control of the admin account for the owner, then we give the subscription owner Owner Role within that subscription.
So I will create 7 groups out of the box.
- Azure Cloud Contributor
- Azure Cloud Owners
- Azure Cloud Reader
- Azure Stack Architects
- Azure Stack Operators
- Azure Stack Owners
- Azure Stack Read-Only Operators
Our Users
My user management is pretty simple in this situation. Again everything is managed via AAD. For this specific stack environment, it is a cloud-only solution so we are not syncing from on premises. Everything is managed from within the AAD blade or via PowerShell. For both our Azure Cloud and Azure Stack subscriptions, I will tend not to assign a user directly to one of the three roles we are working with. Each user will be assigned to a group and that group is assigned to one of the roles. The only use that is assigned the Owner Role in Azure Cloud directly is our Admin account. (Pay no attention to the image below with one of my accounts assigned! Do as I say not as I do! Ha!) We also will assign the Subscription admin account to the Owner Role of every User Subscription created as well. This will allow us to go back in and assign various groups to the Owner Role, the Contributor Role and the Reader Role.
At this point all our Offers are private so the only way a user subscription can be made is from within the Admin Portal. This allows myself for one to be able to manage each subscription and jump in to see what my users are building! After all, we don’t want anyone creating a Block Chain application on my Stack and mine their own Bitcoins. I mean, that is just reserved for me… I mean….
Azure Cloud Subscription
Now, for our Azure Cloud subscription, we will align the following Azure Cloud groups to their specific roles. Again, moving forward if we deploy anything within this subscription we can add more certain groups. For now, we will make the Azure Cloud Owners an Owner Role, the Azure Cloud Contributor a Contributor, and the Azure Cloud Reader the Reader Role within the Azure Cloud Subscription.
Azure Stack Access
Now let me show you my plans on our Stack. We have our admin account. We have the 4 groups that we created in AAD for our Azure Stack. The next step is pretty basic and follows what we did in our Azure Cloud Subscription. Within the Azure Stack’s Default Provider Subscription I will assign the Azure Stack Operators group as a Contributor, the Azure Stack Read-Only Operators group as a Reader, and then our Azure Stack Architects and Azure Stack Owners groups as an Owner Role. Now, moving forward we may have multiple stacks among multiple regions. We may need for some reason to only allow certain owners and certain operators access to their regions. I haven’t had to do this but it is something I will plan out in the future just in case.
Final Thoughts
There is so much more that can be done with Role Based Access. This is just a simple starter that I am working on. In our bigger and larger Azure Cloud environments we have a lot more groups based on the needed roles. Moving forward, I will start expanding on this base as the demand increase. More than likely as we bring more tenants on to our multi-tenant environments I will see the need to expand our basic RBAC design. As we deploy stacks that we will manage for customers, I also will see the need for groups dedicated to departments and various other verticals within a company. Like I mentioned before. I would really love to hear from the community on how you handle RBAC in your Stacks.