NGAC vs RBAC vs ABAC and why choose NGAC as permission control model

This article was co-written by Ignasi Barrera and published in English on TheNewStack.

Different companies or software vendors have devised countless ways to control user access to functions or resources, such as discretionary access control (DAC), mandatory access control (MAC), role-based access control (RBAC), and attribute-based access control (ABAC). Essentially, any type of access control model abstracts out three basic elements: users, systems/applications, and policies.

In this article, we’ll look at ABAC, RBAC, and a new access control model, the Next Generation Access Control (NGAC), and compare the similarities and differences between the three, and why you should consider NGAC.

What is RBAC?

RBAC, or role-based access control, takes the approach of granting (or denying) access to resources based on a user’s role in the organization. Each role is assigned a set of permissions and restrictions, which is good because you don’t need to keep track of every system user and their attributes. You just need to update the corresponding role, assign the role to the user, or delete the assignment. But this can be difficult to manage and scale. Enterprises using the RBAC static role model experience a role explosion: large companies may have tens of thousands of similar but different roles or users whose roles change over time, making it difficult to track roles or audit unwanted permissions. RBAC has fixed access rights, does not stipulate temporary access rights, and does not take into account attributes such as location, time, or device. Enterprises using RBAC have a difficult time meeting the complex access control requirements required to meet the regulatory requirements required by other organizations.

RBAC sample

Here is a Role in the default namespace in Kubernetes that can be used to grant pod read permissions.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: ["v1"]
  resources: ["pods"]
  verbs: ["get"."watch"."list"]
Copy the code

What is ABAC?

ABAC stands for attribute Based Access Control. At a high level, NIST defines ABAC as an access control method “in which a principal’s request to operate on an object is approved or denied based on assigned principal attributes, environmental conditions, and a set of policies specified with those attributes and conditions.” ABAC is a fine-grained model because you can assign any attribute to the user, but it also becomes a burden that is difficult to manage:

• When defining permissions, the relationship between users and objects cannot be visualized.
• If rules are designed to be a little complex or confusing, maintenance and tracking can be cumbersome for administrators.

When you have a large number of permissions to process, this can cause performance problems.

ABAC sample

Kubernetes originally used ABAC for access control and was configured via JSON lines such as:

Alice can just read pod in namespace foo.

 {"apiVersion": "abac.authorization.kubernetes.io/v1beta1"."kind": "Policy"."spec": {"user": "alice"."namespace": "foo"."resource": "pods"."readonly": true}}
Copy the code

What is NGAC?

NGAC, or the next generation of access control, takes the approach of modeling access decision data as a graph. NGAC enables a systematic, policy-consistent approach to access control that grants or denies user management capabilities with a high degree of precision. NGAC was developed by NIST (National Institute of Standards and Technology) and is currently used in Tetrate Q and Tetrate Service Bridge.

There are several types of entities; They represent the resources you want to protect, the relationships between them, and the actors who interact with the system. These entities are:

• The user
• object
• User attributes, such as organizational units
• Object properties, such as folders
• Policy classes, such as file system access, location, and time

David Ferraiolo of NIST and Ignasi Barrera of Tetrate spoke on the next generation of access control at Service Mesh Day 2019 in San Francisco, Shared how NGAC works.

NGAC is based on the assumption that you can represent the system you want to protect with a graph that represents the resources you want to protect and your organizational structure that makes sense to you and fits into your organizational semantics. On top of this model, which is very specific to your organization, you can overlay strategies. Permissions are defined between the resource model and the user model. NGAC thus provides an elegant way to represent the resources you want to protect, the different roles in the system, and how permissions link the two worlds together.

Algorithms to Restrict Insider Access using multi-policy Access Control Systems

NGAC sample

The following example shows a simple NGAC diagram with a user DAG representing the organizational structure, an object DAG representing files and folders in the file system, a classification of files, and two different policies — file system and scope — that can be combined to make access decisions. The associated edge between the two DaGs defines the actor’s permissions on the target resource.

In this figure, we can see representations of the two files resume and Contract in the /hr-docs folder, each linked to a category (public/ Confidential). There are also two policy classes, File System and Scope, where objects in the graph are wired — conditions that need to be met to gain access to each File.

In the example, the user Allice has read and write access to both files because there is a path linking Allice to each file, and the path grants access to both policy classes. However, user Bob only has access to the Resume File, because while there is a path from Bob to the Contract File that satisfies the “read” permission of the File System policy class, there is no path that grants the Scope policy class permission. Therefore, Bob’s access to the Contract file is denied.

Why NGAC?

In the case of ABAC, the need to track the properties of all objects creates a burden of manageability. RBAC is less burdensome because we extract access information for all roles, but this model has the problem of role explosion and can become unmanageable. With NGAC, we have everything we need in the diagram — in a compact, focused way.

When access decisions are complex, ABAC processing times multiply. RBAC becomes particularly difficult to manage in size, whereas NGAC can scale linearly.

Where NGAC really shines is in its flexibility. It can be configured to allow or disallow access based not only on object attributes, but also on other conditions — time, location, phase of the moon, and so on.

Other key advantages of NGAC include the ability to consistently set policies (to meet compliance requirements) and to set diachronic policies. For example, NGAC can grant a developer one-time access to a resource during an outage without leaving unnecessary permissions that could lead to a security breach later. NGAC can evaluate and combine multiple policies in a single access decision while maintaining its linear time complexity.

conclusion

The table below compares ABAC, RBAC, and NGAC in several ways.

To sum up:

• RBAC is simple and performs well, but it suffers in scale.
• ABAC is flexible, but performance and auditability are an issue.
• NGAC fixes these gaps by using a new, elegant and revolutionary approach: overlaying access policies on top of the existing representation of the world provided by the user. You can also model RBAC and ABAC policies.

reference

• Guide to Attribute-Based Access Control (ABAC) Definition and Considerations
• Deploying ABAC policies using RBAC Systems
• RBAC vs. ABAC: What’s the Difference?
• Role Explosion: The Unintended Consequence of RBAC
• Exploring the Next Generation of Access Control Methodologies

Author: Song Jingchao

IO /blog/ Why-Yo…