Add collectorgroupid and collectorgroupdesc standard properties
We already have collectorid and collectordesc standard properties, but in all our deployments we have at least 2 collectors.
Since in Dynamic Group custom queries you cannot use inherited properties I’d like to be able to specify the query to include resources from the collector group level rather than individual collectors (using OR / || operators), especially since provisioning a new collector to replace a previous one will generate a new collectorid and collectordesc value so the query will need to be permanently maintained.
For us at least, new collectors will always belong to a collector group, so this seems to simplify the requirement of splitting up MSP version of LM between multiple customers. The way we handle hierarchy is to add every resource to a static group, outside of any customer folder, then inside each customer folder we have a dynamic group for ‘All Devices’ looking for that customers resources.
Currently we achieve this using the API in a PropertySource to grab the resource’s collectorid value, pass that to the API and return the collectorgroupname value, then set that returned value to an auto.organisation value at the resource level. And then in the query we have auto.organisation == “XYZ”.
Using the API seems an unneeded overhead. Instead, at the point of adding resources, since they already get collectorid and collectordesc added, the Add Device process should include a lookup to get the used collector’s collectorgroup values and set them directly on the resource as collectorgroupid and collectorgroupdesc (to be consistent with the current ones).
Then in each dynamic group we can use something like system.collectorgroupdesc == “XYZ”.
LM User
·2 years agoAny updates for security on windows/powershell?
Not what I said, but it would appear some might be misunderstanding my original statement. I’m referring to the disregard Microsoft has had for 30+ years when it comes to security in their products (especially when compared to Linux). Not a comment about LM.
ldoodle
OP2 years ago(Ignore all the errors and dead devices - this is intentional to help us build out dashboards and alert rules!!)
If it helps anyone visualise, this is what we’re working with for our structure. The very top _All Devices one is where every resource gets added. Then the _Internal group sub dynamic groups have no constraint for customers so bring in every resource matching the dynamic query (e.g. “hasCategory(“Windows_DNS”)).
Then we have dashboard groups matching the resource groups and are constrained to that resource group, and again for the _Internal dashboard group there is no customer constraint so on those dashboards we see everything across all customers together.
(Our customers will have logins but to obviously only their resource and dashboard groups.)
Then the only difference for the customer sub dynamic groups is they have the additional auto.organisation = “XYZ” constraint.
_Unknown just has query where auto.organisation property doesn’t exist.
At least so far this makes adding a new customers really easy as we just create the structure and then clone all the dashboards.
The Infrastructure group I will probably split to have Applications as well, and then put SQL for example in that instead. Not sure yet.
And, actually drawing and writing this out has made me think of something else; templating resource and dashboard group structures.
LM User
·2 years agoAny updates for security on windows/powershell?
Mike Moniz
·2 years agoThis would be a major security problem if it were possible. I guess what you mean is that they might be able to decrypt the https traffic back to LM and pull the API keys out of a pcap? The only thing they could do on the box itself would be to decode the process because the tasks live in memory, not on any disk. If you were to write code that wrote content to the disk, there might be potential for leakage there, but for the most part, i don’t think this is possible. If it is, it’s only remotely possible. Perhaps LM should put out a bug bounty for someone to grab an API key or password from a collector. It shouldn’t be possible.
I don’t think it would be too hard to pull that off without going into process/memory snooping or https snooping (which isn’t that hard anyway). I believe before SSE was implemented, Logicmonitor would write the powershell script to a temp file to then run it. And even with SSE enabled (where it runs powershell in input mode), Powershell has auditing options that will log all commands used in any instance. I also think debug commands creates a temp file to run scripts in even now. Just taking a quick look at the wrapper log files I see a whole groovy script in there for some reason (looks like a poll now test task is failing on a regular basis, might look into that).
I do agree that is a bit safer with Groovy since it doesn’t embed property values directly in the script like how the implemented powershell. But I’m not really comfortable that it may never leak in some error message or log. Just our compliance officer knowing that our key would be sent to customer owned system would be problem enough. :)
I don’t think LM states that credentials are safely stored on collector. Not sure that happening would count towards a bug bounty. If I even had that kinda time, I might be tempted to try. :)
Unavailable member
·2 years agoThank you @Stuart Weenig!! Appreciate you!
LM User
·2 years agoCan I just say thank you to @A11ey for maintaining a community space where I can talk shop with people who can keep up with me?
Joe Williams
·2 years agoTo piggyback off of what Stuart is saying here. We do something very similar to his layout. Our devices are in a single static folder that our automation creates/pushes out to. Then we have dynamic folders all using the tenantid (we used to use the staticgroups contains method) to bring them into various rollup folders for reporting/etc. We continue to use dynamic folders as well for client specific requests. For example region based folders. We will create those based on a property, naming scheme, etc.
As a standard we do not run our collectors on client hardware, but in the cases we do, we scope API tokens that are needed to very specific things, but at the same time, there is a point where you just have to accept risk.
LM User
·2 years agoThis would be a major security problem if it were possible. I guess what you mean is that they might be able to decrypt the https traffic back to LM and pull the API keys out of a pcap? The only thing they could do on the box itself would be to decode the process because the tasks live in memory, not on any disk. If you were to write code that wrote content to the disk, there might be potential for leakage there, but for the most part, i don’t think this is possible. If it is, it’s only remotely possible. Perhaps LM should put out a bug bounty for someone to grab an API key or password from a collector. It shouldn’t be possible.
That said, this function allows you to specify the creds via properties, which means you can specify different creds for different groups of devices. So you could specify individual creds per customer.
You don’t have devices in multiple groups? Or you don’t have them in multiple static groups? By rule, we don’t have a device in more than one static group.
FYI Under each customer we have:
Our automation puts them statically in the last set of groups and the rest of the groups are dynamic. Living statically in any of these groups, they inherit the tenant id property from the customer group. As mentioned before, we have the propertysource to convert that inherited property into a device level property, which causes them to be added to the remainder of the groups.
However, I am intrigued at the idea of using collector assignment to indicate the tenant id. What if it were possible to specify a property on the collector or collector group and if you could toggle each property to be inherited by devices assigned to that collector?
This goes along with a different feature request i have that would allow me to specify key/value pairs that should be included in the collector config; For example, the ability to specify vault.bypass=false as a property on the collector group and let that set the value in each collector’s config.
So maybe make collector group/collector properties useful for more than collector down alerts. Just add two more columns to the group custom properties table: 1) inherited by devices assigned and 2) push to collector config. Does that make sense?
ldoodle
OP2 years agoI am interesting in your design setup as you mentioned it above
I have a thread in the Product Discussions group about it that @Stuart Weenig helped me overcome for now.
Dynamic Device Groups - constrain membership to parent folder | Community (logicmonitor.com)
We’re still early days so I have the luxury of dramatic changes with no/or very little impact.
Mike Moniz
·2 years agoWhile this is not directly related to your feature request, I am interesting in your design setup as you mentioned it above (and perhaps I should start a new thread). I know that LM does lean you towards placing all the devices in one place and really focusing on using dynamic groups, but I wonder how well that works in an MSP situation. The designs I’ve used in LM (also as an MSP), done years ago though, have the same per-customer root folders/groups but devices are static within those customers groups. Actually it’s also broken down by technology groups within the customer group (like network, server, etc). This allowed for using the staticgroups property for customer separation in dynamic groups. It also made it easier to determine the “owner” of the device if your MSP organization has a lot of people involved in monitoring. I do wonder how adding devices outside of the customer group and/or technology sub-groups works for others and what benefits it may have. I can see having devices with multiple roles in multiple groups being useful.
Also a few other things. Code from DataSources and PropertySources are always run from the collector itself. For some MSPs this may mean the code is running on collector servers you don’t fully control or are owned by your customers. So if you use API keys in this code, I always worry about it being potentially leaked to the customer. So you may want to be careful not to use a global API key that work across multiple customers. Same applies if you do some of the API hacky tricks with Dashboards if your not careful. And those might leak to the end user using the dashboard. It may help either having per-customer keys and/or using them on collector servers you have.
Also as far as I know there is no MSP version of the LM portal at a technical level (perhaps for licensing and contracts). You eventually run into various things where the design doesn’t seem to account for MSP situations, but generally you can get around them.
LM User
·2 years agoIf you haven’t already done so, please submit this directly through the product. Posting it on the community is good because users like myself will copy and paste your feature request directly into the feature request submission form in the product. However, the product team does not ingest feature requests submitted through the community, only those submitted through the product itself. Dare i say they don’t even read them?