Permission model/object permissions

[Paul Pappel]

Hi, I work at a medium sized company, we use netbox to track our IT equipment on

the campus. Most of this is done by the IT department itself, but a part of the work

is delegated to groups with a limited scope. We have groups that maintain one room,

one rack, or maybe just a group of servers themselves. I'd like to reflect this properly

in netbox permissions and create limited scopes for those users. 

My problem is that the current netbox object permissions seem not suitable for the task.

I tried to solve the problem with permission constraints. I can successfully generate

constraints, but I need many of them (for the different object types), it works only for

existing objects, and the task is tedious and error prone. It is currently no practical

option for me. I'd wish for an option for easily assign a whole room/rack to a group

and include all relevant permissions and every object that the group creates in its

scope.

Question 1: Is my understanding of the current situation correct? Please tell me if

there is a way to solve my problem with the existing permissions model.

Question 2: Can the problem be solved with a plugin? As far as I understand

plugins cannot change the permission model.

Question 3: How could the problem be solved? I am willing to put some work into netbox

itself, either in a private fork or (better) upstream. But I'd rather hear a competent

opinion on that before even starting.

[Jeremy Stretch]

Hi Paul,

It might help to provide a concrete example of what it is you're trying to do. What permissions have you tried creating, and what specifically isn't working? From there, we can help identify options for employing permission constraints.

Jeremy

--
You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/e601caf9-e3ee-451b-aded-cb7a40dee5a4n%40googlegroups.com.

--

Jeremy Stretch
Sr. Network Automation Engineer
Network to Code, LLC

[Paul Pappel]

Hi Jeremy,

I'll try to illustrate the problem with a specific example.

Lets assume I have a site 'RoomA' and I want to authorize a group 'roomAadmin' to edit that room.

The site object already exists and I created a view/change permission that for dcim->site  and assign it to the

roomAadmin group.

# constraint: {"name__in": ["RoomA"]}

This still works well.

Now lets assume that I want to authorize the group to add a Rack (but only to this room).

I create another permission for view/change/add/delete on dcim->rack and assign it to the group.

# constraint: {"site__in": ["RoomA"]}

This is an attribute that I derived from the web response. It doesn't work and gives a nice crash.

# constraint: {"site__name__in": ["RoomA"]}

Got this from the example in the web. It works, but I'm not exactly sure what it does and it feels

more like tinkering than thoughtful configuration.

And finally: my user should be able to create devices in his new Rack. I failed on this in my first try

for obscure reasons, thats why I came here. I just  managed to make it work successfully with

some trial-and-error:

# constraint: {"rack__site__name__in": ["RoomA"]}

If I follow that finding, I need one permission per object type. The constraints for these permission

are hard to write. I end up with a huge list of permissions that are all specific/handcrafted for one

group (site 'RoomA'). This seems unmanageable to me.

Questions:

- Is there a proper documentation on how exactly the constraints are designed?

- Do I really have to write one constraint for each object type?

- Is there a way to fuse all these constraints in one permission?

  (instead of having one permission per object type)

- Can I 'parameterize' a set of constraints? I'd like to configure something like a

   role 'site-admin' and use it for different groups in different rooms.

Thanks in advance

  P

[Paul Pappel]

I did some deep-dive in the code and have some answers for those who are interested:

- netbox constraints are built on django query set field lookups:

  https://docs.djangoproject.com/en/3.1/ref/models/querysets/#id4

  You have to read the code and understand the corresponding models. You start from the
  object in question and you can either use an attribute or follow a reference to another

  object (until you finally reach an attribute).

  Assume that you have this constraint (for devices, from the examples):

    {"site__name__in": ["NYC1", "NYC2"]},

  It means to first use 'site' (which is a reference) to go to the corresponding site object, then

  proceed to the 'name' (which is an attribute in site) which has the actual value. The keyword

  'in' then compares the value to the specified list.

  This is hard to use, I found no easy way.

- You need to write a permission for every object type/constraint as most models

  are different and need their very own constraint with an exactly matching structure.

  Some constraints can be used by multiple object types if the constraint that you

  write works with all models equally.

- I found no way to parameterizie/reuse permissions. I assume that you have to

  write a huge set of hand-crafted permissions for each group that you have.