Know your access control: RBAC vs. ABAC

Working together successfully as a team — especially in this increasingly remote world — is all about collaboration. As part of that collaboration, it’s critical that team members have access to the files and programs they need to accomplish their jobs, and that access should be easily revocable for when employees change roles or leave the company. This is achieved through access control, which, simply put, defines who is allowed to access what. In this post, we’ll examine the various approaches to access control, and look at a comparison of two of the most popular: role-based access control (RBAC) versus attribute-based access control (ABAC). We’ll also briefly discuss how access control methods like RBAC contribute to secure monitoring best practices.

What is access control?

Before a user is able to gain access to a system or set of data, we first have to ascertain that it’s appropriate for them to do so. In order to protect our critical assets, we need to be able to properly identify our users and then verify, approve, and track that access. A user may identify themselves with a username, and then they’re authenticated to the system with something they know (like a password), something they have (like a token), or something they are (using biometrics, like a thumbprint or retina scan). Once a user has successfully authenticated, we’ll need to determine what they’re allowed, or authorized, to do on the system. Finally, depending on the sensitivity level of your data, you’d also want to conduct periodic audits of user access, a process known as accountability, which is out of scope for this post.

When thinking about access control, consider the principle of least privilege: you want to give people the minimum amount of access they need to do their jobs effectively.

Now that we’ve established the process and philosophy behind access control, we can get into some of the methods. We’ll start with a high-level overview of the various methods before we dive deeper into our RBAC versus ABAC comparison.

Access control methods

The type of access control you set up is entirely dependent on your organization’s needs and the sensitivity of your data. Here are a few of the most common methods of access control:

• Discretionary access control (DAC) is managed by users — i.e., a username and password they set themselves. With this method, users can share their password with others.
• On the other end of the spectrum, with mandatory access control (MAC) all access is set by the system. This method is more work intensive because you have to classify your data and users must have a clearance to access that data. Unlike a password, they can’t simply give their clearance to another person.
• Role-based access control (RBAC) is based on group membership — you can assign access to users based on their roles within your organization. Groups, in turn, are assigned permissions which authorize to perform certain actions on certain assets.
• Attribute-based access control (ABAC) grants access to users based on a set of attributes (no surprise there, based on the name!). You set a policy which combines attributes together, and attributes can be associated with users, resources, objects, environment, and more.

Both discretionary and mandatory access control offer two opposite ends of the spectrum. While a DAC model might be appropriate for smaller businesses, it certainly doesn’t scale or foster a secure environment as the business grows. A MAC model, on the other hand, might be quite secure, but it comes at a great operational cost, and as such is the least efficient method. Remember, security is all about balance — you want to empower folks to do their jobs, without sacrificing security. On the other side of the coin, you don’t want to lock things down to the extent that no one can get any work done.

In the next section, we’ll dive deeper into RBAC and ABAC, both methods which help maintain that balance a bit better than discretionary or mandatory models.

RBAC versus ABAC

What is ABAC?

As noted briefly above, attribute-based control (ABAC) uses attributes assigned to an individual resource to determine who can access what. These attributes can refer to the individual employee’s team and role within a company, as well as environmental conditions, such as the IP address and device used to access a resource.

For example, you could restrict access to a resource by setting one attribute to role = manager, another as team = engineering, and yet another as IP address = [your corporate network IP range]. That would restrict access to that resource to individuals who are managers on the engineering team, and they can only access that resource when on the company network.

What is RBAC?

Role-based access control (RBAC for short) is an authorization mechanism that decides which actions users can perform against resources. RBAC makes it easy for you to manage user access by assigning users to various roles. These roles in turn define a set of permissions that users in that group can execute — for example, read access on a certain file.

The engineering team is granted access to your GitHub repository, but not the personnel files of employees within the organization. The HR team doesn’t need access to your GitHub repo, but they do need access to those employee files. Any member on the engineering or HR team will be able to access the appropriate resources related to their role. By assigning individual members of each team to their respective group (i.e., based on their roles), you can make sure everyone has access to what they need, and nothing more.

This model works quite well for monitoring, where you may need to control which groups have access to certain resources in your monitoring tool. At Sensu, we’ve designed our RBAC model after Kubernetes RBAC, with a workflow that will be quite familiar to a Kubernetes user: permissions can be configured using sensuctl or the Sensu API itself and the same top-level types are declared: Role, ClusterRole, RoleBinding, and ClusterRoleBinding. (For more resources on Kubernetes RBAC, we like this resource from rbac.dev, which has pulled together several helpful links on K8s RBAC good practices.)

RBAC versus ABAC: differences, benefits, & downsides

One key distinction between RBAC and ABAC is their static versus dynamic nature, as implied in their respective models — RBAC permits access based on roles, which are generally fairly static within an organization, where ABAC relies on attributes, which can be dynamic — changing, for example, when a user attempts to access a resource from a different device or IP address.

This brings us to the benefits and downsides of each model: ABAC can be automated to update permissions, and — once everything is set up — requires less overall administration. It’s also secure when set up correctly. In terms of downsides, ABAC can be quite complex and environment-specific, and complicated attribute sets can be hard to scale. It’s also hard to audit for compliance purposes — you have to check each individual object against your access policy, as opposed to simply checking what access a particular user has.

RBAC, on the other hand, is highly efficient and can streamline the compliance process. While any form of access control comes with a degree of complexity, RBAC is transparent enough that you can see how individuals interact with resources based on their roles. And, in keeping with the adage: “Complexity is the enemy of security,” because its setup is relatively straightforward, you can more easily control how sensitive data is accessed, which can lead to fewer breaches.

One major downside of RBAC is if your environment has a multitude of different roles, each with its own complex set of permissions, which can make management difficult. Unlike ABAC, RBAC can’t be automated, so the more complex your environment, the more manual the access management control becomes (and by that fact, more prone to errors).

Next steps: resources

As with any security measure, it’s important to evaluate the needs of your organization when it comes to access control, choosing the model which lets you best fulfill the principle of least privilege without hindering business operations. We hope this breakdown was helpful in terms of understanding the differences between RBAC and ABAC! This post was by no means exhaustive, so we’ve included a list of resources and FAQs below, including resources on how to implement RBAC with Sensu.

What types of access control have you found work best in your organization? Let us know in our Community Forum, below!

Resources:

• Our guide to securing Sensu 101, including best practices for secure monitoring
• The Sensu documentation on role-based access control
• [Blog post](https://sensu.io/blog/intro-to-rbac-in-sensu-go](https://sensu.io/resources/webinar/introduction-to-rbac-in-sensu-go) on RBAC in Sensu Go
• Whitepaper on the 5 essential security features for monitoring

FAQ

What are the 3 types of access control?

Three types of access control are attribute-based access control (ABAC), role-based access control (RBAC), and discretionary access control (DAC).

What is ABAC policy?

ABAC is an access control policy based on attributes, which can be assigned based on user role, department, device used to access the asset, and much more.

What are the object attributes of ABAC?

The object attributes of ABAC can range widely, including the individual user’s role and team, devices used to access resources, IP addresses, and more.

What is the RBAC model?

RBAC is an access control method based on individual roles. You assign permissions (such as read, write, execute) to a role (such as “engineering”) and that dictates whether an individual can access a resource (and what they can do once they access it).

What are the three primary rules for RBAC?

The three rules for RBAC, as defined in this Wikipedia article, are:

1. Role assignment: a user has to be assigned a role to exercise permissions associated with that role.
2. Role authorization: tied to the rule above, users must be authorized to take on certain roles.
3. Permission authorization: tying all three rules together, a user must be authorized to execute certain actions, based on the permissions associated with their role