Download the eBook here.
One of the first questions that I get from customers who are serious about Microsoft Azure Cloud offering is “Where do I start?”, “What is an Azure subscription?” When you swipe your credit card or buy Azure what exactly do I get. To that extent the question from enterprise customers then is “How do I isolate work between various project teams?”, “What about show-back or charge-back?”
It was becoming tough to explain these in a single blog post, so I decided to write it in the form of a quick eBook so that you can download and read it as a complete topic.
Subscription container model in Azure
This is the cover image I choose for this book “Understanding Azure Subscription”. It’s from Wikipedia. It’s called Matryoshka doll. The reason for choosing this image is of course covered in the eBook, so read on :). In short, you need to plan before you really get started in terms of leveraging various Azure features and this book helps you understand exactly that. The details in this book are not a must to know before you start working with Azure, but yes, knowing it makes your life easier specially if you are thinking multiple projects, isolation, network layout and so on.
Hopefully you will enjoy reading this. Have fun!
The New Azure Preview Portal.
The user experience for the new azure preview portal (portal.azure.com) is quite different than the current management portal (manage.azure.com). I am no UX expert by any stretch but I wanted to introduce the vocabulary for the new Azure preview portal. So, let’s jump straight in-
Startboard: The first layout you are presented with when you login to azure.portal.com. You can pin various entities you feel you need one click access to Startboard.
Blade: Vertical container that acts as a starting point for a journey. Can contain multiple parts.
Part: Components that provide reusable units of functionality.
Lens: Container for parts.
azure portal- blade, lens and part
Journey: Series of steps that a user follows (represented by sequential blades)
- azure portal- journey
Jump Bar: As the name says it, it’s a jump bar.
azure jump bar
Browse Hub: Hubs are the central location for global services that all extensions leverage.
I will keep adding to the list as I come across new ones. Hope you learnt something new!
On 2/20/2015 Microsoft announced release of additional set of role based access controls. In my previous blog post we talked about RBAC concepts. In this blog post I wanted to highlight the importance of these new roles.
You can see this in the Azure preview portal today, you can now see additional roles come up as shown below-
New RBAC roles
Before 2/20/15 you could just see ‘owner’, ‘contributor’ and ‘reader’, now can see these additional 20 roles. If you give a closer look, all these are essentially contributor roles.
|API Management Service Contributor
||Let’s you manage API Management service, but not access to them.
|Application Insights Component Contributor
||Let’s you manage Application Insights components, but not access to them.
||Let’s you manage BizTalk services, but not access to them.
|ClearDB MySQL DB Contributor
||Let’s you manage ClearDB MySQL databases, but not access to them.
||Contributors can manage everything except access.
|Data Factory Contributor
||Let’s you manage data factories, but not access to them.
|Document DB Account Contributor
||Let’s you manage DocumentDB accounts, but not access to them.
|Intelligent Systems Account Contributor
||Let’s you manage Intelligent Systems accounts, but not access to them.
|NewRelic APM Account Contributor
||Let’s you manage New Relic Application Performance Management accounts and applications, but not access to them.
||Owner can manage everything, including access.
||Readers can view everything, but can’t make changes.
|Redis Cache Contributor
||Let’s you manage Redis caches, but not access to them.
|SQL DB Contributor
||Let’s you manage SQL databases, but not access to them. Also, you can’t manage their security-related policies or their parent SQL servers.
|SQL Security Manager
||Let’s you manage the security-related policies of SQL servers and databases, but not access to them.
|SQL Server Contributor
||Let’s you manage SQL servers and databases, but not access to them, and not their security-related policies.
|Scheduler Job Collections Contributor
||Let’s you manage Scheduler job collections, but not access to them.
|Search Service Contributor
||Let’s you manage Search services, but not access to them.
|Storage Account Contributor
||Let’s you manage storage accounts, but not access to them.
|User Access Administrator
||Let’s you manage user access to Azure resources.
|Virtual Machine Contributor
||Let’s you manage virtual machines, but not access to them, and not the virtual network or storage account they’re connected to.
|Virtual Network Contributor
||Let’s you manage virtual networks, but not access to them.
|Web Plan Contributor
||Let’s you manage the web plans for websites, but not access to them.
||Let’s you manage websites (not web plans), but not access to them.
All this gives one more level at which you can assign permissions to resources. Earlier if you were a contributor for a ‘resource group’, you could do everything across all resources like VMs, VNets and so on within the resource group. Now you if you are part of “Virtual Machine Contributor” you can only deal with Virtual Machine(s) in the resource group and not VNets or other resources. This brings in one more level of granularity.
Azure role based access control.
A word about resource groups-
Prior to resource groups’ introduction into Azure, the recommendation for achieving isolation was to use as many subscriptions as needed in a Microsoft Azure account(s). That was good, but it certainly introduced issues around network and resource sharing like AD and so on. And you had to do VPN between these networks for resource sharing. Lot of work for achieving the isolation.
Introduction of ‘resource groups’ and ‘RBAC’ makes it easy to achieve this isolation level. As you can guess, there certainly is a need to group entity actions together to make this flexible and achieve granular scenarios. For example, it would be better if there can be a custom role where we can pick few actions from Network and few actions from Virtual Machines. That should possibly be a road-map item for Azure RBAC.
Microsoft Azure RBAC
What is Azure RBAC?
RBAC is role based access control. A bit of history to begin with might help understand this better. Before RBAC there were two basic roles in Azure- 1) service administrator and 2) co-admin for a subscription (of course this is outside of the EA roles like Account/Department admin)
Azure Subscription roles
Members who are part of these roles can do everything in a subscription right from VNet creation, VM creation and accessing logs and what not. Co-Admins are added from the management portal- manage.windowsazure.com and you can have more than one co-admin. Service Administrator is added by the Account Manager (added/managed from enterprise portal- ea.windowsazure.com). Members in both of these roles cannot see billing details (in the case of Enterprise Account) and for any tickets you open with Microsoft support, the email of service administrator is used for communication.
The distributed world of application development and infrastructure management requires much more than that. You may want few members to just take care of VMs, few others for Storage and so on. You may want to further assign different privileges within that. Like some could only view while others could create and so on. That basically is fine grained control. That’s what RBAC is all about. RBAC is not as complete as that as of this writing (02/01/2015) but it’s let’s say v1 towards that goal.
As of this writing you have three built-in roles (Owner, Contributor and Reader) available for assignment to Users, Groups and Services on Azure scopes: Subscription, Resource Group and Resources. You can manage the access using Azure portal, Command Line Tools & REST API for bulk operations.
What you can achieve today in RBAC is depicted in the graphic below-
The important architectural element worth noting is that these roles can actually be your IDMS roles (from your on premise AD which is federated). So that’s all for the introduction to Azure RBAC. I will further elaborate this with an example in a separate blog post.