How to Use Role-Based Access Control (RBAC)

You need role-based access control (RBAC). Why?

It’s highly likely that your admin team spends too much time and energy on server access control that could be delegated, automated, or both. We know it can be daunting to segment servers and provide appropriate levels of access for teams within your organization, but failure to do so means slowing down operations and limiting your admin team’s capacity, because you’re forced to do work on behalf of others.

Puppet Enterprise’s role-based access control (RBAC) automates the access control process. Learn how.

Table of Contents: 

• What Is Role-Based Access Control?
• How to Use Role-Based Access Control (RBAC)
• Get Started With RBAC With Puppet

What Is Role-Based Access Control?

Role-based access control (RBAC) enables self-service server access. This removes the burden from your admin team and ensures that mission-critical production nodes are protected — no matter the size of your deployment.

Let’s walk through a sample RBAC setup to see how it works, using Monty Python characters as examples.

How to Use Role-Based Access Control (RBAC)

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.

Get Started with RBAC with Puppet

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.

Ready to get started with role-based access control in Puppet? If you're not already using Puppet, try it — and RBAC — today. 

START MY TRIAL

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.