Project

General

Profile

Actions

Feature #1652

closed

Fix privacy for puppetclasses.

Added by Brian Gupta almost 12 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Users, Roles and Permissions
Target version:
-
Difficulty:
Triaged:
No
Fixed in Releases:
Found in Releases:

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.)


Related issues 1 (0 open1 closed)

Related to Foreman - Feature #4477: Improve permissions on resources in host creation/editing formClosedTomer Brisker02/27/2014Actions
Actions #1

Updated by Anonymous almost 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.

Actions #2

Updated by Corey Osman almost 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.

Actions #3

Updated by Brian Gupta almost 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

Actions #4

Updated by Dominic Cleal almost 10 years ago

  • Related to Feature #4477: Improve permissions on resources in host creation/editing form added
Actions #5

Updated by Dominic Cleal almost 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.

Actions #6

Updated by Anonymous almost 7 years ago

I think this can get closed, correct?

Actions #7

Updated by Anonymous over 4 years ago

  • Status changed from New to Resolved
Actions

Also available in: Atom PDF