Feature #1652
closed
Fix privacy for puppetclasses.
Description
So currently puppetclasses permissions seem to be settable at the puppet_env level. I don't think this is granular enough, and would like to explicitly set a user/usergroup filter on the puppetclasses that a user/usergroup can see and tag a node with.
Really this would be most useful at the usergroup level, but filters at the usergroup level don't exist. (Am starting to think all filters should be moved to the usergroup level and if a user needs filtering, one should create a single-user usergroup.)
Updated by Anonymous over 12 years ago
I agree with Brian's comments, both about moving Filter's to the group level and being able to restrict access to the the classes users can see and assign to nodes via filters. This came up in a discussion with our group today and the feeling was that this would be a great additional feature. Users are likely to end up needing access to multiple environments, but needing access to only a subset of classes in each.
Updated by Corey Osman over 12 years ago
This would entail a few new items.
1. allow ability to filter out non authorized classes for each user when requested in the puppetclasses model
2. Build the support within the edit role view so that a admin could select which classes the role should contain.
Updated by Brian Gupta over 12 years ago
Hmm. wouldn't we do this is a filter, like we do domains? IE: The roles do not contain specific data. They just contain broad permissions, like view, edit, etc, for each type of high level collection. The user level filters contain the details, and I believe would be were you set the allowed classes. -Brian
Updated by Dominic Cleal over 10 years ago
- Related to Feature #4477: Improve permissions on resources in host creation/editing form added
Updated by Dominic Cleal over 10 years ago
- Description updated (diff)
- Assignee deleted (
Greg Sutcliffe)
Foreman 1.5's revamped authz system means you can now filter puppet classes using the search syntax and then associate this to a role instead of a user. Roles can now be assigned to user groups instead of users.
What's missing to complete this I think is #4477, which would mean our web forms can limit which associated resources you see (i.e. not the puppet classes you can't see). The difficulty with doing this right now is that if an admin user associated puppet class A to a host, then a user who can't see A goes and edits the host + adds another class, I think we'd lose puppet class A. The same goes for other resource types, like domain, proxies etc.