Organization Based Permissions Filtering

Latest response

I'm configuring a satellite for use on at a university. I want to create a separate organization for each college in the university. Kicker is I need to keep orgs from changing each others stuff. What I want to do is create a role that contains the thing an org admin would need to do (create host collections, activation keys, etc) but limit these changes to items owned by the org the user is a member of.

In other words, have an Org Admin role that has create rights to nearly everything and a filter set to org = $UsersOrg.

It seems that right now all I can do is create a specific Org Admin role for each org on the satellite. That seems like it'll quickly get unmanageable.


You shouldn't need to do any filtering at all - "Organizations" in Satellite 6 are one of the few useful "object"-based permissions boundaries (almost all of the permissions are "action"-based, a design limitation which drives me bonkers). So a satellite user "John Doe" configured with access only to the Organization "Astronomy" cannot see anything (hosts, collections, products, repositories, etc.) in the "Biology" Organization, and user "Jane Doe" configured with access the "Biology" Org cannot see anything in "Astronomy". Inside Organizations, you can further isolate users & groups of systems using "Locations" (but that presents challenges to automating the host registration process, since Activation Keys cannot (yet?) set a specific Location).

The exception is if you check the "Administrator" box for any user - Satellite "administrator" permissions override all security boundaries such as Organizations and Locations. At least as of Satellite 6.2.x, you should be able to give your College-level sysadmins rights to do everything they need to do without giving them "administrator" rights (at least for Pulp/Content & Puppet-related tasks; we've avoided the provisioning features & functions in our environment due to a combination of hostile DNS/DHCP environment & mostly using VM cloning instead).

We operate in a similar universitary environment. While the organization object looked quite well suited for the separation of access rights, because there is not other suitable way do do it. But the situation is getting worse with every new feature we would like to use. Some items in Sat6 are limited by organization boundaries and restricted to exactly one organization, some can be assigned to several organizations, some are not covered at all. Using filters is no option, this would lead to hundreds of filters. Delegation still would be a problem, as your local administrators would have to fiddle around with filters. And one wrong filter and security is compromised.

There is no sharing of products between organizations. We have to sync the same stuff more than one dozend times. Physically the packages get fetched only once, but the load caused by syncs on the system is substantial, so we had to spread the organizational syncs over the 24 hours of a day to avoid congestion. The design decision how products are handled looks quite wrong, in Sat5 sharing a repo is common in our setup.

Puppet products/repositories are limited to one organization, but Puppet classes and groups are NOT. This leads to the strange effect that users in any organization see classes and groups from any organization: huge lists of classes which can be assigned to systems, but no access to the modules; users from one org can modify puppet groups from another org as long as they have the permission to work with puppet groups. A security desaster. The whole Puppet part is completely unusable, because of the security implications and the confusion and support tickets we have to expect.

The same with user groups: it is not possible to delegate the management of user groups because the are always global. Either you can manage all groups in the system, or none. Groups are unaware of organizations. Managing groups is no one job more we have to do.

I wonder if any testing without "Adminstrator" check box has been done, for example: releasing a test mail in a users email setup needs "Edit Users" permission! Obvious choice. It took hours of work in contact with RH support to find out what happened. All in all we have spent enough hours, RH should offer us unlimited Sat6 licences so we simply could install one independent satellite per organization. This would be by far the easiest option.

We need to go even further in granularity in a large governmental organization with 6500+ hosts and 23 organizations. I tried to set up a Host Collection Admin role to allow a user to view/manage only "his" systems on a host_collection level, which failed miserably. This is a feature we're using in the satellite 5 environment, and that we have come to rely on. And now we apparently can't use it any more in satellite 6.

Unfortunately we're "encouraged" by support to create an RFE to get this functionality, although it should already be available using the available (but not working) filtering.

Needed to get this off my chest ;-)