Letting non-admin users make and manage their own dynamic groups

We’ve got an environment that is maturing into a space where our SMEs are now wanting to take some ownership of their device organization and alert tuning. Part of that has butted up against dynamic group membership, but unfortunately (understandably), that can only be done by people who can manage all groups, since obviously you could just make a dynamic group under a group to which you have access whose AppliesTo is just “true()” and thus gain access to every device in the org.

We have been considering ways to facilitate access to these SMEs so that they can manage their own device groups, without giving them too much power with which they could accidentally delete or silence a bunch of devices they don’t own by a mistake in their AppliesTo logic. We’d really prefer not to just give these SMEs blanket Manage access, but we’d also like to avoid having a paradigm where they have to come to us to have every single dynamic group created for them.

We’ve been considering Terraform, granting each team access to their own static group and letting them make subgroups inside of it, and adding what is effectively an AppliesTo prepend that is “belongsToThisTeam() &&” + “whatever their AppliesTo is.” This, unfortunately, would require them to know about and remember to use whatever custom module we’d build to add that prepend. Furthermore the way parent groups are set up, we’d have little to no way to restrict them to putting their new groups under the ones to which they rightfully have access.

Has anyone else come up on these hurdles and figured out a way, or done some thinking on how to facilitate dynamic group management for specific teams without giving them the keys to the kingdom?

Dynamic group

permissions

Anonymous
11 months ago
This seems like it would be a natural evolution of LM towards using actual multi-tenancy. The FR i submitted looks like this (in case you want to copy/paste).
Inheritance of additional appliesto clause
I would like to specify a property on a parent group called mandatoryAppliesTo and have that appliesto "AND"ed to every appliesto of every dynamic group under the group containing the property.
This would simplify our current appliesto and make our standard dynamic group definitions under each customer folder identical, with the parent folder adding to each dynamic group under the customer to ensure only that customer's devices are included.
This also gives us the ability to delegate dynamic group management under customers to non administrators while ensuring they don't accidentally cross tenant boundaries.
More details and discussion can be found here: https://community.logicmonitor.com/product-discussions-22/letting-non-admin-users-make-and-manage-their-own-dynamic-groups-4073?postid=14899

tswisdom
LM Conqueror
11 months ago
Unfortunately, this comes down to the functionality of Dynamic Groups themselves. The intention is to allow a user to control membership of a group using the Applies To language, and subsequently, grants a user the ability to include any resource within a portal.

Because this naturally allows someone with permissions to manage Dynamic groups the capacity to access all resources, in order for customers to be able to effectively control user access, dynamic grouping is restricted to users with manage permissions for all resources.

With that said, it may theoretically be possible to accommodate this with “view all” permissions as opposed to “manage all”. I’d suggest submitting feedback through your portal requesting additional access control options for dynamic groups.
Anonymous
11 months ago
This seems like it would be a natural evolution of LM towards using actual multi-tenancy. The FR i submitted looks like this (in case you want to copy/paste).
Inheritance of additional appliesto clause
I would like to specify a property on a parent group called mandatoryAppliesTo and have that appliesto "AND"ed to every appliesto of every dynamic group under the group containing the property.
This would simplify our current appliesto and make our standard dynamic group definitions under each customer folder identical, with the parent folder adding to each dynamic group under the customer to ensure only that customer's devices are included.
This also gives us the ability to delegate dynamic group management under customers to non administrators while ensuring they don't accidentally cross tenant boundaries.
More details and discussion can be found here: https://community.logicmonitor.com/product-discussions-22/letting-non-admin-users-make-and-manage-their-own-dynamic-groups-4073?postid=14899
ncustis
Neophyte
11 months ago

This isn’t that different to my recent post about (default) group ‘constraints’.

What I think would be a much better approach, and I can’t see that it would be hard for LM to implement in the back end is something like this...

create a new property name specifically for this, e.g. something like ‘mandatoryAppliesTo’. You would put this on a parent static group, anywhere in the hierarchy

when you create a dynamic group inside a static group that has that property, the dynamic group implicitly includes it in the AppliesTo logic, albeit not shown in the field (to then be removed by someone rogue)

In my scenario, mandatoryAppliesTo would be auto.organisation =~ “xyz” ( xyz here is customer acronym )
In @ncustis scenario, each SME team parent static group would have the ‘belongsToThisTeam’ logic required, and then those SME teams can create nested dynamic groups

Yeah, that’s exactly what I’d like to see in a future version.
ldoodle
Advisor
11 months ago
This isn’t that different to my recent post about (default) group ‘constraints’.
What I think would be a much better approach, and I can’t see that it would be hard for LM to implement in the back end is something like this...
create a new property name specifically for this, e.g. something like ‘mandatoryAppliesTo’. You would put this on a parent static group, anywhere in the hierarchy

when you create a dynamic group inside a static group that has that property, the dynamic group implicitly includes it in the AppliesTo logic, albeit not shown in the field (to then be removed by someone rogue)
In my scenario, mandatoryAppliesTo would be auto.organisation =~ “xyz” ( xyz here is customer acronym )
In @ncustis scenario, each SME team parent static group would have the ‘belongsToThisTeam’ logic required, and then those SME teams can create nested dynamic groups
ldoodle
Advisor
11 months ago
Thinking about this some more, I wonder if a property is not the right approach. Since the SME team might also want to be able to add their own at the parent group level, which means they’d need perms to do this which means they could accidentally or deliberately remove this mandatoryAppliesTo one.
So something new, like tokens on a dashboard, should be added. Then from a perms perspective you can give access to the properties but not the tokens (or anything else like renaming the group).
The outcome is the exactly same, just a slightly different but maybe more granular approach.
ldoodle
Advisor
11 months ago

The FR i submitted looks like this (in case you want to copy/paste).

Yeap, just done the same.
Anonymous
11 months ago

This isn’t that different to my recent post about (default) group ‘constraints’.

What I think would be a much better approach, and I can’t see that it would be hard for LM to implement in the back end is something like this...

create a new property name specifically for this, e.g. something like ‘mandatoryAppliesTo’. You would put this on a parent static group, anywhere in the hierarchy

when you create a dynamic group inside a static group that has that property, the dynamic group implicitly includes it in the AppliesTo logic, albeit not shown in the field (to then be removed by someone rogue)

In my scenario, mandatoryAppliesTo would be auto.organisation =~ “xyz” ( xyz here is customer acronym )
In @ncustis scenario, each SME team parent static group would have the ‘belongsToThisTeam’ logic required, and then those SME teams can create nested dynamic groups

This would be my preference.
Mike_Aracic
Employee
10 months ago
Whatever the organizing principle of your grouping structure, it could probably be used to assign devices into static groups using the API, and the API tokens a user can have are bound to respect the roles.