[dev.icinga.com #13285] Missing roles (authentication) for services

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/13285

Created by birkir on 2016-11-23 01:56:40 +00:00

Assignee: birkir
Status: Resolved (closed on 2016-12-07 09:27:17 +00:00)
Target Version: 1.3.0
Last Update: 2016-12-07 09:27:17 +00:00 (in Redmine)

---

It appears that the director/services part is missing from selectable roles for users in icingaweb, so users need full administrative access to properly use Director, and be able to add services, which is not preferrable.

Changesets

2016-12-06 23:37:35 +00:00 by tgelf 5e09753

providePermission director/*, disable unused ones

refs #13285

[icinga-migration]

Updated by tgelf on 2016-12-06 10:06:43 +00:00

• Status changed from New to Feedback
• Assigned to set to birkir

Well, there is a reason for this. Anyone allowed to manage commands can basically circumvent your restrictions, as it is hard to protect against someone able to run commands with your very own user. So, they are clearly an admin-only feature. Services are right now an all-or-nothing thing. You can assign single services to hosts according given rules (fields), but that's it for now.

There is more to come, I'd like to explain you where we want to go and hear your thoughts about it - because it's not too late to take influence on it ;-)

First:

• users granted such permissions will be allowed to assign services with apply rules
• in case those users have other restrictions, like "only hosts matching web*", those restrictions would automagically be added to their apply rules
• "apply for" would also be fine and work the same way

It's trickier when it comes to the permission to define full service templates. If I allow you to freely choose any command, I could easily forget that I created one as simple as /bin/bash x $argument$. Should not exist, but sooner or later all of us take such shortcuts. When the user is now allowed to define custom fields, he'll add 'argument' and got this way the possibility to do whatever he wants to restrictions got pointless.

We might introduce the permission to create service templates from a restricted set of service templates once again provided by you. And the permission to define all kind of fields with a big fat hint that this would probably mean indirectly making him admin. You could use this in a trusted environment where all you want is restricted visibility, but this wouldn't work out where you need hard and strictly enforced ACLs.

Given all this, could you please describe me your scenario with some more details on how you'd want your daily workflow to look like for you and your users?

Thanks,
Thomas

[icinga-migration]

Updated by birkir on 2016-12-06 18:33:41 +00:00

Sounds like you've given this a lot of thought, and mostly i only have 1 concern.

Would it then be possible to add a director/* field, so that i can allow users to create services and hosts and freely do whatever they want inside of Director? As setting them as full admins in Icingaweb2 as a whole also allows these users to mess with the Configuration tab, which in turn opens up the risk of someone being able to create and add new users to the system, or simply removing every user and causing general chaos on the system. This being the scenario i was trying to avoid.

As we are a government institute, we have limited funding, personnel and therefore time (at least i have very limited time), we are trying to make out monitoring system a mostly self-service system for other departments instead of all requests having to go through me. This would be where your lovely Director comes in. The plan is to let certain capable people in each department be able to add hosts/services as needed (and the rest of the IT department) without having to give everyone access to the Icinga machine and mess with the config files, which can be a pain to do if you aren't exactly sure what to do.

[icinga-migration]

Updated by tgelf on 2016-12-06 23:42:06 +00:00

birkir wrote:

Sounds like you've given this a lot of thought, and mostly i only have 1 concern.

Would it then be possible to add a director/* field... This being the scenario i was trying to avoid.

Sure, I pushed a fix for this. Honestly, I erroneously believed that there is modulename/* as a default option for every module - seems that I was wrong on this :D Anyways, director/* is now there. If this fixes this issue for you I'd close this ticket for now, as already mentioned there will then nonetheless be more possibilities in future.

Cheers,
Thomas

[icinga-migration]

Updated by birkir on 2016-12-07 09:26:24 +00:00

Thanks, this fixes my problem, so you may close the ticket.

[icinga-migration]

Updated by tgelf on 2016-12-07 09:27:17 +00:00

• Status changed from Feedback to Resolved
• Target Version set to 1.3.0

Glad to hear that, thank you!