Best practices for assigning permissions

Working with user permissions requires delicacy. You don't want to unintentionally escalate users' roles by granting them excessive permissions, but you also don't want to hamper them in their day-to-day duties. The following sections describe some strategies and requirements for setting permissions in Puppet Enterprise (PE).

Grant edit permissions to users with create permissions

Creating objects doesn't automatically grant the creator permission to view those objects. Therefore, users who have permission to create an object (such as roles) must also be given permission to edit the same object. Otherwise, they can't see the object they create. When you grant permission to create an object, we recommend that you also grant permission to edit all objects of the type that they have permission to create.

For example, to allow a user to create roles and also view/edit the roles they create, we recommend assigning these permission sets:

Type	Permission	Object
User roles	Create	A specific object or all objects of this type ("*")
User roles	Edit	All (or "*")

As another example, to allow a user to create user records and also see the user records they create, we recommend the following:

Type	Permission	Object
Users	Create	A specific object or all objects of this type ("*")
Users	Edit	All (or "*")

Related information:

• Structure of user permissions
• Reference: User permissions and names

Least-privilege model: Avoid overly-permissive permissions

Operators, one of the default PE roles, have many of the same permissions as Administrators. However, we've intentionally limited this role's ability to edit user roles. This way, users with the Operators role can do many of the same things as Administrators, but they can't edit (or enhance) their own permissions.

Similarly, when you're editing permission or creating your own roles, avoid granting users more permissions than necessary. For example, if users have the roles:edit:* permission, this allows them to add the node_groups:view:* permission to the roles they belong to, and, subsequently, see all node groups. Take care that permissions you've granted don't have the potential to allow a user to view or change something you don't want them to view or change.

Grant edit directory service permissions sparingly

The directory service password is not redacted when a user requests directory service settings through the RBAC API. Make sure the directory_service:edit:* permission is only granted to users who are allowed see the directory service password and other settings.

Grant reset password permissions along with other password permissions

The users:reset_password:<INSTANCE> permission allows a user to issue a password reset token to a user who forgot their password. However, this permission also reinstates revoked users when the password reset token is used. Therefore, make sure the users you allow to reset passwords are also allowed to revoke and reinstate users. Otherwise, you might have unauthorized users reinstating revoked users.