starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Extend the Users REST API Endpoint to support managing API Tokens #4210

New Issue
Closed
opened 2025-12-29 18:33:52 +01:00 by adam · 10 comments
adam commented 2025-12-29 18:33:52 +01:00
Owner
Copy Link

Originally created by @tagur87 on GitHub (Oct 23, 2020).

Originally assigned to: @jeremystretch on GitHub.

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

Originally created by @tagur87 on GitHub (Oct 23, 2020). Originally assigned to: @jeremystretch on GitHub. <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/g/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.7 * NetBox version: 2.9.7 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality Establish REST API endpoint at `/api/users/tokens/` for managing tokens via the API. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### 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. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes None <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies None
adam added the status: acceptedtype: feature labels 2025-12-29 18:33:52 +01:00
adam closed this issue 2025-12-29 18:33:53 +01:00
adam commented 2025-12-29 18:33:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 26, 2020):

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.

@jeremystretch commented on GitHub (Oct 26, 2020): 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.
adam commented 2025-12-29 18:33:53 +01:00
Author
Owner
Copy Link

@tagur87 commented on GitHub (Nov 10, 2020):

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

@tagur87 commented on GitHub (Nov 10, 2020): What if the permission to create tokens via the API was only given to a user with superuser permissions?
adam commented 2025-12-29 18:33:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 17, 2020):

@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.

@jeremystretch commented on GitHub (Nov 17, 2020): @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.
adam commented 2025-12-29 18:33:53 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Dec 22, 2020):

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.

@lampwins commented on GitHub (Dec 22, 2020): 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.
adam commented 2025-12-29 18:33:53 +01:00
Author
Owner
Copy Link

@coloHsq commented on GitHub (Jan 26, 2021):

@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.

@coloHsq commented on GitHub (Jan 26, 2021): @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.
adam commented 2025-12-29 18:33:53 +01:00
Author
Owner
Copy Link

@tagur87 commented on GitHub (Feb 25, 2021):

@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!

@tagur87 commented on GitHub (Feb 25, 2021): @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!
adam commented 2025-12-29 18:33:53 +01:00
Author
Owner
Copy Link

@coloHsq commented on GitHub (Feb 25, 2021):

@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 commented on GitHub (Feb 25, 2021): > @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.
adam commented 2025-12-29 18:33:54 +01:00
Author
Owner
Copy Link

@coloHsq commented on GitHub (Mar 2, 2021):

@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.

@coloHsq commented on GitHub (Mar 2, 2021): > > @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.
adam commented 2025-12-29 18:33:54 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 17, 2021):

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.

@github-actions[bot] commented on GitHub (Apr 17, 2021): 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](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:33:54 +01:00
Author
Owner
Copy Link

@wegenerbenjamin commented on GitHub (Apr 17, 2021):

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

@wegenerbenjamin commented on GitHub (Apr 17, 2021): We have the same use case (configuration mgmt) and would be very interested in a netbox-native feature
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#4210
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?