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.
This 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.
While 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.
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:
- _All Devices - all devices for this customer
- _Dead - all devices marked as dead. AppliesTo: system.hoststatus =~ "dead" && system.hostname !~ "invalid"
- _Locations - all sites the customer has with devices sorted by location
- Collectors - all collectors for the customer
- Devices by Practice (high level technology group like datacenter, voice, networking, security), useful for reporting
- Minimal Monitoring - same as default minimal monitoring, but filtered by customer
- Various technology groups - this is where we have groups for routers, switches, APs, windows, linux, etc.
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?
Advisor
