homeblogpuppet enterprise rbac api or how to manage access to tasks

Puppet Enterprise RBAC API, or how to manage access to tasks

RBAC is great, but I’m tired of clicking!

Puppet Enterprise (PE) role-based access control (RBAC) is great because it allows you to manage access to tasks with groups or individual users and nodes. But what if your organization is growing, or your use of Puppet is expanding? What if you want to take advantage of agentless tasks and there are just too many users and systems? What if different teams are managing permissions, lists of users and nodes, and writing tasks? The PE RBAC API can help.

Freeing you to do what robots can’t

PE has a new API to enable you to control access to Puppet Tasks. You can interact with this API through your scripts or code, or integrate with other systems, enabling you to make changes without having to interact with the PE console. Maybe you want to divide up task development and role management. Perhaps you want to include RBAC access to systems that are created and destroyed frequently in containers or the cloud. Now you can! Follow me down the rabbit hole and see.

To pull our example together we will be enabling web devs to restart web servers on web server nodes in our infrastructure. Roles and permissions for users to call these APIs are outside the scope of this article.

Thus begins a series of steps (divide and conquer!)

Homework! In order to use our API, you will need to locate the required services in your infrastructure1, have a tool for web requests (and maybe working with JSON)2, and you will need an authentication token:


Docs: Puppet RBAC POST /auth/token endpoint

First things first: User groups and node groups need to exist before the rest.

User groups come from LDAP or whatever external directory you are using. We will need the name of this group, e.g. ‘Web Devs’. Node groups (we will call ours ‘Web Servers’) can be created with this API call1:


Docs: Classifier POST groups endpoint

Subtasks FTW! Hand these out to your team like party favors!

These steps can all be done separately with a few ordering requirements. The core of this is the task-target. This is a data structure that enables you to connect nodes or node groups and tasks. Then you can create roles to allow users or user group members to execute these tasks on the targeted nodes.

Now separately (task-target must exist before roles are created, and nodes must have a name before they are added to a group, but they don’t have to exist yet), you can:

  1. Find or write a module that has tasks and include it in your PE installation3 (e.g. https://forge.puppet.com/puppetlabs/apache/tasks#task_init). We will be using the built in ‘service’ task.

  2. Create or update a ‘task-target’ (this is our unit of permissions in our RBAC API):


Docs: Puppet orchestrator POST /command/task_target endpoint

  1. Create a role that controls permission to execute the task-target:


Docs: Puppet RBAC POST /roles endpoint

Note: %CAUTION% Permissions to create this role require ultimate permissions (think “root”) on your PE console, so this operation should only be performed by your PE Administrator. It does have to be done after your task-target is created. Currently there is no way to modify or delete a task-target, but you can remove its associated roles. Also, this needs the task-target ID, so that has to be created first.

In this simplified example, the permissions are set for a user id for testing. In a more realistic environment, the UUID of one or more user groups would be in the currently empty argument: “group_ids”:[]

  1. Add a node to our inventory:


Docs: #post_command_create-connection

Note: most API calls will refer to this system by its certname: rabid-chairman.delivery.puppetlabs.net

  1. Add (“pin”) a node to a group:


Docs: Puppet Classifier POST /groups/pin endpoint

Note: The node does not have to be in inventory before it is pinned to the group, but its certname has to be known. Also, there are many other ways the classifier can include a node in a group3.

Everything (should be) ready!

Permissions can be checked with this API:


Docs: #get-permittedobject-typeactionuuid

And finally, users can even use an API to execute the task:


Docs: Puppet Orchestrator POST /command/task endpoint

Tying everything up!

Congratulations! You have the tools to start automating the management of your RBAC in detail. You can divide this effort into teams as you find appropriate, and there is flexibility in the order of these tasks, reducing bottlenecks, scheduling, and handoffs. Instead of clicking, you can create automation that works with your flows and teams.

For more info

API documentation and examples can be found in your PE documentation, e.g. https://puppet.com/docs/pe/latest/pe_user_guide.html For example, you can find RBAC API details here: https://puppet.com/docs/pe/latest/rbac_api_v1.html

1 Your Puppet administrator will be able to point you to your PE host. If you need help finding port numbers, typically a configuration file here will have values, or ask your admin: /etc/puppetlabs/console-services/conf.d/console.conf

2 Tools used:

3 https://puppet.com/docs/pe/latest/grouping_and_classifying_nodes.html


  • Get more information about what curl sends and receives with ‘-v’
  • See the body of what you post with curl with ‘--trace-ascii /dev/stdout’