Give tenant read only access

[mitch2k]

Hi,

As an MSP we have multiple tenants in our Netbox install. We want to give customers access to their own tenant so they can see their own data. This is possible with constraints. However, the keyword tenant_id is only valid for device, vlan, etc, not for example cable. This means I have to create 6 permissions for each tenant:

Name	Models	Groups	Actions	Constraints
XXX_readonly_main	dcim | device, ipam | VLAN, dcim | rack, virtualization | virtual machine, ipam | IP address, ipam | prefix, dcim | site	XXX_readonly	view	[{"tenant_id": 00}]
XXX_readonly_tenant	tenancy | tenant	XXX_readonly	view	[{"id": 00}]
XXX_readonly_devicedetails	dcim | front port, dcim | power outlet, dcim | interface, dcim | power port, dcim | device bay, dcim | rear port	XXX_readonly	view	[{"device__tenant_id": 00}]
XXX_readonly_cable1	dcim | cable	XXX_readonly	view	[{"_termination_a_device__tenant_id": 00}]
XXX_readonly_cable2	dcim | cable	XXX_readonly	view	[{"_termination_b_device__tenant_id": 00}]
XXX_readonly_vminterface	virtualization | interface	XXX_readonly	view	[{"virtual_machine__tenant_id": 00}]

Replace XXX by the tenant name. Replace 00 by the tenant ID.

I was wondering if this is the correct way. Is there a way to put this in a single constraint?

Thanks

[DanSheps]

I was wondering if this is the correct way. Is there a way to put this in a single constraint?

Nope, you got the best use of constraints right here I think.

[uRhaineWork]

If thats less of a problem You could #tag elements for customers, as tags I think are more uniwersal for components?

[bscheewe]

I'm trying to figure out if we can use Netbox in our MSP. From what I've seen on the demo site, Duplicates, parents, etc show up across regions, sites, or tenants. How can Netbox be configured to be truly multi-tenanted for an MSP that has many clients.

Sorry if I'm hi-jacking this question, but it's the only place I've seen MSP needs mentioned.

[a084ed22]

we have a similar situation of overlapping address ranges across different tenants/entities. The solution we chose is to map each tenant to a separate VRF and keep globally-unique (i.e. public address space) ranges in the global VRF.