Netbox: Extend the Users REST API Endpoint to support managing API Tokens

[tagur87]

Environment

• Python version: 3.7
• NetBox version: 2.9.7

Proposed Functionality

Establish REST API endpoint at /api/users/tokens/ for managing tokens via the API.

Use Case

Enables the ability to programmatically manage the user tokens that have access to the netbox API. Currently the management of this is only via the Admin UI or user control panel.

There are a couple potential use cases that can be benefitted from.

1) Creation of API users in configuration management (IaC) platform.

• We use a configuration management tool to deploy our Netbox instance and manage it, including user and token management. Currently we are using the nbshell programmatically to create the API users that we need for our automated processes. Since the creation of the Users and Groups endpoint, we are almost able to do it all via the API. However since Token's is not supported, we will still have to shell out the the nbshell to add our users.

2) Dynamic API user creation

• We can see a use case where ephemeral users/tokens can be generated by a tool such as hashicorp vault which would allow us to have short lived secrets that can be revoked and/or deleted after a certain point in time or if the secret was breached. This would improve security and allow us to have better auditing and compliance with the usage of a tool like vault. If token management via the API were supported, we could programmatically do these operations in a safe a repeatable way.
  

Database Changes

None

External Dependencies

None

[jeremystretch]

Further consideration needs to be given to the permissions architecture. Allowing users to create tokens only for themselves via the REST API is of limited utility. So, how can we best handle the granting of permissions to particular users that will allow them to create/modify/delete tokens for other users?

One approach is to require permissions with constraints that identify the user accounts for which tokens may be created; e.g. {"user__group__name__in": ["Group A", "Group B"]}. However, this conflicts with the way we currently handle the permission, which merely toggles whether a user is allowed to create his or her own tokens. It would be very tedious to require the creation of a discrete permission for each user, but we also need to preserve the mechanism for disallowing users to create tokens.

[tagur87]

What if the permission to create tokens via the API was only given to a user with superuser permissions?

[jeremystretch]

@tagur87 I'd expect many people to be hesitant to grant an API token to superuser accounts. It's a potential solution but I'm not sure it's tenable for everyone.

[lampwins]

I see two paths ways here and maybe it makes sense to actually do both.

1. Users are able to authenticate to a new API endpoint /api/users/<username>/tokens/ to generate a new token. A POST request would create a new token, a GET request would show all the user's tokens. The key here is that a user does this for themselves, not anyone else. The endpoint would accept basic auth and use whatever auth backend to actually authenticate the user.

2. Admin users (those with permission to create/modify users) are able to generate and view tokens for other users.