Discovery rule needs to have exactly the same 1:1 organisations/locations assigned as the hostgroup used.
Should be enough for discovery rule to exist in a subset of hostgroup taxonomies.
Foreman and Proxy versions:
Foreman and Proxy plugin versions:
Other relevant data:
Please consider this scenario:
- hostgroup X assigned to locations A, B
- user Y assigned only to location A
- user Y creates discovery rule Z pointing to hostgroup X
ERROR, because user Y does not belong to location B (cannot assign and generally has no idea about it)
ERROR app : Failed to save: Locations Host group location LOCATION must also be associated to the discovery rule
Hey, yes this was implemented because of CVE-2015-3199 (Bug #10469: Auto provision rule does not enforce host group association to org/location - Discovery - Foreman). If we won’t do this, users are able to create rules which can provision hosts in any organization or location allowed by a hostgroup. This is an authorization problem.
We are open to suggestions, it does make sense to allow it however it’s safer to be more strict. You can always create special rules/hostgroups to workaround this limitation.
Now I can understand the security inconsistency . Let me share the use case.
Most of our users have just one location accessible. It sorta reflects the business structure.
Currently, we create product_release/location hostgroup per every product_release per every location involved in product. Then, users do whatever they want via discovery rules limited to their location.
It feels a bit overkill, cause there’s no difference between product_release/a and product_release/b other than taxonomies (extra DB complexity too).
We would like to allow developers to collaborate easier using hostgroups: share hostgroups between locations. So the developer could say to his partner in another location “check out my setup at product_release/my_setup” – withouth asking admin, worrying about taxonomies and all that.
An external batch job runs periodically, enforcing hostgroup-location assignment via regex and API calls.
It all works, but we still hit the wall against this limitation.
Would it please be possible to make the ‘strict’ mechanism switchable in some way? The flexibility benefits would be immense.
The UI still constraints all users, so the security fallacy doesn’t really scream to anybody’s face.
Thank you for your engagement and sorry for the reply lag (vacation).
I wanted to edit the previous post, but took too much time.
What I end up with:
Hostgroups are shared (taxonomies), but get useless in combination with discovery rules. It’s still possible to take existing host, change hostgroup and ‘Rebuild host’. It is some workaround, but the discovery magic goes away… All pretty confusing for an average user.
Better to hide discovery rules from the regular users completely at this point.
Adding another setting is a failure and inability to design things properly. We try hard to decrease amount of settings we have, we already struggle with many possibilities and combinations and it’s pain to support. Do you have any other idea?