What are Role-Based Access Control (RBAC) and ACL (Access Control Lists) and how are they used?
RBAC (Role-based Access Control)
A real world analogy to RBAC- all authorized sports personnel can enter the basketball team locker room, but only the players can put on the jerseys.
How is this analogous to RBAC?
Security
A primary goal of RBAC, or Role-Based Access Control is security. It’s at the level of authorization after authentication; once a user is authenticated (logged in) and is allowed access to a resource (like a database, or locker room), without authorization she could do anything she wanted with that resource. Like delete the database, or try on all the jerseys.
But if there is some way to manage authorization, then the options of what can be done to a resource is limited. I.e., a person who is roleA can view and edit all documents in a database, but cannot delete. Another roleB will be able to view all and edit all and delete all.
This is important from a security perspective since if a bad actor gets into a resource, we can limit the damage she can do. In our basketball analogy, it’s like locking the jerseys up with an additional key that only players have. Role B— players- can access and put on the jerseys. This limits the damage done by a bad actor who uses a trainer’s pass to get into the locker room — at least the bad actor cannot touch the jerseys, since the bad actor does not have the key to where they are locked up inside the locker room. This is what RBAC lets you do; control the access of a resource based on the role of the person or application accessing that resource.
Error prevention
Another use case for using RBAC is error prevention. Say the human user accessing a resource has the best of intentions, but mistakenly deletes important unrecoverable data. Or executes a heavy command that hurts a production environment. It is possible to use RBAC to prevent these mistakes.
Data privacy and compliance
A third use case of why RBAC+ACL is implemented is for regulatory compliance. Sensitive information must be limited to only those who are permitted access. This too can be achieved via RBAC+ACL.
How can RBAC work?
Define roles and access per role, then assign users to roles.
Roles — who will have access?
Access per role- Probably a super/system admin needs full access to all. Other roles may need more restrictive permissions. The resolution of the access here can differ. It can be for entire resources, or it can be for specific parts of the resource, or even particular actions on specific parts of the resource. As on the entire resource:
In this example, Roles A and C have access to resource A, but role B does not.
Greater granularity is possible:
In this example, maybe roleB is a human user, and you don’t want her to mistakenly delete the entire resource (like a database). So you can grant her access to READ resource A, but limit her access so she can’t modify resource A. This is already one step into access control lists, but let’s wait for it.
Users to roles — Now that we have Roles and access control per role, we need someone to use them. So, for each user we assign at least one role. MongoDb supports multiple roles per user:
Others like Redis Enterprise does not offer this functionality of multiple roles per user (at least as of writing this post).
Implementation
How in practice is RBAC implemented? Usually programmatically like through CLI. Some services or products also offer a user interface to manage this. Here is a screenshot from the documentation of a company called Aerospike explaining how to implement RBAC via cli:
ACL — Access Control Lists
Now let’s have a look at access control lists. These are used to provide more granularity and sophistication by limited access to particular keys, commands, or key-command pairs. For an example on keys on a particular database, where resourceA is a database:
Here we have three different ACLs: (1) read-only for specific keys has been applied to roleA on resourceA, (2) no access has been applied to roleB for resourceA, and (2) read-only on specific keys and write on other keys has been applied to roleC on resourceA.
This is a small example but imagine if the key-command pair lists are longer and even more involved. More sophisticated commands, more specific keys, more complex key-command combinations. You need a way to take this lists of access control logic, and easily apply it elsewhere. Say you want to take these ACLs (1,2,3) and apply them on a different resourceB, say a different database. Do you have to rewrite them all? ACL (access control lists), once defined, act as a group and can easily be applied elsewhere. Like this:
Without having this entity of an ACL, after setting access control logic per role on resource A, the admin would have to manually repeat the access control logic when she applies it on resource B.
Pain points in using RBAC and ACL
In my research, I have found a few challenging points.
Changing needs per Environment
In a development environment, there is less risk, so developers expect to have fewer restrictions so they can focus on the development, and not get ‘bogged down’ by dealing with access control issues. Contrast this to a production environment where naturally you need all the access control in place. Approaches to solving these are either short term or long-term thinking: if it’s short term, then the system admins tend to let some services use roles with higher permissions. This causes problems later on, in pre-production and production environments, when the temporary higher permission roles are removed. In the long term solution, the access control levels anticipated for production must also be implemented in the development and pre-production environments. Getting this right earlier causes more upfront work, so hurts velocity of time to deliver. But in the long run, it sounds like the wise thing to do.
Central control vs. developer freedom
This is a lait motif in mid-size to large organizations. In the centralized setup, it is a select group of devOps or security officers who should always be overseeing and granting privileges. This provides more control and oversight, but sometimes can be a bottleneck. On the decentralized/developer freedom, each team or unit can set the privileges in their own domain. This may threaten the authority of those responsible for security in the organization, but with the proper tools and visibility given to the overall admins, I personally believe this can be supported.
Inconsistency of RBAC + ACL between services
Looking at the terminology and functionality of RBAC+ACL across services (like AWS to openshift to redis to MongoDb etc), one can notice gaps and clashes in the functionality offered and in the mechanism of implementation. This makes it hard for admins to implement RBAC + ACL consistently across a complex tech stack that probably uses a mix of solutions & services, each that require to define RBAC+ACL anew. Here, too, I wager to guess that in the future there will be some kind of solution that offers ‘translation’ of RBAC+ACLs from one service to another.
Identifying what should be protected
It’s not easy to configure efficient RBAC + ACLs that protect against security issues and prevent errors. Resources like dBs change, both human users and application users move in and out of roles, roles change — all through the development process. Keeping up to protect resources is a formidable challenge. It is my contention that a solution can be developed to solve this problem — to identify sensitive keys that should be protected but are not, or to identify commands that are allowed in production environments that pose a risk.
Thanks for reading.
About the author
I’m a UX Designer turned Product Manager, with experience in startups, freelance, and agile B2B2C companies. Writing helps me reflect & continuously learn. Connect with me on Twitter.
References
This article by Tommer Amber helped me understand pain points in using RBAC + ACLs. Thanks!
This article helped particularly with ACLs.
Francois from redis youtube video is great.
