I recently researched the permission model, and after reading AWS IAM, I feel that AWS IAM is very well designed. In my personal opinion, RBAC is still not enough for some scenarios, mainly because the control granularity is not enough. For example, I want to control a role can only operate the resources of a certain cluster, RBAC can not express, but ABAC can express, but ABAC is much more complex, AWS IAM is ABAC, but ease of use is very good. There is another way to modify the RBAC, by adding a condition to narrow down the permissions, so as to achieve fine-grained control.

This is actually a permission model that combines RBAC and ABAC. However, let’s start from the beginning and go step by step.

There are many permission models, and Wikipedia alone lists 12 of them. Let’s pick a few.

ACL(Access Control List)

ACL means that for each object, we keep an access list, for example: /home/jiajun/.vimrc allows users A, B and C to access it. We store these, and when checking permissions, we check the list in turn to see if there is a corresponding user, so that we know if the user has some kind of permission to an object.

MAC (Mandatory Access Control)

MAC has a lot of explanations, but not many of them are very clear. MAC is a little bit similar to ACL, but the difference is that MAC sets a security level for an object, and when checking permissions, it checks whether the user has the corresponding identity level, and if so, access is allowed, otherwise access is denied.

In addition MAC will also have the concept of permissions, for example, the person who holds the highest level of permission and also has write permission for a certain object, then the access will be passed.

RBAC (Role Based Access Control)

RBAC is a very common type of authorization, and I have done this type of system before. For common authorization, it is all about establishing a relationship between the user and the object, such as.

1
2
3

User A -> can read -> file a
User B -> can write -> file a
User A -> can delete -> file b

Such control can be done at a very fine level of granularity, but has the disadvantage that it is difficult to control. For example, for an internal system, let’s say that ordinary employees have access to 100 subsystem interfaces, and for a new employee, we need to reconfigure the permissions of these 100 subsystem interfaces for him. But with RBAC, it’s different. By introducing role as an intermediate layer, all authorization relationships are established between role and object, e.g.

1
2
3

Role A -> can read -> file a
Role B -> can write -> file a
Role A -> can delete -> file b

Then we establish the relationship between the user and the role. This way, for a new employee, we just associate him with the corresponding role and he automatically has all the permissions for that role.

However, the disadvantage of RBAC is that, after granting permissions, it is not possible to limit the granularity of permissions to a smaller size. For example, we allow user A to “delete cluster”, but on RBAC, we cannot express the operation “delete cluster 1”, that is, the RBAC cannot do this with reduced permissions.

ABAC (Attribute Based Access Control)

Attribute, that is, the various attributes of the object, including the various attributes at the time of execution. The complexity of ABAC lies here, because there are an infinite number of attributes, and determining whether permissions are sufficient based on various attributes involves a lot of judgments and rules, as well as priority handling issues. But the AWS IAM is still easy to use, and the IAM itself is more of an ABAC implementation, but with policies, user/user group/role abstraction, the whole system behaves very much like RBAC.

Summary

Through the above statement, we can see that RBAC is easy to use, simple to configure, but can not fine-grained control of permissions; while ABAC can do everything, the control granularity can be very fine, but the implementation will be very complex, but the abstraction of a better system, such as IAM, in the ease of use is also good.

I personally think that for most of the company’s business scenarios, RBAC is sufficient, if you want more fine-grained control, you can integrate RBAC and ABAC two control models, in view of the difficulty of implementation, you can consider based on RBAC, to rely on ABAC, such as the introduction of condition to narrow the permissions.