Role-Based Access Control (RBAC): Security Benefits + RBAC Examples for Automated Access Management

Role-based access control (RBAC) is a way to secure IT systems and networks by limiting access to roles that can be assigned to individuals and groups of users. It makes sense for just about any IT team. After all, not everyone needs access to everything in a system, right? Different roles have different responsibilities, and those responsibilities require access to different things. RBAC makes sure that only the users who need access to certain services and resources have it.

But as straightforward as that sounds, role-based access control can get pretty complicated. For example, when roles need to change, or when individuals request access that’s outside their assigned role, RBAC needs to account for that.

Fortunately, well-instituted RBAC supported by strong tools can handle those cases – and even automate the granting and revocation of access at scale in enterprise IT. Read on for an overview with role-based access control examples, benefits, and automation tips.

What is Role-Based Access Control (RBAC)?

Role-based access control (RBAC) is an IT security model that restricts access to systems and networks based on a user’s role in an organization. RBAC is popular for access control at scale because it allows for grouping of users with similar roles.

With role-based access control, each user of an organization’s IT system is assigned a ‘role’. That role defines the permissions and access that user has, including actions and operations they can and can’t perform. Individual users can be assigned multiple RBAC roles to enable a finer level of control over access permissions.

Role-Based Access Control Examples

RBAC examples include roles that enable tasks necessary to job functions. For example, a SecOps RBAC role might include security auditing permissions, while a network admin role could include access to network configurations and monitoring.

RBAC Example: Jen in IT

For a more specific example of role-based access control, consider Jen. Jen is an IT employee whose role is a little nebulous (shocker). They do a lot, but mostly, Jen’s tasks are focused on network admin and database management.  

Jen can be assigned both Network Admin and Database Manager roles, which will give them permission to perform the functions associated with both jobs. Jen’s Network Admin role lets them do stuff like configure routers, firewalls, and VPNs, which database managers don’t have permission to do. And because Jen has also been assigned a Database Manager role, they can also do data backup, recovery, installation, security, and migration – which network admins don’t have access to.

Jen’s dual role is a great example of RBAC in action: They have access to the different tools and functions they need to perform both of their primary roles. But while we’re here, let’s take this RBAC example one step further. Imagine Jen’s role changes a bit, so they’re doing a lot less network administration and more database administration (DBA). Oh, and they’ll be doing IT security, too. (Seems like Jen’s got a pretty wide IT ops skill set. Good for Jen.)

Here’s how Jen’s RBAC example roles will need to change to reflect their new responsibilities:

• Jen’s Network Admin role will be revoked, removing the access and permissions they had for completing network admin tasks.
• Jen’s Database Manager role will be changed to a DBA role, which includes additional database management functions like query optimization and user access control.
• Jen will be assigned a new SecOps role, which lets them perform tasks like audits, incident response, and vulnerability assessments.

While that’s just one hypothetical example of role-based access control, there can be hundreds or thousands of users like Jen in an organization. You can imagine how RBAC makes managing access easier.

With RBAC, admins know what access users have and can quickly assign and edit roles, and the users themselves can continue accessing the things they need to do their jobs without friction. Then, they can group Jen in with other users on their team who have similar roles and apply broader rules to that group, simplifying access management at an even bigger scale.

The Security Benefits of Role-Based Access Control

Role-based access control reduces the risk of unauthorized users accessing sensitive systems and data, which can prevent mistakes and security vulnerabilities. RBAC also helps organizations meet internal and external IT compliance policies.

RBAC boasts a lot of benefits for IT teams, like efficiency, simpler user management, and scalability. But one of its primary use cases, and one of the ways it’s easiest to prove the value of limiting access to roles, is in ensuring system security. Here are a few security benefits of RBAC:

• Reduced risk: Because RBAC limits a user’s access to just the permissions they require to do their job, it makes it a lot harder for a user to make mistakes and errors. It also simplifies the task of removing user access when a user leaves the organization. It’s more than good housekeeping. Unattended roles and profiles are incredibly dangerous, and it’s very easy to miss when someone’s abusing them. If someone gains access via an old profile, they may gain unsanctioned access to systems and information. In auditing access controls, our own experts have discovered profiles for users that had retired (or even passed away) years before.
• Scalable access control: With RBAC, users can be added and removed from certain roles, rather than having to tweak each individual’s permissions. Users can also have multiple roles (like Jen and their dual DBA and SecOps roles), so no users are excluded from the RBAC policy.
• Compliance: Regulatory requirements and security compliance frameworks often require proof of access. Auditors like RBAC because it shows that user access is aligned to job responsibilities, and that people who don’t need access to certain resources don’t have it.

Learn How Puppet Enterprise Can Get You from "Zero" to "Zero Trust" GET THE WHITE PAPER

Implementing + Automating RBAC

Role-based access control can be automated by using an IT automation tool or custom scripts, integrating with identity management tools, and leveraging relevant resources and databases like HR.

In its most basic form, RBAC automation comes down to three main components: A source of data about roles to be assigned; a source of data about people who can hold those roles; and an automation tool to assign, update, and revoke roles.

Role-based access control implementation can get very complex at scale, but to get a little more specific, here are some tips for automating RBAC:

• Define roles and the permissions each role needs. RBAC automation starts with a standardized, documented record of the permissions and access each role should have.
• Use an identity and access management (IAM) tool. IAM tools are a type of security automation tool that centralizes and maintains user accounts and attributes. Your RBAC relies on the user roles and permissions outlined in an IAM tool. Examples include CyberArk, Solar Winds Access Rights Manager, Okta, Auth0, Azure Active Directory, LDAP, SailPoint IdentityIQ, Ping Identity, and more.
  • Integration with IAM also permits admins to grant or revoke access based on a user’s role or employment status. Updates can sometimes get put on the back burner when the IT staff are overworked, resulting in users having incorrect or inappropriate access. That can be both frustrating to the user and dangerous to the organization.
• Automate with IT automation tools and scripts. Automation tools and custom scripts can automate user provisioning, assign roles to users, and permissions updates when those roles change. When integrated with other data sources like human resources (HR), automation can even make sure roles are updated or removed when a user’s job status, roles, and responsibilities change.

How to Use Puppet Role-Based Access Control

RBAC is one of Puppet’s many use cases. You can use Puppet as the engine of your RBAC automation by integrating Puppet automation with your IAM system to deploy your RBAC policies automatically. Puppet can automate role assignment, permissions changes, and role removal as needed.

Puppet Enterprise also comes with RBAC built in. RBAC in Puppet helps organizations manage access to Puppet infrastructure code as well as Puppet-managed servers and other resources. With Puppet, admins can define Puppet roles with specific permissions, like modifying configuration files and accessing nodes, and grouped for efficiency. Puppet Enterprise RBAC also integrates with LDAP and AD services to streamline user management as part of your RBAC policy.

To make things even easier, Puppet’s built-in roles include Code Deployers, Node Managers, and Operators, covering common Puppet responsibilities. Of course, you can also create custom roles to make sure users have exactly the access they need – no more, no less. And it’s all manageable right from in the Puppet Enterprise console.

In fact, higher levels of Puppet automation can increase system security by reducing the number of users who need access roles to a system. More automation means fewer manual interactions with a system, which minimizes attack vectors across infrastructure and can improve overall system security. That degree of automation also reduces the time and effort it takes to configure and deploy and manage resources, which increases efficiency while reducing risk.

How to Set Up RBAC in Puppet Enterprise

As mentioned, RBAC is built into Puppet Enterprise, so you can define a user's level of access from the Puppet Enterprise console. So while you're here, let’s walk through a sample RBAC setup to see how it works in Puppet, using Monty Python characters as examples. (Because why not?)

In this simplified demonstration, we’ll give a video game development team (Arthur, Robin, Lancelot, and Galahad) the ability to make changes on the Puppet-managed development servers associated with their work on Grail Quest III: We’ve Already Got One. As per their company’s policy, we’ll also grant the team the ability to view all the production servers associated with their work.

Let's get started with role-based access control. 

Step 1: Create Two Node Groups

To begin, set up a classification node group that holds all the development and production nodes associated with Grail Quest III. This node group defines the boundaries of dev server access. The team won’t be able to access any servers outside the segment you define here.

1. In the PE console, select Node Groups in the main menu, then click Add group.
2. Specify options for the new classification node group:

• Parent name – Select All Nodes.
• Group name – Enter a name that describes the purpose of this node group. In this case, “Grail Quest Servers.”
• Environment – Leave "Set to Production."
  d. Environment group – Do not select this option.

3. Click Add.

Next, create a node group that will nest below the node group we just created. This group will contain only the development nodes that the team can change.

1. Specify options for the new classification node group:

• Parent name – Select Grail Quest Servers, which will be the parent to this node group. Classification node groups inherit classes, parameters, and variables from their parent node group.
• Group name – Enter “Grail Quest III Development.”
• Environment – Leave "Set to Production."
• Environment group – Do not select this option.

3. Click Add.

Step 2: Place Servers in the Groups

Our node groups are set up, but they’re empty! We need to fill them with the appropriate nodes. Let’s begin with the server group.

1. Select Grail Quest Servers.
2. Click the Rules tab.
3. Add a rule. To set up the server group, we’ll dynamically add the three production servers (shrubbery1.grailquest.com, shrubbery2.grailquest.com, and shrubbery5.grailquest.com) and the two development servers (coconut0.grailquest.com and coconut1.grailquest.com) to the node group by creating a rule: select clientcert as the fact and matches regex as the operator; enter “grailquest.com” as the value.
4. Click Add rule and then click the commit button.The Grail Quest Servers group’s Matching nodes tab now contains the five servers.

Next, you’ll repeat these steps to add nodes to the development group.

1. Select Node Groups from the main menu, and select Grail Quest III Development.
2. Click the Rules tab.
3. Because the development group is a child of the server group, it inherits the clientcert matches regex grailquest.com rule you created for the parent group. To further narrow down matching nodes, add a new rule: select clientcert as the fact and matches regex as the operator; enter “coconut” as the value.
4. Click Add rule and then click the commit button. The Grail Quest III Development group’s Matching nodes tab now shows coconut0.grailquest.com and coconut1.grailquest.com.

Step 3: Create a New User Role and Add Permissions

This is the heart of role-based access control. We’ll now create a role for the developers that grants them the ability to change development servers while maintaining view-only access to production servers. When we’re done, the devs won’t have access to any servers outside their segment, the Grail Quest Servers group.

1. In the console, click Access control and select the User Roles tab.
2. In the Name field, enter “Grail Quest III Developers”, and then click Add role.
3. Click the newly created Grail Quest III Developers role.
4. Click the Permissions tab.
5. Use the Type - Permission - Object controls to select the permissions your developer group will have in PE. In this case, we’ll assign our developers the following permissions:

Now click Add permissions, and then click the Commit change button.

Step 4: Bring Out Your users

We need to give our four developers access to PE and assign them to the new user role. It’s easiest to provide user access to Puppet Enterprise by connecting PE to the directory service you’ve likely already set up for your organization. See the LDAP section of the PE docs for more information on integrating PE with your directory server.

In the external company directory you’ve connected to PE, an established Knights of the Round Table user group contains login information for Arthur, Robin, Lancelot, and Galahad. If you click Access control and then select the User Groups tab in the PE console, you’ll see Knights of the Round Table listed.

1. Assign the newly created developer role to the developers. Select the User roles tab, and then select Grail Quest III Developers.
2. Click the Member groups tab. In the Group name drop-down list, select Knights of the Round Table.
3. Click Add group, and then click the commit button.

That’s it! You’ve now explicitly defined which servers the four developers can see and access, and given them the specific user permissions they need to do their work on those servers (and only those servers). The development team can now sign into the PE console with their existing credentials and start making changes to their development servers — changes they previously would have brought to the admin team. Now both teams can work far more efficiently.

See Puppet in Action or Try It Today

Need to set up an RBAC strategy? Need a stronger automation solution to power your existing IAM? Want to see how RBAC works in Puppet Enterprise? Get a demo or try Puppet Enterprise free for yourself.

DEMO PUPPET   TRY PUPPET

Learn More

• How to connect Puppet Enterprise to Okta using SAML
• How to authenticate Puppet Enterprise with FreeIPA LDAP

This blog was originally published on May 16, 2016 and has since been updated for accuracy and relevance.