Using RBAC with Puppet Enterprise

30 minutes
  • 3 Learning Objectives

About this Hands-on Lab

Puppet Enterprise comes with many features, one of which is the role-based access control (RBAC) system that allows us to fine-tune who has access over what within out Puppet Enterprise setup. In this hands-on lab, we’ll use RBAC to set up a tiered system of access for our admins by following the “principle of least privilege” to ensure our Puppet setup is not a security vulnerability in and of itself. We’ll also create accounts for some of our users and ensure those accounts are assigned the appropriate roles.

Learning Objectives

Successfully complete this lab by achieving the following learning objectives:

Add user roles for tier 1, 2, and 3 admins

Expand the Access control menu and click User roles.

Create a role with the name T1 Admins and the description Permissions for newly-minted admins. Click Add role.

Click on T1 Admins to edit the newly-created role, then move to the Permissions tab.

Select Console from the dropdown menu. Then click Add.

Next, set the dropdown to Node groups, then select View. Set the instance to Development environment (development). Add.

Repeat the above process for the production environment.

Then, set the dropdown to Tasks, then set the instance to package. Change the permitted nodes to Node group, then set the new dropdown to Development environment (development). Add.

Repeat the above process for the service tasks.

Commit 6 changes when done.

Return to the User roles page and repeat this process for the other two admin tiers.

Create users

From the main navigation, click on Users.

Set the full name of the first user to Ollie and the login to olliep. Click Add local user.

Repeat this process until all users are added.

Add users to the appropriate role

From the main navigation, return to User roles.

Select T1 Admins.

Select Andy from the dropdown and click Add user. Do the same for Ollie.

Commit 2 changes.

Repeat this process with the other two admin tiers.

Additional Resources

Your DevOps team has begun the process of implementing Puppet Enterprise across your existing infrastructure, and part of that process has been determining what level of access within Puppet your existing admins will be granted. Your current systems administration team uses a tiered approached, with tier 1 admins being the newest and tier 3 admins having the most responsibility. After some discussion, your team has settled on a list of responsibilities each level of admin will have within Puppet. It is now your job to use this list to create user roles using Puppet's role-based access control system, then create accounts for each member of the admin team, ensuring they are assigned to the correct role.

View the following list to see what level of access each admin tier should have:

Tier 1 Admins

  • Name: T1 Admin
  • Description: Permissions for newly-minted admins
  • Roles:
    • Console: Admins should be able to view the PE console
    • Node groups: Admins should be able to view instances in the development and production environments
    • Tasks: Admins should be able to run service and package tasks against the development environment

Tier 2 Admins

  • Name: T2 Admin
  • Description: Further orchestration access and infra visibility
  • Roles:
    • All the permissions of a tier 1 admin (we still suggest reading through all requirements before continuing)
    • Job orchestrator: Admin should be able to start, stop, and view jobs
    • Node groups: Admin should be able to edit classes, parameters, and variables on all nodes
    • Puppet agent: Admins should be able to perform Puppet runs
    • Tasks: Admins should be able to run all tasks on all nodes
    • Users: Admins should be able to make reset password requests

Tier 3 Admins

  • Name: T3 Admin
  • Description: Highest-level Puppet-specific admins; can work with all nodes
  • Roles:
    • All permissions of both tier 1 and 2 admins, except without any environmental restrictions (i.e., set instances to all)
    • Certificate requests: Admins should be able to accept and reject certs
    • Nodes: Admins should be able to view PuppetDB data
    • User roles: Admins should be able to edit the membership of tier 1 and 2 admins

And here is a list of users; the name in the parenthesis is the desired username:

Tier 1 Admins

  • Andy (andyp)
  • Ollie (olliep)

Tier 2 Admins

  • Tina (tinab)
  • Louise (louiseb)
  • Gene (geneb)

Tier 3 Admins

  • Bob (bobb)
  • Linda (lindab)

To access the Puppet Enterprise Console, go to https://PUBLIC_IP, replacing PUBLIC_IP with the provided public IP of the server. The username for the console is admin and the password is pinehead.

What are Hands-on Labs

Hands-on Labs are real environments created by industry experts to help you learn. These environments help you gain knowledge and experience, practice without compromising your system, test without risk, destroy without fear, and let you learn from your mistakes. Hands-on Labs: practice your skills before delivering in the real world.

Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!

Get Started
Who’s going to be learning?