RBAC

What Is Role-Based Access Control (RBAC)? A Complete Guide 

Role-Based Access Control (RBAC) is a method for restricting network access based on the roles of individual users. RBAC allows employees to access only the information they need to do their job. Employee roles in an organization determine the privileges granted to individuals and prevent lower-level employees from accessing sensitive information or performing higher-level tasks.

In the role-based access control data model, roles are based on several factors, including authorizations, responsibilities, and job competency. This model allows businesses to specify whether individuals are end-users, administrators, or expert users. Additionally, a user’s access to computing resources may be restricted to certain operations, such as viewing, creating, or modifying files.

Network access restrictions are especially important for organizations with large numbers of employees and for organizations that allow access to third parties such as customers and suppliers, which can be difficult to monitor. Companies that rely on RBAC can better protect their sensitive data and applications.

This is a part of an extensive series of guides about Access Management.

In this article:

How Role-Based Access Control Works

Before implementing RBAC in an enterprise, the organization should define the permissions for each role as thoroughly as possible. This includes precisely defining permissions in the following areas:

  • Permissions to modify data (e.g., read, write, full access)
  • Permission to access company applications
  • Permissions inside an application

The first step to getting the most out of RBAC is to model roles and permissions. This includes assigning all employee responsibilities to specific roles that determine appropriate privileges. The organization can then assign roles based on the employee’s responsibilities.

Role-based access control allows organizations to assign one or more roles to each user or assign permissions individually. The goal is to define permissions that allow users to perform their tasks without further changes.

Organizations use Identity and Access Management (IAM) systems to implement and monitor RBAC. IAM primarily supports businesses with large numbers of employees by logging, monitoring, and updating all identities and permissions. Assigning permission is called “provisioning” and removing permission is called “deprovisioning”. This type of system requires organizations to establish a unified and standardized set of roles.

Related content: Read our RBAC Kubernetes guide

What Is an RBAC Role?

Within the RBAC framework, roles are semantics that organizations can use to build their privileges. Roles can be defined by various criteria, such as authority, responsibility, cost center, business unit, and more.

A role is a collection of user privileges. Roles are different from traditional groups, which are collections of users. In the context of RBAC, permissions are not directly associated with identities but rather with roles. Roles are more reliable than groups because they are organized around access management. In a typical organization, features and activities change less frequently than identities.

The RBAC Model

There are three types of access control in the RBAC standard: core, hierarchical, and restrictive.

Core RBAC

The core model describes the key elements of a role-based access control system. Core RBAC can serve as a standalone access control method, but it is also the basis for the hierarchical and constraint models.

All RBAC models must adhere to the following rules:

  • Role assignment—a subject can only exercise privileges when the subject is assigned a role.
  • Role authorization—the system must authorize a subject’s active role.
  • Permission authorization—a subject can only apply permissions granted to the subject’s active role.

Hierarchical RBAC

Hierarchical RBAC builds on the basic RBAC model and introduces a role hierarchy. A role hierarchy is a way to structure roles to reflect a complex organizational structure and enable sharing and inheritance of permissions between roles. A simple example of hierarchical RBAC is a series of roles, in which each role inherits the permissions of the previous one, and adds more permissions:

  • Guest user – limited permissions
  • Regular user – same permissions as guest user and more
  • Power user – same permissions as regular user and more
  • Administrator – same permissions as a power user and more

This is useful because any permission added to the guest user, for example, will automatically be added to all roles. 

Hierarchical RBAC supports several types of hierarchies:

  • Tree – bottom-up hierarchy in which the elements at the bottom of the tree grant permissions to elements higher up. For example, at the bottom is a departmental role with general permissions, which grants permissions to multiple employees.
  • Inverted tree – top-down hierarchy in which senior roles inherit some of their permissions to junior roles under them.
  • Lattice – a combination of bottom-up and top-down, where every role can inherit permissions from nodes below it and above it.

The image below illustrates the hierarchy.

Source: NIST

Constrained RBAC

Constrained RBAC adds separation of duties to the core model. There are two types of separation of duties:

  • Static Separation of Duties (SSD)—no single user can have mutually exclusive roles (as defined by the organization). SSD prevents, for example, one person from making purchases and approving those purchases.
  • Dynamic Segregation of Duties (DSD)—users can be members of conflicting roles. However, the same user cannot perform both roles in a single session. This constraint helps control internal security threats by, for example, enforcing a two-person rule that requires two different users to approve an action.

Related content: Read our RBAC vs ACL guide

Examples of Role-Based Access Control

RBAC allows organizations to specify whether users are administrators, expert users, or end-users. Additional options include:

  • Software engineering users who receive access to development tools like cloud services or source control repositories.
  • Marketing users who receive access to marketing tools like web analytics, content management systems (CMS), or customer relationship management (CRM).
  • Finance users who receive access to billing systems or accounting software.

Each role can include a separate management layer and contributor layer. Different roles have varying privilege levels within a given application.

When an end-user’s job changes, the organization must manually reassign the roles to other users—or alternatively, assign the roles to a role group and use role assignment policies to add or remove members of role groups.

When users join a role group, they have access to all the roles in that group. Removing a user from a group restricts that user’s access. Another option is to temporarily assign users to multiple groups, granting them access to certain data or programs and removing them when they no longer need access.

Related Content: Role Based Access Control Best Practices

RBAC in Modern IT Systems

RBAC is used to manage authorization in many modern IT systems, including those powering the transition to the cloud. Let’s see a few examples.

Azure RBAC

Azure RBAC is a real-world implementation of RBAC that helps administrators manage access to Azure resources and define exactly what actions can be performed within them. Azure RBAC is an authorization system based on Azure Resource Manager (ARM).

There are three key elements to assigning a role in Azure.

  • Principal—a user, group, service principal, or managed identity that requested a resource and was granted access to the resource.
  • Role definition—a set of permissions on various Azure resources, associated with the role assigned to a principal. It defines the actions that a principal with a certain role can perform on a resource.
  • Scope—defines the resources the role provides access to and the permission level for one or more roles.

In Azure, it is possible to define scopes directly at the management group, subscription, resource group, or individual resource level. Scopes have a parent-child relationship, and the child resource inherits the permissions of the parent resource.

Azure includes several built-in roles based on industry best practices and Azure resource structures. Azure also provides compatibility for creating custom RBAC roles based on an organization’s requirements.

After defining roles and mapping scopes to these roles, administrators can use role assignments to grant access to a role scope for one or more security principles. They can also de-assign role assignments if the organization needs to remove access. Scopes thus make it easier to manage permissions.

AWS RBAC with Amazon Cognito

The Amazon cloud provides RBAC through the Amazon Cognito service. Cognito enables authentication, authorization, and user management for mobile and web applications. 

Cognito uses the concept of user pools, which are managed user directories, and identity pools, which allow users to gain access to other AWS services. Identity pools grant users temporary, limited-privilege access to AWS resources. These permissions are created through Amazon IAM roles. You can use tokens to assign roles to users of your applications, and leverage rule-based mapping to assign roles to users.

RBAC in Kubernetes

The RBAC model in Kubernetes includes the following components:

  • Role—specifies permissions at the namespace level.
  • ClusterRole—specifies permissions at the cluster level or for namespaces across the environment.
  • Subject—describes a user, group, or service account.
  • RoleBinding—lists subjects and their assigned roles to bind roles to entities at the namespace level.
  • ClusterRoleBinding—lists subjects and assigned roles at the cluster level for every namespace in the cluster.

The rbac.authorization.k8s.io API group determines all role authorization decisions in a Kubernetes cluster. It is best to ensure that the RBAC roles in all clusters are enabled—this helps the organization secure the project and maintain security compliance.

Additional best practices for using Kubernetes RBAC include:

  • Implementing least privilege—with RBAC enabled, it blocks all access by default. An administrator can define permissions at a granular level, granting each user the necessary permissions. The least privilege approach prevents redundant permissions from expanding the attack surface and increasing the security risk. For example, most employees should not have cluster-admin permissions. 
  • Keeping the RBAC policy up to date—an effective RBAC strategy requires continuous maintenance. Admins need to keep adjusting the roles and rules, validating and testing the RBAC. It may be useful to adopt a phased approach to RBAC management, taking the time to understand the issues and successes. Most important is regular reevaluations of the operational state and analysis of the environment for gaps like old user accounts.
  • Keeping the roles simple—Kubernetes RBAC roles are reusable, so there is no need to tailor roles to individual users. Organizations should use the fewest roles possible and avoid continuously creating new roles to enable simpler management. The more roles, the more complex the system becomes and the higher the potential risk. The focus of RBAC is on the roles, not the users.

RBAC Alternatives

There are several ways to manage access control, including access control lists and attribute-based access control.

RBAC vs. ACL

Access control lists (ACLs) are tables that list the permissions associated with computing resources. An ACL is an object-based access control mechanism defining who can access a specific object and what actions are permitted. The operating system allows access based on entries for every user in the system, which list the permitted actions (i.e., view, create, export, etc.).

RBAC is the better option for most organizations because it offers higher security and less administrative effort than ACLs. An ACL may be useful for controlling access to low-level data. However, RBAC is more effective for controlling access.

RBAC vs. ABAC

Attribute-based access control (ABAC) implements a set of policies that manage access permissions according to attributes (i.e., object, user, system, and environmental information). It uses boolean logic to determine if a user can access an object, evaluating set-valued or atomic attributes and their relationships to allow or deny access. 

While RBAC relies on a predefined set of roles, ABAC is granular, making it more complex to manage. An example of the difference between RBAC and ABAC is that the first system might grant GitHub access to all users with a management role, while the second might restrict access to software engineers.

Related: RBAC vs ABAC

Role-Based Access Control Security Best Practices

RBAC can help organizations enhance their security posture and ensure compliance with security standards and regulations. Implementing company-wide RBAC is often complex, so it is important to ensure successful adoption to keep stakeholders on board. When adopting role-based access control, organizations should organize the implementation process using the following phases:

Step 1: Determining the organization’s needs—the organization should comprehensively analyze its business needs before adopting RBAC. The analysis should determine which job functions support established business processes and tools. Auditing and other regulatory requirements should also help inform the RBAC policy. It may be useful to combine RBAC with an additional access control measure in some cases. 

Step 2: Identifying the scope of implementation—the organization should identify the scope of the RBAC needs and align the implementation plan with these needs. The scope should be relatively narrow, focusing on apps and systems that process or store sensitive data. A limited scope makes for an easier transition.

Step 3: Defining the roles—the organization should define roles based on the conclusions of the needs analysis, considering how users can perform their tasks. It is important to avoid the pitfalls of role design, such as an inappropriate level or granularity, excessive exceptions, and overlapping roles.

Step 4: Rolling out the RBAC system—the organization should implement RBAC in stages to avoid disrupting business with overwhelming workloads. For example, the first stage might address a core user group, providing less granular access control and gradually providing more detailed roles. User feedback and monitoring of the RBAC implementation in the computing environment can help plan the rest of the rollout.

RBAC for SaaS Applications with Frontegg

User management is a crucial component of modern SaaS apps due to the multiplication of use cases and customer requirements. You need robust and self-selved capabilities to create an app that can scale up fast without causing stress on IT and dev teams. Frontegg allows organizations to manage roles and permissions seamlessly without losing focus on core tech development.

Our end-to-end user management platform is completely self served and comes with predefined roles and permissions for quick implementation. We also allow the creation of new ones based on your requirements. That’s not all. Your customer’s end-users can also unlock a smooth in-app experience without putting additional stress on your IT teams. A truly self-served option.

Start For Free

See Additional Guides on Key Access Management Topics

Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of access management.

ABAC

Authored by Frontegg

User Management

Authored by Frontegg

Network Topology Mapping

Authored by Faddom

Looking to take your User Management to the next level?

Sign up. It's free