Azure Role-Based Access Control (RBAC)

Azure Role-Based Access Control (RBAC)

Azure Role-based access control (RBAC) is a policy-neutral access-control mechanism defined around roles and privileges. The components of RBAC such as role-permissions, user-role, and role-role relationships make it simple to perform user assignments.

Access management for cloud resources is a critical function for any organization that is using the cloud. Azure role-based access control (Azure RBAC) helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to.

Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources.

When defining an RBAC model, the following conventions are useful:

• S = Subject = A person or automated agent
• R = Role = Job function or title which defines an authority level
• P = Permissions = An approval of a mode of access to a resource
• SE = Session = A mapping involving S, R and/or P
• SA = Subject Assignment
• PA = Permission Assignment
• RH = Partially ordered Role Hierarchy. RH can also be written: ≥ (The notation: x ≥ y means that x inherits the permissions of y.)
• A subject can have multiple roles.
• A role can have multiple subjects.
• A role can have many permissions.
• A permission can be assigned to many roles.
• An operation can be assigned to many permissions.
• A permission can be assigned to many operations.

EXAMPLES OF ROLE-BASED ACCESS CONTROL

Through RBAC, you can control what end-users can do at both broad and granular levels.

You can designate whether the user is an administrator, a specialist user, or an end-user, and align roles and access permissions with your employees’ positions in the organization.

Permissions are allocated only with enough access as needed for employees to do their jobs.

What if an end-user’s job changes? You may need to manually assign their role to another user, or you can also assign roles to a role group or use a role assignment policy to add or remove members of a role group.

By adding a user to a role group, the user has access to all the roles in that group. If they are removed, access becomes restricted. Users may also be assigned to multiple groups in the event they need temporary access to certain data or programs and then removed once the project is complete.

Other options for user access may include:

• Primary — the primary contact for a specific account or role.
• Billing — access for one end-user to the billing account.
• Technical — assigned to users that perform technical tasks.
• Administrative — access for users that perform administrative tasks.

BENEFITS OF RBAC :

1. Reducing administrative work and IT support.
2. Maximizing operational efficiency.
3. Improving compliance.

Azure RBAC can do the following things :

• Allow one user to manage virtual machines in a subscription and another user to manage virtual networks
• Allow a DBA group to manage SQL databases in a subscription
• Allow a user to manage all resources in a resource group, such as virtual machines, websites, and subnets
• Allow an application to access all resources in a resource group.

Role definition in RBAC :

A role definition is a collection of permissions. It’s typically just called a role. A role definition lists the operations that can be performed, such as read, write, and delete. Roles can be high-level, like owner, or specific, like virtual machine reader.

Azure includes several built-in roles that you can use. The following lists four fundamental built-in roles. The first three apply to all resource types.

• Owner — Has full access to all resources including the right to delegate access to others.
• Contributor — Can create and manage all types of Azure resources but can’t grant access to others.
• Reader — Can view existing Azure resources.
• User Access Administrator — Lets you manage user access to Azure resources.

SCOPE OF RBAC :

Scope is the set of resources that the access applies to. When you assign a role, you can further limit the actions allowed by defining a scope. This is helpful if you want to make someone a Website Contributor, but only for one resource group.

In Azure, you can specify a scope at multiple levels , scopes are structured in a parent-child relationship.

When you grant access at a parent scope, those permissions are inherited to the child scopes. For example:

• If you assign the Owner role to a user at the management group scope, that user can manage everything in all subscriptions in the management group.
• If you assign the Reader role to a group at the subscription scope, the members of that group can view every resource group and resource in the subscription.
• If you assign the Contributor role to an application at the resource group scope, it can manage resources of all types in that resource group, but not other resource groups in the subscription.

Role assignments :

A role assignment is the process of attaching a role definition to a user, group, service principal, or managed identity at a particular scope for the purpose of granting access. Access is granted by creating a role assignment, and access is revoked by removing a role assignment.

The following diagram shows an example of a role assignment. In this example, the Marketing group has been assigned the Contributor role for the pharma-sales resource group. This means that users in the Marketing group can create or manage any Azure resource in the pharma-sales resource group. Marketing users do not have access to resources outside the pharma-sales resource group, unless they are part of another role assignment.

Ways to create RBAC :

1. We can create role assignments using the Azure portal, Azure CLI, Azure PowerShell, Azure SDKs, or REST APIs.

2. We can have up to 2000 role assignments in each subscription. This limit includes role assignments at the subscription, resource group, and resource scopes.

3. We can have up to 500 role assignments in each management group. To create and remove role assignments, you must have Microsoft.Authorization/roleAssignments/* permission.

Azure RBAC was an allow-only model with no deny, but now Azure RBAC supports deny assignments in a limited way.

Similar to a role assignment, a deny assignment attaches a set of deny actions to a user, group, service principal, or managed identity at a particular scope for the purpose of denying access.

How the roles are related to each other ?

Azure has mainly managed with just three administrator roles:

1. Account Administrator,

2. Service Administrator, and

3. Co-Administrator.

Azure role-based access control (Azure RBAC) was added later on for the finer granular access to the resources.

Azure RBAC includes many built-in roles, can be assigned at different scopes, and allows you to create your own custom roles. To manage resources in Azure AD, such as users, groups, and domains, there are several Azure AD roles.

The following diagram is a high-level view of how the classic subscription administrator roles, Azure roles, and Azure AD roles are related.

In the Azure portal, role assignments using Azure RBAC appear on the Access control (IAM) blade. This blade can be found throughout the portal, such as management groups, subscriptions, resource groups, and various resources.

When you click the Roles tab, you will see the list of built-in and custom roles.

Azure AD roles

In the Azure portal, you can see the list of Azure AD roles on the Roles and administrators blade.

Differences between Azure roles and Azure AD roles :

Contact us for Microsoft Azure training related query.