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.

[coloHsq]

@lampwins

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.

I have already developed a similar solution as part of a plugin, also adding an encryption layer to not let data (credentials and tokens) pass in cleartext. The whole process is done in two steps, with two differents API endpoints, the first for keys exchange, and the second to actually perform the login.
As I'm not a professional developer, the code probably needs some improvement, but I think it might serve the purpose.

Let me know it you're interested in it.

[tagur87]

@coloHsq - Do you have an example of this plugin that you used? I would be interested in how you did this, as I tried to do something similar, but ran into some road blocks with the user models. If you could publish the code, I would be very grateful!

[coloHsq]

@coloHsq - Do you have an example of this plugin that you used? I would be interested in how you did this, as I tried to do something similar, but ran into some road blocks with the user models. If you could publish the code, I would be very grateful!

At the moment that part is incorporated in a bigger plugin with all my custom endpoints.
In the next few days I'll extract the necessary and prepare a plugin for the authentication part only.

[coloHsq]

@coloHsq - Do you have an example of this plugin that you used? I would be interested in how you did this, as I tried to do something similar, but ran into some road blocks with the user models. If you could publish the code, I would be very grateful!

At the moment that part is incorporated in a bigger plugin with all my custom endpoints.
In the next few days I'll extract the necessary and prepare a plugin for the authentication part only.

https://github.com/coloHsq/netbox-auth-api

It should work.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

[wegenerbenjamin]

We have the same use case (configuration mgmt) and would be very interested in a netbox-native feature