Project

General

Profile

Feature #1652

Fix privacy for puppetclasses.

Added by Brian Gupta about 7 years ago. Updated about 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Authorization
Target version:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Team Backlog:
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

Related to Foreman - Feature #4477: Improve permissions on resources in host creation/editing formClosed2014-02-27

History

#1 Updated by Jason Montleon about 7 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.

#2 Updated by Corey Osman about 7 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.

#3 Updated by Brian Gupta about 7 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

#4 Updated by Dominic Cleal over 5 years ago

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

#5 Updated by Dominic Cleal over 5 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.

#6 Updated by Michael Moll about 2 years ago

I think this can get closed, correct?

Also available in: Atom PDF