RBAC: Manage Permissions with Roles, Not Users
RBAC manages permissions by assigning users to roles (e.g., "editor"), not by giving permissions directly. This simplifies security in large systems like AWS IAM. The footgun is creating overly broad roles that grant excessive, unintended access.
Why it exists
Managing access control user-by-user is complex, error-prone, and doesn't scale. In any large system, manually assigning and revoking individual permissions for each person is a recipe for mistakes and security holes. RBAC was created to replace this chaotic model with a structured, manageable approach.
The mental model
Think of RBAC like job titles in a company. Instead of giving a new hire a list of every single thing they are allowed to do, you give them a title like 'Accountant'. That title implicitly grants them access to the accounting software, financial reports, and so on. In RBAC, a 'role' is the job title, and 'permissions' are the access rights that come with it. You manage roles, not an endless list of individual user permissions.
How it works
RBAC has three main components: users, roles, and permissions. A user is an individual account. A permission is the authority to perform a single action, like 'read-file' or 'delete-record'. A role is simply a named collection of permissions. The administration process is straightforward: first, you define roles that match job functions (e.g., 'support-agent', 'database-admin'). Second, you assign the necessary permissions to each role. Finally, you assign users to one or more roles. When a user tries to perform an action, the system checks if any of their assigned roles contain the required permission.
When to use it
Use RBAC as the default for any system with more than a handful of users or different access levels. It is the foundation of modern identity and access management (IAM) in cloud platforms like AWS, GCP, and Azure. It's also essential for Kubernetes, databases, and multi-tenant applications. RBAC dramatically simplifies user onboarding, offboarding, and security audits.
When not to use it
For extremely simple applications with only one or two permission levels (e.g., a public user and a single admin), a full RBAC system can be overkill. In cases where access depends on the data itself (e.g., a manager can only see reports for their own department), you may need a more granular model like Attribute-Based Access Control (ABAC), often used alongside RBAC.
One canonical example
A content management system has three roles: 'Viewer', 'Editor', and 'Admin'. Viewers can only read articles. Editors can read, write, and publish articles. Admins can do everything editors can, plus manage user accounts. When a new writer joins the team, an administrator simply assigns them the 'Editor' role. All the necessary permissions are granted automatically. If they leave the company, the role is revoked, instantly removing all their access.
Interview question
What is the primary advantage of using Role-Based Access Control (RBAC) over assigning permissions directly to individual users?
- a.It automatically determines user permissions based on their organizational department.
- b.It simplifies management by grouping permissions into roles, which are then assigned to users.Correct
- c.It allows for more granular control over individual data elements based on user attributes.
- d.It eliminates the need for individual user accounts, simplifying system administration.
Why? this is the answer
RBAC's core principle is to define roles (collections of permissions) and then assign users to these roles, streamlining the process compared to managing permissions for each user individually. Option C describes Attribute-Based Access Control (ABAC), a different model for data-dependent access.
Just read this? Test yourself on what you have been reading.
Read the original → csrc.nist.gov
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on security — each one lists the topics its interview covers.
See open roles