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

Allow to store an "audit user" for changes via restAPI #10500

New Issue
Closed
opened 2025-12-29 21:32:16 +01:00 by adam · 9 comments
adam commented 2025-12-29 21:32:16 +01:00
Owner
Copy Link

Originally created by @JohannesKreuzer on GitHub (Nov 21, 2024).

NetBox version

v4.1.6

Feature type

Data model extension

Triage priority

N/A

Proposed functionality

allow to pass an username (actually an arbitrary string) via restAPI to store the user of the upstream application which triggered the rest api request for auditing purposes, it should default to the username of the netbox user triggering the request, if it is not passed in the request. Might be done via an additional HTTP-Header to be sent from restAPI client to netbox server.

Use case

Netbox is used as a Datasource for an upstream application. To be able to see who really triggered the changes in netbox, it is needed to be able to pass the username from the upstream application to netbox.

Database changes

add an additonal audit_username field of type string to ChangeLog model.

External dependencies

support in the netbox restAPI client libraries

Originally created by @JohannesKreuzer on GitHub (Nov 21, 2024). ### NetBox version v4.1.6 ### Feature type Data model extension ### Triage priority N/A ### Proposed functionality allow to pass an username (actually an arbitrary string) via restAPI to store the user of the upstream application which triggered the rest api request for auditing purposes, it should default to the username of the netbox user triggering the request, if it is not passed in the request. Might be done via an additional HTTP-Header to be sent from restAPI client to netbox server. ### Use case Netbox is used as a Datasource for an upstream application. To be able to see who really triggered the changes in netbox, it is needed to be able to pass the username from the upstream application to netbox. ### Database changes add an additonal audit_username field of type string to ChangeLog model. ### External dependencies support in the netbox restAPI client libraries
adam added the type: feature label 2025-12-29 21:32:16 +01:00
adam closed this issue 2025-12-29 21:32:16 +01:00
adam commented 2025-12-29 21:32:17 +01:00
Author
Owner
Copy Link

@rboucher-me commented on GitHub (Feb 13, 2025):

Best practices is to use different users (with corresponding API keys) for each application. This should satisfy this need.

@rboucher-me commented on GitHub (Feb 13, 2025): Best practices is to use different users (with corresponding API keys) for each application. This should satisfy this need.
adam commented 2025-12-29 21:32:18 +01:00
Author
Owner
Copy Link

@JohannesKreuzer commented on GitHub (Mar 24, 2025):

@rboucher-me this is not about having different applications reusing the API key, but about to be able to audit which user of the application triggered the changes in NetBox.

@JohannesKreuzer commented on GitHub (Mar 24, 2025): @rboucher-me this is not about having different applications reusing the API key, but about to be able to audit which user of the application triggered the changes in NetBox.
adam commented 2025-12-29 21:32:18 +01:00
Author
Owner
Copy Link

@rboucher-me commented on GitHub (Mar 24, 2025):

Understood. You make a good point and the "audit trail" use case probably requires further consideration.

@rboucher-me commented on GitHub (Mar 24, 2025): Understood. You make a good point and the "audit trail" use case probably requires further consideration.
adam commented 2025-12-29 21:32:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 24, 2025):

to be able to audit which user of the application triggered the changes in NetBox.

The application would need to be configured to act as that user, with an API token tied to the user's account in NetBox.

@jeremystretch commented on GitHub (Mar 24, 2025): > to be able to audit which user of the application triggered the changes in NetBox. The application would need to be configured to act as that user, with an API token tied to the user's account in NetBox.
adam commented 2025-12-29 21:32:19 +01:00
Author
Owner
Copy Link

@JohannesKreuzer commented on GitHub (Mar 24, 2025):

@jeremystretch
In the upstream application, you don't want every user (which is unaware of NetBox, and would have no direct access to NetBox) to have to go to NetBox to create an API token and feed to the upstream Application and store there.

e.g. think about a Managed hosting system, managing VMs on the hypervisor and also storing the information in NetBox. Users are only allowed to access the application itself, but have no access to the hypervisor and NetBox. Only the application has access with restricted service credentials, only granting the least necessary privileges to the application. The changes in NetBox should then be traceable to the application user which triggered the change (creating a tuple to identify the original user (NetBox User + audit user).

@JohannesKreuzer commented on GitHub (Mar 24, 2025): @jeremystretch In the upstream application, you don't want every user (which is unaware of NetBox, and would have no direct access to NetBox) to have to go to NetBox to create an API token and feed to the upstream Application and store there. e.g. think about a Managed hosting system, managing VMs on the hypervisor and also storing the information in NetBox. Users are only allowed to access the application itself, but have no access to the hypervisor and NetBox. Only the application has access with restricted service credentials, only granting the least necessary privileges to the application. The changes in NetBox should then be traceable to the application user which triggered the change (creating a tuple to identify the original user (NetBox User + audit user).
adam commented 2025-12-29 21:32:19 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 24, 2025):

In the upstream application, you don't want every user (which is unaware of NetBox, and would have no direct access to NetBox) to have to go to NetBox to create an API token and feed to the upstream Application and store there.

It seems you're conflating two authentication systems. If the user of a remote application has no equivalent account in NetBox, then it makes no sense for NetBox to associate that user with a change made in NetBox: That information would need to be recorded within the remote application. NetBox knows only about the users which have accounts created within it.

@jeremystretch commented on GitHub (Mar 24, 2025): > In the upstream application, you don't want every user (which is unaware of NetBox, and would have no direct access to NetBox) to have to go to NetBox to create an API token and feed to the upstream Application and store there. It seems you're conflating two authentication systems. If the user of a remote application has no equivalent account in NetBox, then it makes no sense for NetBox to associate that user with a change made in NetBox: That information would need to be recorded within the remote application. NetBox knows only about the users which have accounts created within it.
adam commented 2025-12-29 21:32:19 +01:00
Author
Owner
Copy Link

@JohannesKreuzer commented on GitHub (Mar 24, 2025):

@jeremystretch We don't want to associate an additional NetBox user, but from DB perspective a string field in the ChangeLog entry, to store this info.

@JohannesKreuzer commented on GitHub (Mar 24, 2025): @jeremystretch We don't want to associate an additional NetBox user, but from DB perspective a string field in the ChangeLog entry, to store this info.
adam commented 2025-12-29 21:32:19 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 24, 2025):

Right; a string that represents a user completely foreign to NetBox. It's arbitrary metadata, extraneous to the intended purpose of change logging in NetBox.

@jeremystretch commented on GitHub (Mar 24, 2025): Right; a string that represents a user completely foreign to NetBox. It's arbitrary metadata, extraneous to the intended purpose of change logging in NetBox.
adam commented 2025-12-29 21:32:19 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Mar 27, 2025):

While we can appreciate this and related use cases, we don't think this is the proper way to attack this. This points to a larger feature that would require more exploration and design work.

@jnovinger commented on GitHub (Mar 27, 2025): While we can appreciate this and related use cases, we don't think this is the proper way to attack this. This points to a larger feature that would require more exploration and design work.
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 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#10500
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?