RBAC stands for Role-Based Access Control. It is a method of regulating access to servers, computers or network resources based on the roles of individual users within an organization. RBAC allows administrators to define roles, assign permissions to those roles and then assign users to the appropriate roles for their job functions. This allows for a more fine-grained approach to access control, as users should only be given the permissions they need to perform their jobs.

A common role in a cloud environment might be "Cloud Infrastructure Administrator" or simply an “SRE Team”. This role would manage and maintain the organization's cloud infrastructure. As such, the SRE role would likely be granted permissions to perform tasks such as:

Managing and provisioning cloud resources, such as virtual machines and storage
Configuring and managing network and security settings
Monitoring cloud resource usage and costs
Managing user access and permissions to the cloud environment
Automating cloud infrastructure deployment and scaling

This example is just one of the many roles that can be defined in a cloud environment, depending on the specific needs of the organization and the different job functions that exist within it.

RBAC and ACLs

Access Control Lists (ACLs) are access control mechanisms often used in conjunction with Role-Based Access Control (RBAC). Using ACLs in combination with RBAC provides a more fine-grained and flexible approach to access control.

In an ACL-based system, each resource is associated with an ACL specifying the permissions different users or groups have for that resource. For example, an ACL for a file might specify that certain users have read-only access while others have read-write access.

RBAC, on the other hand, is a method of regulating access to resources based on the roles of individual users within an organization. RBAC allows administrators to define roles, assign permissions to those roles and then assign users to the appropriate roles for their job functions.

When used together, ACLs and RBAC provide a powerful and flexible way to control access to resources. For example, an organization might use RBAC to define roles such as "developer" and "administrator" and assign permissions to those roles and then use ACLs to further refine access control by specifying individual role/shared user permissions or groups for specific resources. This allows for a more fine-grained and flexible approach to access control, as users are only given the permissions they need to perform their jobs.

For example, with Teleport, teams will use RBAC to map an SSO user to a Local Linux User. Consider this: If Alice logs into a server with ubuntu, the user will have access to `rwx`. If you want to provide more fine-grained ACLs in Linux, a dedicated user with specific ACLS should be created if a team wants to restrict access.

ubuntu@ip-10-0-0-98:~$ getfacl /home/ubuntu
getfacl: Removing leading '/' from absolute path names
# file: home/ubuntu
# owner: ubuntu
# group: ubuntu
user::rwx
group::r-x
other::r-x

Limits of RBAC

RBAC (Role-Based Access Control) is a widely used method for controlling access to resources and has several benefits, such as fine-grained control and ease of management.

However, it also has some limitations:

Limited expressiveness: RBAC can be limited in its ability to express complex access control requirements, particularly those that involve multiple roles or attributes.
Limited scalability: As the number of roles and users in an organization grows, the number of role-permission assignments can grow exponentially, which can make management and maintenance of the access control system difficult.
Limited support for dynamic environments: RBAC is designed for static environments where roles and permissions are predefined and do not change frequently. It may not be as well-suited for dynamic environments where roles and permissions need to be updated frequently or in real time.
Limited support for delegation of authority: RBAC does not inherently support delegation of authority, meaning that a user cannot assign permissions to another user.
Limited support for accountability: RBAC does not provide an inherent mechanism for tracking which users have performed which actions, making it difficult to determine accountability in case of a security incident without other tooling in place.
Limited support for context-aware access control: RBAC does not provide an inherent mechanism for taking into account contextual information such as the time of day or the location of the user when making access control decisions.

Organizations may sometimes need to consider using other access control methods, such as ABAC (Attribute-Based Access Control) or combine them with RBAC for a comprehensive security strategy.

Implementing role-based access control

Implementing Role-Based Access Control (RBAC) involves several steps:

Define roles: The first step in implementing RBAC is to define the roles that will be used in your organization. These roles should correspond to different sets of permissions and should be based on the different job functions within your organization. For example, you might define roles such as "developer", “devops”, "administrator", and "user".
Assign permissions to roles: Once you have defined your roles, you will need to assign permissions to each role. These permissions will determine what actions users in a particular role can perform. For example, you might give the "administrator" role the ability to create, read, update and delete resources, while the "developer" role only has the ability to read and update resources.
Assign users to roles: Once you have defined your roles and assigned permissions to them, you will need to assign users to the appropriate roles. Depending on your organization's requirements, this can be done manually or via an automated process, such as linking Okta groups to Roles.
Enforce access control: The next step is to enforce the access control policies you have defined, which can be done by integrating the RBAC system with the resource management system. This can be done by modifying the roles or by using libraries or frameworks that implement RBAC, such as Teleport Predicate.
Auditing and compliance: The final step is ensuring that the RBAC system complies with the organization's security requirements and regulatory compliance, including auditing and reporting on user access to resources. This can be done by logging the access attempts, generating reports based on those logs and sending them to a SIEM solution.