Get Puppet Enterprise First 10 nodes are free!
Try it now
Request a demo
Automate IT and infrastructure, manage complex workflows, and mitigate risk at scale.
Try the full-featured Puppet Enterprise for free on 10 nodes.
Puppet Comply Find and prevent compliance failures
Compliance Enforcement Modules Remediate to stay in compliance
Continuous Delivery for Puppet Enterprise Build, test, and deploy infrastructure as code faster and easier
Content & Modules Pre-built scripts to automate common tasks
Find thousands of component modules built by the community and guidance on using them in your own infrastructure.
Visit Puppet Forge >>
Open Source PuppetPerfect for individuals and small infrastructure
BoltAutomate tasks in orchestration workflows
See all open source projects >>
Contribute to open source projects >>
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:
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.
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.
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.
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.
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.
Next, you’ll repeat these steps to add nodes to the development group.
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.
Now click Add permissions, and then click the Commit change button.
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.
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
This blog was originally published on May 16, 2016 and has since been updated for accuracy and relevance.
Associate Technical Writer, Puppet by Perforce