Permissions¶

Nautobot provides an object-based permissions framework, which replace's Django's built-in permissions model. Object-based permissions enable an administrator to grant users or groups the ability to perform an action on arbitrary subsets of objects in Nautobot, rather than all objects of a certain type. For example, it is possible to grant a user permission to view only sites within a particular region, or to modify only VLANs with a numeric ID within a certain range.

Object Permissions¶

A permission in Nautobot represents a relationship shared by several components:

Object type(s) - One or more types of object in Nautobot
User(s)/Group(s) - One or more users or groups of users
Action(s) - The action(s) that can be performed on an object
Constraints - An arbitrary filter used to limit the granted action(s) to a specific subset of objects

At a minimum, a permission assignment must specify one object type, one user or group, and one action. The specification of constraints is optional: A permission without any constraints specified will apply to all instances of the selected model(s).

Actions¶

There are four core actions that can be permitted for each type of object within Nautobot, roughly analogous to the CRUD convention (create, read, update, and delete):

View - Retrieve an object from the database
Add - Create a new object
Change - Modify an existing object
Delete - Delete an existing object

In addition to these, permissions can also grant custom actions that may be required by a specific model or plugin. For example, the napalm_read permission on the device model allows a user to execute NAPALM queries on a device via Nautobot's REST API. These can be specified when granting a permission in the "additional actions" field.

Note

Internally, all actions granted by a permission (both built-in and custom) are stored as strings in an array field named actions.

Constraints¶

Constraints are expressed as a JSON object or list representing a Django query filter. This is the same syntax that you would pass to the QuerySet filter() method when performing a query using the Django ORM. As with query filters, double underscores can be used to traverse related objects or invoke lookup expressions. Some example queries and their corresponding definitions are shown below.

All attributes defined within a single JSON object are applied with a logical AND. For example, suppose you assign a permission for the site model with the following constraints.

{
  "status": "active",
  "region__name": "Americas"
}

The permission will grant access only to sites which have a status of "active" and which are assigned to the "Americas" region.

To achieve a logical OR with a different set of constraints, define multiple objects within a list. For example, if you want to constrain the permission to VLANs with an ID between 100 and 199 or a status of "reserved," do the following:

[
  {
    "vid__gte": 100,
    "vid__lt": 200
  },
  {
    "status": "reserved"
  }
]

Additionally, where multiple permissions have been assigned for an object type, their collective constraints will be merged using a logical "OR" operation.

Example Constraint Definitions¶

Constraints	Description
`{"status": "active"}`	Status is active
`{"status__in": ["planned", "reserved"]}`	Status is active OR reserved
`{"status": "active", "role": "testing"}`	Status is active OR role is testing
`{"name__startswith": "Foo"}`	Name starts with "Foo" (case-sensitive)
`{"name__iendswith": "bar"}`	Name ends with "bar" (case-insensitive)
`{"vid__gte": 100, "vid__lt": 200}`	VLAN ID is greater than or equal to 100 AND less than 200
`[{"vid__lt": 200}, {"status": "reserved"}]`	VLAN ID is less than 200 OR status is reserved

Permissions Enforcement¶

Viewing Objects¶

Object-based permissions work by filtering the database query generated by a user's request to restrict the set of objects returned. When a request is received, Nautobot first determines whether the user is authenticated and has been granted to perform the requested action. For example, if the requested URL is /dcim/devices/, Nautobot will check for the dcim.view_device permission. If the user has not been assigned this permission (either directly or via a group assignment), Nautobot will return a 403 (forbidden) HTTP response.

If the permission has been granted, Nautobot will compile any specified constraints for the model and action. For example, suppose two permissions have been assigned to the user granting view access to the device model, with the following constraints:

[
    {"site__name__in":  ["NYC1", "NYC2"]},
    {"status":  "offline", "tenant__isnull":  true}
]

This grants the user access to view any device that is assigned to a site named NYC1 or NYC2, or which has a status of "offline" and has no tenant assigned. These constraints are equivalent to the following ORM query:

Site.objects.filter(
    Q(site__name__in=['NYC1', 'NYC2']),
    Q(status='active', tenant__isnull=True)
)

Creating and Modifying Objects¶

The same sort of logic is in play when a user attempts to create or modify an object in Nautobot, with a twist. Once validation has completed, Nautobot starts an atomic database transaction to facilitate the change, and the object is created or saved normally. Next, still within the transaction, Nautobot issues a second query to retrieve the newly created/updated object, filtering the restricted queryset with the object's primary key. If this query fails to return the object, Nautobot knows that the new revision does not match the constraints imposed by the permission. The transaction is then rolled back, leaving the database in its original state prior to the change, and the user is informed of the violation.

Assigning Permissions¶

Permissions are implemented by assigning them to specific users and/or to groups of users. Users can have a combination of permissions and groups assigned to their account. All of the permissions granted to the user's groups and directly to the user's account will be used when determining authorization to access an object or view.

Assigning Permissions to Individual Users¶

Permissions can be related directly to users from the Admin UI or the API:

-	Admin UI	API
Superusers	Yes	Yes
Staff users with `users.add_permission` or `users.change_permission`	Yes	Yes
Regular users with `users.add_permission` or `users.change_permission`	No	Yes

Multiple permissions can be assigned to a user account.

Info

User permission relationships can be managed in the Admin UI by modifying the user or the permission.

Warning

Granting a user users.change_permission or users.add_permission gives the user the ability to modify their own permissions. This permission should be restricted to trusted accounts and should be considered the same as giving a user full access.

Creating Groups¶

Groups of users can be created to provide role-based access control and simplify user permissions management. Permissions related to a group will apply to all users in the group. A user can belong to any number of groups. Groups can be created from the Admin UI or the API:

-	Admin UI	API
Superusers	Yes	Yes
Users with `auth.add_group` or `auth.change_group`	No	Yes

Adding Users to Groups¶

Users can be added to groups through the Admin UI by superusers or automatically assigned to externally authenticated users through the EXTERNAL_AUTH_DEFAULT_GROUPS and EXTERNAL_AUTH_DEFAULT_PERMISSIONS settings. Nautobot groups can optionally be mapped to LDAP groups when using LDAP authentication.

Assigning Permissions to Groups¶

Permissions can be related to groups by superusers or users with users.add_permission or users.change_permission permissions.

-	Admin UI	API
Superusers	Yes	Yes
Staff users with `users.add_permission` or `users.change_permission`	Yes	Yes
Regular users with `users.add_permission` or `users.change_permission`	No	Yes

Multiple permissions can be assigned to a user group.

Info

Group permission relationships can be managed in the Admin UI by modifying the group (superusers only) or the permission.