Restrict permissions to edit puppet classes and their smart class parameters which are common between multiple organizations.

Environment

• Red Hat Satellite 6.3.x

Issue

• Smart class parameters in one organization are visible to other organizations as well.
• The puppet modules/classes which are common in multiple organizations have the smart class variables visible and editable to all other organizations and their users with some specific permissions.
• Users from one organization should not be allowed to change/set smart class parameters for puppet classes from another organization. This can result in outages, unexpected service configurations, or possibly access to other organization's servers by unauthorized users.

Resolution

• This behavior is not different from that of many other resources that are shared between organizations. Some resources may be scoped to certain organizations, but they may also be shared between organizations. Other resources, such as puppet classes and their parameters, are always shared between all organizations.
  Due to this, similar issues can occur if, for example, a user permitted to edit operating systems edits an operating system (which also does not have an organization scope), or a user permitted to edit domains edits a domain (which may be shared between multiple organizations).
  In other words - changes to any such shared resource can impact multiple organizations and should be done with care.
  Organizations in Satellite are used as a method for grouping certain resources together to ease infrastructure and asset management, not of ensuring complete isolation between all resources, since in many cases it is actually very useful to share some resources between organizations. If one needs to ensure complete isolation between two organizations for all resources, one might want to consider running a separate Satellite instance for each organization.

• To resolve the specific example, users can use more specific matchers for smart class parameters to ensure they do not affect other organizations.

• In the example given, the user in org A should do the following, instead of changing the default value for the parameters:

For ensure parameter, add a matcher for "organization=Org A" with a value of "stopped".
For enable parameter, add a matcher for "organization=Org A" with a value of "false".
and similarly for the second user and so forth. 
Matchers can even be combined if needed for more complex logic, e.g. "organization,hostgroup=Org A,DBs".

• If needed, regular satellite users can be prevented from modifying these parameters directly by not granting them the edit_external_parameters permission and only allowing the satellite administrators, who have visibility to all organizations, to make such changes.

Important Note If given wrong/extra permissions to non-admin (unintended) user, it may result in unwanted/unexpected outage or services going down.

Diagnostic Steps

• Smart classes parameters can be visible, modified, and shared between organizations, and it is expected behavior, so to achieve limitation, one must assign permissions accordingly.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.