Project

General

Profile

Actions

Feature #25448

closed

Make Puppet classes and their parameters taxable

Added by Ondřej Pražák over 5 years ago. Updated over 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Organizations and Locations
Target version:
-
Difficulty:
Triaged:
No
Fixed in Releases:
Found in Releases:

Description

Currently any user with Manager role can change smart class parameters from all organizations created on Foreman server. We would like to have users with access restricted to organizations.

The functionality can be misused as below:
1. Example Foreman server provides a class to manage the `root` account.
-- https://forge.puppet.com/thias/root
--- This class can set SSH authorized public keys.
2. The class is available in all organizations.
3. Org A has a user `jack` who can edit class parameters for Org A. `jack` is not a member of Org B
4. Org B has a host `protected.example.com` that is x86_64 with the `root` management class attached
5. Login as `jack` and edit the class parameters for the `root` module to add a new public key to `protected.example.com` if architecture == x86_64
6. Run puppet on `protected.example.com`
7. Notice the new public key provided by `jack` is now added to the `root` account on this host.
8. Notice `jack` is not an authorized admin for `protected.example.com`"

The existing behavior permits Org A to reconfigure Org B even if the users are not members of Org B. This can result in outages, unexpected service configurations, or possibly access to Org B servers by unauthorized users.


Related issues 1 (1 open0 closed)

Blocks Foreman - Feature #25313: Full multitenancy supportNewActions
Actions #1

Updated by Ondřej Pražák over 5 years ago

Actions #2

Updated by Ondřej Pražák over 5 years ago

  • Subject changed from Make Puppet classes and their parameters taxable to Make Puppet classes and their parameters taxable
  • Category changed from PuppetCA to Organizations and Locations
Actions #3

Updated by Ohad Levy over 5 years ago

this is going to have a significant impact on how parameters are used in foreman, and will have a fairly large user impact. IMHO WE SHOULD NOT DO THIS

Actions #4

Updated by Marek Hulán over 5 years ago

Ohad, could you please elaborate a bit more your concerns? When is it expected to have 2 organizations sharing same variables? Obviously the issue in the steps here is the expectations, that "Org A has a user `jack` who can edit class parameters for Org A. `jack` is not a member of Org B", in fact Jack can edit class parameters which can't be restricted to Org A as of today.

But if we are not implementing this, we're basically saying we will never he 100% multitenancy for configuration management. So my questions are:
1) how this affects existing users which would have single org?
2) what is the use case for users having more than 1 org today but not having smart class parameters isolated to their org?

Actions #5

Updated by Marek Hulán over 5 years ago

Also you might be interested in https://github.com/theforeman/foreman/pull/6106 which adds org/loc inheritance from environments to puppet classes.

Actions #6

Updated by Tomer Brisker over 4 years ago

  • Status changed from New to Rejected

This is by design and not expected to change in the near future, closing.

Actions

Also available in: Atom PDF