Permission profiles for tenants

[misch42]

NetBox version

v.3.5.4

Feature type

New functionality

Proposed functionality

Add Permission Profiles to netbox. Permission Profiles will combine several Permissions to one single profile.

Use case

If you run netbox for several tenants, you have to assign permissions based on distinct objects / models. That causes a lot of work for every tenant. Also for some models you have no tenant and you have to write an automation to allow access to these objects. i.e. interfaces of devices. Devices belong to a tenant, interfaces belong to a device.

It would be much easier to collect permissions in a profile and assign this profile to a user role. Users would have group membership and a use role.

Database changes

don't know

External dependencies

no.

[kkthxbye-code]

Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our contributing guide, a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.

I have a hard time understanding exactly what you are suggesting. Permissions can already cover multiple object types. And if that's not enough, adding multiple permissions to a group and assigning the user to that groups sounds a lot like what you are looking for. For this FR to be actionable, you'll need to be much more specific as to what you are trying to achieve.

[misch42]

A permission profile is a collection of permissions that can be assinged to a user / group. Generally it would make more sense to also create user roles as a model.

A "user group" determines to which objects a user has access. A "user role" (or permission profile) determines what rights this role has.

Example: The user group A has access to models of tenant "A". And also access to associated model (interfaces of devices of tenant A). The role "Admin" has read / write access to models. The role "Operator" has readl-on access to models.

Finally user "X" is in group A and has the role "admin". So he can read and write objects of tenant A. The user "Y" is on group A and has the role operator assigned. So he can have a look at objects of tenant A.

A user is assigned a group and a role. This determines what access rights and permissions a user has. The marketing word is Role Based Access Model (RBAC).

[kkthxbye-code]

It's still unclear to me what you actually want. It sounds like you want to just split up actions and the target object_types, but I fail to see how this would improve anything. In my opinion it sounds way less useful as you cannot give read access to to some models but read write access to other models, at least in your explanation. If you mean that roles are tied specifically to individual groups, that is, you can have different roles for each group, that can easily be achieved in the way that it works now.

Regardless, if you want a major overhaul of the permission system, as it seems like you are suggesting, the FR is not in any way specified enough for it to be accepted. I suggest you read up on the existing permission system, how it works and create a new FR with a specific implementation plan of your FR.

Suggested reading:

https://github.com/netbox-community/netbox/blob/3307bd200c38d2c548022917292c5f8db37c5541/netbox/users/models.py#L279

https://github.com/netbox-community/netbox/blob/3307bd200c38d2c548022917292c5f8db37c5541/netbox/netbox/authentication.py#L63

https://github.com/netbox-community/netbox/blob/3307bd200c38d2c548022917292c5f8db37c5541/netbox/utilities/permissions.py

Let me know if you want to update this FR with a more thorough design explanation of the proposed system or it should be closed instead.

[misch42]

It sounds like you want to just split up actions and the target object_types, but I fail to see how this would improve anything.

Imagine read access to a device and r/w access to the interfaces of that device. Now you have to enter specific permissions to user from tenant A and different permissions for users from tenant B. Imagine the work if you have 100 tenants. With user roles, you just create a role that has r permissions to devices and r/w access to interfaces and assign these roles to the users or user groups.

In my opinion it sounds way less useful as you cannot give read access to to some models but read write access to other models, at least in your explanation. Sorry if I did not explain completely. See: https://en.wikipedia.org/wiki/Role-based_access_control Basically the final user permissions are derived from two sources. The group membership that i.e. give access to models of one or more tenants. User of group A see models of tenant A. Users in group B see models of tenant B. netbox admin group users see all tenants.

Roles define what permissions are given to the user. The Admin rols has r/w access, the operator role as r/o access.

A user in group A in role Admin has r/w access to all models of tenant A. I think you get the system.

If you mean that roles are tied specifically to individual groups, that is, you can have different roles for each group, that can easily be achieved in the way that it works now. No. Roles are not assigned to groups, but users. Think of a matrix of permissions. colums: User groups rows: User roles. The user inherits permissions from the intersections of the groups and roles.

[kkthxbye-code]

I'm sorry, it still doesn't make any sense to me at all in the context of how permissions works in netbox. If you want to propose a specific implementation of RBAC in netbox, you are free to do so, but your current suggestions are not sufficiently detailed for a feature request.

If you need to workshop the idea, I'd recommend a discussion thread instead. For a major re-implementation of a core feature of netbox, we require a very detailed FR, so I'm going to close this in its current state. If you feel like you can provide a more detailed design of the proposed feature, please post it here and I'll review it.