Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Automate the Bridgekeeper: Using RBAC to Safely Delegate Access

DZone's Guide to

Automate the Bridgekeeper: Using RBAC to Safely Delegate Access

RBAC enables self-service server access, removing the burden from your admin team while ensuring that mission-critical production nodes are protected.

· DevOps Zone
Free Resource

Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.

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

The Bridgekeeper from Monty Python and the Holy Grail

The Bridgekeeper, played by Terry Gilliam, Monty Python and the Holy Grail

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.
    • 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. 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.
  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. 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.comrule 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:
Type Permission Object
Console View -
Node groups View Grail Quest Servers
Node groups Create, edit, and delete child groups Grail Quest III Development
Node groups Edit classes, parameters, and variables Grail Quest III Development
Node groups Set environment Grail Quest III Development
Puppet agent Run Puppet from the console -
Puppet environment Deploy code Development

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 that 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 that the four developers can see and access and given them the specific user permissions that 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.

Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure, brought to you in partnership with Sauce Labs

Topics:
RBAC ,bridgekeeping ,puppet

Published at DZone with permission of Mindy Moreland. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}