Microsoft Azure security - how to use RBAC and least privileged access
by INVOKE Team
Posted on September 03, 2019 at 12:00 AM
With latest computer hacks, every organization understands that “ security is a business risk” and they are paying sufficient attention while evaluating public cloud providers on how best these providers are in terms of hosting security and compliance. These providers have had no choice but to prove that they take their services security and compliance responsibilities very seriously.
Azure teams what Does Shared Responsibility in the Cloud Mean? blog written by Microsoft Cloud team, goes in depth on this topic, highly recommend to read it. In summary, security in public cloud is “shared responsibility”. Who is responsible for what (in terms of security) depends on the cloud service model you use (IaaS/PaaS/SaaS). With IaaS, the cloud service provider (example, Microsoft Azure Cloud) is responsible for the core infrastructure security, which includes storage, networking and compute (at least at the fabric level – the physical level). As you move from IaaS, to PaaS and then to SaaS, you’ll find that you’re responsible for less and the cloud service provider is responsible for more.
Another nice way Microsoft Cloud team represented shared responsibility of security concept as:
You are always responsible for the following, regardless of the type of deployment:
- Data
- Endpoints
- Account
- Access management
This blog post is about the last bullet point, “Access management”. Managing access to cloud resources is always your responsibility irrespective of whichever cloud service model you are using and Azure provides different tools like Network Security Groups, RBAC etc., to have proper access management controls. We can’t cover every possible approach here, so in this blog post we are limiting our discussion to Azure RBAC.
What is RBAC for Azure resources?
Role-based access control (RBAC) helps in managing who has access to Azure resources, what they can do with those resources, and what areas they have access to.
RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources. Instead of giving everybody unrestricted permissions, RBAC helps in achieving least privileged access to users or resources to get their work done.
How RBAC works?
Azure users need to perform “role assignments” to enforce RBAC for the cloud resources. Role assignment is a 3 step process:
You are always responsible for the following, regardless of the type of deployment:
- Security principle creation (or) use existing security principle
- Role definition
- Scope for this role is applicable
- Security principle
An Azure user, group, service principle, or managed identity can be defined as security principle.
For example: If you are running Azure VM and want to allow this VM to talk to other Azure resources. In this scenario, you can mark this VM as “managed identity” by navigating to “Identity” tab on left pane, then select “System assigned” and set “status” to “ON” and save. We recommend to read our how to retrieve Azure VM performance data retrieval blog post to learn more about how to create “service principal” to access data from a computer which is running outside Azure.
- Role definition or Role
A role definition is a collection of permissions. A role definition lists the operations that can be performed, such as read, write, and delete. Roles can be high-level, like the owner, or specific, like a virtual machine reader. Azure has four fundamental built-in roles:
- Owner - This role grants full access to all resources including the right to delegate access to others.
- Contributor - This role ONLY grants capability to create and manage all types of Azure resources but can’t grant access to others.
- Reader - This type of role can view existing Azure resources.
- User Access Administrator - Lets you manage user access to Azure resources.
There are several built-in roles provided by Azure based on these fundamental roles. You can find a list of all those roles and descriptions here .
Apart from built-in roles, Azure cloud provides an option for users to define their own roles in case of built-in roles do not meet the requirements. These roles are called as “custom role”. Similar to built-in roles, you can assign custom roles to users, groups, and service principals at subscription, resource group, and resource scopes. Because custom roles are stored in Azure Active Directory, these can be shared across subscriptions.
- Scope
Scope is the set of resources that the role based access is applicable for. When you assign a role, you can further limit the actions allowed by defining a scope. Scope can be specified at either management group, subscription, resource group, or resource level. Scopes are structured in a parent-child relationship.
Once you identify the scope where RBAC should be applied, the process would be, create role definition with fine grained permissions(always remember least privileged access) and attach the permission to security principal. Then assign the “role” to a scope like subscription or resource group etc.,
In summary, security principal, role definition, scope together helps in establishing proper RBAC controls for cloud resources.
INVOKE team strength is automating the cloud resource management and optimize cloud hosting costs . Our team created and opensourced a power shell script on INVOKE GitHub repository. This script automates the role definition and attach to multiple scopes. We welcome enhancements or suggestions for improvements.
What happens if you have multiple overlapping role assignments?
Azure role based access is additive model, which means the effective permissions are addition of all the role assignments and role with the highest privilege will be enforced. For example, if you have a contributor role and reader role assigned to a resource group, the addition of contributor role and reader role permissions will end up as contributor role. To avoid this confusion try to avoid “overlapping” role assignments and go with least privileged custom role definitions wherever applicable.
In summary, security in public cloud is shared responsibility. RBAC is one of the tools provided by Azure to address “access management” controls for cloud users. Using least privileged approaches, cloud resource consumers can reduce the risk of cyber threats and hence reduce business risks.
Hope this blog post provided some value for you and by the way INVOKE Cloud has RBAC control which helps your team see ONLY the resources they are authorized to work with. For example, QA team can access ONLY VM’s dedicated for QA purposes. DEV can access VM’s dedicated for development ONLY etc., looking for solutions like this, reach us at info at invoke dot cloud. If we are not the best fit for your requirement, we may be able to recommend someone who could help you.
