Indeed "it depends". In fact it depends very heavily on which part you are trying to multi-tenant.
We are monitoring > 100 SMB networks in our installation, however we do not give our customers access to it at this time.
Templates & Policies (same thing in version 3)
We wouldn't customers access. A customer writing an auto-bind rule for "their" equipment would also apply to other customers. You would have to trust the customer to add checks for their zone (or custom attributes or whatever else you wish to use to identify a customer) into their templates. I do not trust.
If you are managing this, there is probably no reason not to apply the same templates to everyone. You can always use auto-apply rules for customer specific templates.
Mapping customers/nodes to containersAuto-bind rules allow for that. But again, I wouldn't give customers write access to that as I do not trust the customer to always do the right thing here.
Event Policy RulesAnd again, I wouldn't give customers access. There are no access controls to individual rules, you either can access EPRs or you can't. You do not want your customers to be able to mess with that. If the idea is that you're handling all of the rules, it is much easier. You can apply rules based on source objects, e.g. Zones. Make sure you get your naming conventions right so you can easily identify which rules apply to whom. You can configure customer specific settings as custom attributes on zones, containers or nodes. Or use persistent storage variables. You can script this to fit your needs.
Event StrategyYou can use the same events across your customers and apply different rules in EPRs depending on the customer. You can also create customer specific events if needed for customer specific templates. Once again, I wouldn't let customers create events.
Action StrategyYou might sense a pattern here.... I wouldn't let customers configure those, but you can set them up to deal with different customers yourself.
Basically NetXMS does not lend itself to full multi-tenancy where you can give actual administrative control over a zone to a different admin with them only being able to change their own templates, policies, rules, etc.
You can use it to give customers some level of access to their own devices. This is something you should test thoroughly. You do not want to have some area where one customer can pull data from another, e.g. via scripting or other means. You will need to setup trusted nodes, rather than assuming trust between everything. That also means newly discovered devices will need to be configured with trusted nodes. I haven't checked if that can be done via NXSL as discovered nodes are being created.
For logging, you need to enable ExtendedLogQueryAccessControl (disabled by default). It will make queries for logs slower, but it means customers won't be able to see each other's logs. However, we found a little while ago that "unknown" sources will be visible to everyone. That has been raised with the developers. Having said that, enabling UseSyslogForDiscovery and UseSNMPTrapsForDiscovery might be a workaround as it would create a new node from unknown sources. From that point onwards access restrictions would apply.
As we have not actually configured our system for this, I do not have any actual experience with that kind of setup. We simply needed a locked down temporary account one day for one particular customer and the above was what we found while doing so.
Author
Topic: Tips for multi tenant setup and configuration (Read 350 times)