homeblogautomate bridgekeeper using rbac safely delegate access

Automate the Bridgekeeper: Using RBAC to safely delegate access

“Stop! Who would cross the Bridge of Death must answer me these questions three, ere the other side he see.”

RBAC blog post image

That poor Bridgekeeper. How does he get anything done? Every time someone wants bridge access, he’s forced to drop everything and conduct a three-factor user authentication test. No wonder he’s behind on his ornithological research.

And that’s just one bridge: what if the Bridgekeeper monitored five or 50 or 5,000 bridges, each with complex access criteria? How would he ever sort out all the itinerant knights and so-called kings, each of whom is allowed to cross only specific bridges?

You can probably guess where we’re going with this (and that we’re fond of Monty Python). It’s highly likely that your admin team spends too much time and energy on server access bridgekeeping 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 bridgekeeping process. No matter the size of your deployment, RBAC enables self-service server access, removing the burden from your admin team while ensuring that mission-critical production nodes are protected. Let’s walk through a sample RBAC setup to see how it works.

Role-based access control, step by step

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.

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, click Nodes > Classification, 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 – Select the Puppet environment that you want classes to come from. In a simple deployment, production is often the natural choice.
    d. Environment group – Do not select this option.
  1. 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. In the console, click Nodes > Classification, then click Add group.
  2. 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 – Specify a Puppet environment for filtering the classes and parameters available for selection in this node group. Let’s assume you have an established development environment where the team tests code before promoting it to production, so you’ll select development.
  • Environment group – Do not select this option.
  1. 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. Click Nodes > Classification, and 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. Click Nodes > Classification, 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 RBAC. 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 then click User Roles.
  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:
Node groupsViewGrail Quest Servers
Node groupsCreate, edit, and delete child groupsGrail Quest III Development
Node groupsEdit classes, parameters, and variablesGrail Quest III Development
Node groupsSet environmentGrail Quest III Development
Puppet agentRun Puppet from the console-
Puppet environmentDeploy codeDevelopment

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 > User Groups in the PE console, you’ll see Knights of the Round Table listed.

  1. Assign the newly created developer role to the developers. Click User roles, 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.

And there was much rejoicing

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.

As for the Bridgekeeper, he’s free to take a well-earned spam-and-coffee break, secure in the knowledge that RBAC is safely granting access and making life easier for everyone.

Mindy Moreland is an associate technical writer at Puppet.

Learn more