Replies: 2 comments 1 reply
-
I agree. If you don't trust your users and you require proper isolation, you will need separate instances. Many objects do have a direct relation to tenant (including IP address and prefix), but some things are indirect (e.g. interface > device > tenant), and some not at all or very hard (e.g. cable: you'd have to go termination > component > device > tenant, and there are many different types of component it could connect to, at both ends) Even if you can control read access to a sufficient degree, allowing create and edit access is fraught. Like you say, one specific problem is being able to create IP addresses only within a prefix belonging to the tenant; there's no direct relationship between IP address and prefix. |
Beta Was this translation helpful? Give feedback.
-
Is there any plan to implement proper multi tenancy support for ALL objects in a future version? I would love to use netbox for all our customers, but having the ability to restrict access on a tenant-level is an absolut MUST for us. |
Beta Was this translation helpful? Give feedback.
-
We run a netbox instance for a service provider. We can segregate the data by assigning devices, VMs and even VDCs to different tenants and it is all good, although I wish for the matching of networks to other networks or IPs to networks the tenant would be considered and not only the VRF. But that is a different story.
The problem that I am facing is that different teams support different customers. This could also have legal reasons or cause by regulations. And we have been asked to ensure that a team has only access to data from tenant they are supposed to.
The only proper way to do this seems to be having a dedicated instance per tenant at the end.
I have tried to use Constraints, but as not all objects have a direct relation to tenant this seems to be limited.
Beta Was this translation helpful? Give feedback.
All reactions