Microsoft Azure RBAC- Part 2

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

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.

ROLE NAME DESCRIPTION
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.
BizTalk Contributor 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.
Contributor 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 Owner can manage everything, including access.
Reader 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.
Website Contributor 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.

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.

Thanks, -Phani

Posted in Azure IAM | Tagged , , | Leave a comment

Microsoft 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

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-

Azure-RBAC-Layout

 

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.

-Phani

Posted in Azure IAM | Tagged , | Leave a comment

Windows azure caching 101

In Windows Azure there are three options for caching- Shared Cache Service, In-role caching and Azure Cache Service:

  1. “Shared Caching Service”, this was caching on a shared cluster and one could access the cache using the secret key. This is a multi-tenant offering and enforced throttling behavior and hence many windows azure customers didn’t like this. This is being retired sometime Aug 2014. This btw, is not even there in the current HTML portal and hence many people don’t know about the existence of this mechanism.
  2. “In-role cache”

This was an offering where you could mention that a portion of your webrole or worker role be used for caching purpose.

webrole for caching

webrole for caching

worker role for dedicated caching

worker role for dedicated caching

You can mention this in a cloud service project in Visual Studio:

Visual Studio Settings for caching

In the web role properties, you can select the Caching section and turn on caching by checking the “Enable Caching” select box.

You can specify which percentage of the web role memory you want towards cache size if using “co-located role” model. If you select dedicated role (2nd graphic above) (please note: dedicated role caching is only supported on worker roles and cannot be configured on web roles), the worker role is dedicated for caching purpose. Billing for in-role caching is same as compute web/worker role billing. And it’s available in small (1.75), medium (3.5), large (7) and extra-large (14) sizes.  Although the compute roles have the said memory, please note that some resources would however be used by the OS.

3.  “Cache Service”

Cache service is the latest offering. It brings the best of both worlds. While in-role caching was available for use only from within the cloud service, cache service makes the cache data available on a public end point by use of a secret key. It has few other really wonderful aspects like highly available data for the cache data, in the sense that the data is cached in a cluster from a failover perspective. Both the service and the data itself are highly available in this case. It’s not a shared service as the originally available cache service, so no throttling! There are also few advanced features like notification to the client when cache changes and so on, which makes it really best a reliable and advanced cache service offering.

Note on memcached:

memcached is a high-performance, distributed memory object caching system, generic in nature, but originally intended for use in speeding up dynamic web applications by alleviating database load. The system uses a client–server architecture. The servers maintain a key–value associative array; the clients populate this array and query it. Keys are up to 250 bytes long and values can be at most 1 megabyte in size. Clients use client-side libraries to contact the servers which, by default, expose their service at port 11211. Each client knows all servers; the servers do not communicate with each other.

If you have existing applications which use memcached, you can readily use them in windows azure. Windows Azure Caching supports almost every API that other Memcache implementations support. Memcached in windows azure works with the in-role caching mechanism as of the writing of this blog post. In future it could be expected to be made available with “cache service” too.

Posted in Azure | Tagged , , | Leave a comment

Windows Azure Portal View restructured to filter by directory

Just noticed today, right now (22OCT2013), that the WindowsAzure portal now filters the view based on Azure Active Directory. Have a look at the graphic below and you will understand what I am talking about-

azure subscription by directory

azure subscription by directory

If you were to login to the portal today, you will see the following message come up- “The subscriptions view has been restructured to filter by directory. Resources shown here belong to subscriptions associated with the ‘Default Directory’ directory only.” And you cannot view details for all directories at once.

What does this mean?

Basically this means that when a subscription is created for a user, a Microsoft Azure directory (<<your Microsoft account alias>>.onmicrosoft.com) is created and the current Microsoft account (user) becomes a part of that directory. And now you add co-admins as part of this directory. Essentially a directory container is added to the azure subscription.

Essentially, think about the number of Azure AD tenants being provisioned today? Basically all the azure subs got a directory, isn’t it? Phew! Far too many. And are the users are getting authenticated against Azure AD/ACS? yes.

Why is Microsoft doing this? My thinking is that this will help lot of enterprise customers to start federating on premise AD to Azure AD and getting authenticated from there. Avoids the hassle of creating one more Microsoft account(s). This will also mean rapid adoption and understanding of Windows Azure Active Directory. Sweet!

-Phani

 

Posted in Windows Azure Active Directory | Tagged , | Leave a comment