Feature #25448
closedMake Puppet classes and their parameters taxable
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.
Updated by Ondřej Pražák about 6 years ago
- Blocks Feature #25313: Full multitenancy support added
Updated by Ondřej Pražák about 6 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
Updated by Ohad Levy about 6 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
Updated by Marek Hulán about 6 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?
Updated by Marek Hulán about 6 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.
Updated by Tomer Brisker about 5 years ago
- Status changed from New to Rejected
This is by design and not expected to change in the near future, closing.