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

Expand Secrets to Include Racks and Rack Cages #225

New Issue
Closed
opened 2025-12-29 16:19:38 +01:00 by adam · 5 comments
adam commented 2025-12-29 16:19:38 +01:00
Owner
Copy Link

Originally created by @JNR8 on GitHub (Jul 15, 2016).

In shared data centers there may be cages containing your Racks. Each of those cages made have an access code, and each of the racks may also have access codes. It would be handy to be able to store the access codes for cages and rack with those objects in NetBox.

Originally created by @JNR8 on GitHub (Jul 15, 2016). In shared data centers there may be cages containing your Racks. Each of those cages made have an access code, and each of the racks may also have access codes. It would be handy to be able to store the access codes for cages and rack with those objects in NetBox.
adam closed this issue 2025-12-29 16:19:38 +01:00
adam commented 2025-12-29 16:19:39 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 15, 2016):

This was a consideration early on in NetBox development, but I figured the overhead and complexity introduced by employing a GenericForeignKey to map Secrets to multiple models isn't worth the limited gain. Realistically, most people probably don't need to encrypt lock combinations; most will be fine with storing them as plaintext in the comments of an object.

@jeremystretch commented on GitHub (Jul 15, 2016): This was a consideration early on in NetBox development, but I figured the overhead and complexity introduced by employing a `GenericForeignKey` to map Secrets to multiple models isn't worth the limited gain. Realistically, most people probably don't need to encrypt lock combinations; most will be fine with storing them as plaintext in the comments of an object.
adam commented 2025-12-29 16:19:39 +01:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 21, 2016):

What about site-wide secrets, too. For things like product keycodes (VMware, windows, etc)?

@ghost commented on GitHub (Jul 21, 2016): What about site-wide secrets, too. For things like product keycodes (VMware, windows, etc)?
adam commented 2025-12-29 16:19:39 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 21, 2016):

If it's not tied directly to a NetBox resource, it probably shouldn't be in NetBox. There are myriad general purpose password management tools out there.

@jeremystretch commented on GitHub (Jul 21, 2016): If it's not tied directly to a NetBox resource, it probably shouldn't be in NetBox. There are myriad general purpose password management tools out there.
adam commented 2025-12-29 16:19:40 +01:00
Author
Owner
Copy Link

@joachimtingvold commented on GitHub (Jul 22, 2016):

This makes sense for more than racks and rack cages. One example would be BGP key/password; it would probably make more sense to apply that secret to a Circuit (or Provider), than the actual device (e.g. when replacing the device, you'd need to add the secret again, but the circuit/provider would be the same).

@joachimtingvold commented on GitHub (Jul 22, 2016): This makes sense for more than racks and rack cages. One example would be BGP key/password; it would probably make more sense to apply that secret to a Circuit (or Provider), than the actual device (e.g. when replacing the device, you'd need to add the secret again, but the circuit/provider would be the same).
adam commented 2025-12-29 16:19:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 6, 2016):

Tracking secrets for individual routing protocol adjacencies probably falls too far on the configuration management side, which NetBox does not attempt to breach. Operators are better off storing that data wherever they keep every other parameter of an adjacency (peer IP, route filters, timers, etc.).

I'm going to close this out because extending secrets beyond the Device model would introduce substantial complexity and overhead while yielding little additional value.

@jeremystretch commented on GitHub (Aug 6, 2016): Tracking secrets for individual routing protocol adjacencies probably falls too far on the configuration management side, which NetBox does not attempt to breach. Operators are better off storing that data wherever they keep every other parameter of an adjacency (peer IP, route filters, timers, etc.). I'm going to close this out because extending secrets beyond the Device model would introduce substantial complexity and overhead while yielding little additional value.
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
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#225
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?