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 secrets to be associated with multiple devices #43

New Issue
Closed
opened 2025-12-29 15:30:34 +01:00 by adam · 6 comments
adam commented 2025-12-29 15:30:34 +01:00
Owner
Copy Link

Originally created by @candlerb on GitHub (Jun 28, 2016).

Proposal for discussion: that the same secret can be associated with multiple devices; and that secrets are versioned.

Current: (device, secret role, username, secret)

router1,SNMP community,,abc123
router2,SNMP community,,abc123
router3,SNMP community,,def456
ups1,SNMP community,,p@ssw0rd

Proposed: (device, secret role, username, secret class, secret version)

router1,SNMP community,,SNMP core,1
router2,SNMP community,,SNMP core,1
router3,SNMP community,,SNMP core,2
ups1,SNMP community,,SNMP UPS,1

Secrets: (class, version, secret, timestamp, comment)

SNMP core,1,abc123,20160112,Initial version
SNMP core,2,def456,20160628,Rotated after staff change
SNMP UPS,1,p@ssw0rd,20160112,Initial version

Secret classes can have an overall description:

SNMP core,Community for core routers
SNMP UPS,Community for vendor-managed UPS equipment

This would mean:

  • fewer encrypted items stored in the database
  • the ability to add a new device and select from existing secrets in a drop-down menu, without having to type in the secret itself each time
  • easier to report on which devices are using out-of-date secrets
  • GPG-encrypted secrets could be used, eliminating the need to handle private keys in the browser (aside: could also export them to a passwordstore filetree)

Since secrets are shared they should be immutable, at least if in use by more than one device. To rotate a password you would create a new version of the secret and then assign the new version to each device as you update it. This could be offered as a bulk-change operation in the GUI.

The above design allows the same secret to be used for any role, which is most flexible, but alternatively each secret class could be linked to a single role (to restrict the drop-down choices to relevant ones only)

Backwards-compatibility: may need to allow both per-device and shared secrets. May also be helpful when some oddball devices have ad-hoc passwords.

Originally created by @candlerb on GitHub (Jun 28, 2016). Proposal for discussion: that the same secret can be associated with multiple devices; and that secrets are versioned. Current: (device, secret role, username, secret) ``` router1,SNMP community,,abc123 router2,SNMP community,,abc123 router3,SNMP community,,def456 ups1,SNMP community,,p@ssw0rd ``` Proposed: (device, secret role, username, secret class, secret version) ``` router1,SNMP community,,SNMP core,1 router2,SNMP community,,SNMP core,1 router3,SNMP community,,SNMP core,2 ups1,SNMP community,,SNMP UPS,1 ``` Secrets: (class, version, secret, timestamp, comment) ``` SNMP core,1,abc123,20160112,Initial version SNMP core,2,def456,20160628,Rotated after staff change SNMP UPS,1,p@ssw0rd,20160112,Initial version ``` Secret classes can have an overall description: ``` SNMP core,Community for core routers SNMP UPS,Community for vendor-managed UPS equipment ``` This would mean: - fewer encrypted items stored in the database - the ability to add a new device and select from existing secrets in a drop-down menu, without having to type in the secret itself each time - easier to report on which devices are using out-of-date secrets - GPG-encrypted secrets could be used, eliminating the need to handle private keys in the browser (aside: could also export them to a [passwordstore](https://www.passwordstore.org/) filetree) Since secrets are shared they should be immutable, at least if in use by more than one device. To rotate a password you would create a new version of the secret and then assign the new version to each device as you update it. This could be offered as a bulk-change operation in the GUI. The above design allows the same secret to be used for any role, which is most flexible, but alternatively each secret class could be linked to a single role (to restrict the drop-down choices to relevant ones only) Backwards-compatibility: may need to allow both per-device and shared secrets. May also be helpful when some oddball devices have ad-hoc passwords.
adam closed this issue 2025-12-29 15:30:34 +01:00
adam commented 2025-12-29 15:30:35 +01:00
Author
Owner
Copy Link

@phobiadhs commented on GitHub (Jun 12, 2017):

I would also like to suggest that while secrets should be able to be associated with single or multiple devices, that they also have the ability (by default in my opinion, but open to other possibilities here) to be associated with no device at all. An independent entity exclusive of device assignment.
For example, domain credentials that may be used for namespace shares that are possibly machine independent depending on namespace configuration.

@phobiadhs commented on GitHub (Jun 12, 2017): I would also like to suggest that while secrets should be able to be associated with single or multiple devices, that they also have the ability (by default in my opinion, but open to other possibilities here) to be associated with no device at all. An independent entity exclusive of device assignment. For example, domain credentials that may be used for namespace shares that are possibly machine independent depending on namespace configuration.
adam commented 2025-12-29 15:30:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 28, 2017):

I understand the efficiency argument, however treating a collection of multiple discrete values as a single atomic unit is dangerous. In practice, it is extremely likely that the secrets stored in NetBox will get out of sync with what's actually configured on devices. Additionally, I don't think it offers any significant benefits. The main advantage of the secrets system in NetBox is its ability to store unique secrets for each device. If you're reusing secrets for many devices, a simply password store like LastPass might be a better option.

fewer encrypted items stored in the database

Secrets consume very little space in the database. Further, consider that adopting a many-to-one model would necessitate an intermediary table linking secrets to devices, which incurs a (similarly negligible) performance penalty.

the ability to add a new device and select from existing secrets in a drop-down menu, without having to type in the secret itself each time

Again, this seems extremely dangerous. You'll also likely end up with a list of seemingly redundant secrets (e.g. "root," "root2," "root password," "new root password," etc.).

easier to report on which devices are using out-of-date secrets

Each secret already includes a created and last_updated time. (Though to be fair, I believe these were added after this feature request was opened.)

GPG-encrypted secrets could be used, eliminating the need to handle private keys in the browser

I'm not sure what you have in mind here, but it doesn't seem like it would be bound to device assignment.

@jeremystretch commented on GitHub (Jul 28, 2017): I understand the efficiency argument, however treating a collection of multiple discrete values as a single atomic unit is dangerous. In practice, it is extremely likely that the secrets stored in NetBox will get out of sync with what's actually configured on devices. Additionally, I don't think it offers any significant benefits. The main advantage of the secrets system in NetBox is its ability to store unique secrets for each device. If you're reusing secrets for many devices, a simply password store like LastPass might be a better option. > fewer encrypted items stored in the database Secrets consume very little space in the database. Further, consider that adopting a many-to-one model would necessitate an intermediary table linking secrets to devices, which incurs a (similarly negligible) performance penalty. > the ability to add a new device and select from existing secrets in a drop-down menu, without having to type in the secret itself each time Again, this seems extremely dangerous. You'll also likely end up with a list of seemingly redundant secrets (e.g. "root," "root2," "root password," "new root password," etc.). > easier to report on which devices are using out-of-date secrets Each secret already includes a `created` and `last_updated` time. (Though to be fair, I believe these were added after this feature request was opened.) > GPG-encrypted secrets could be used, eliminating the need to handle private keys in the browser I'm not sure what you have in mind here, but it doesn't seem like it would be bound to device assignment.
adam commented 2025-12-29 15:30:37 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Aug 11, 2017):

This wish comes from supporting a particular way of working.

The way we work here is to have "password classes". All machines in the same password class have the same root password (for example). If we have 12 storage servers, they all have the same password, and building a 13th storage server we just use the same one again.

We also use the same SNMP community string for similar classes of device (e.g. all switches, all access points) and the same IPMI login creds for similar classes of device.

As you say, we could use lastpass type approach for this: indeed, we currently have a GPG password file with all the various password classes in it. To integrate this with netbox we'd need to add a custom field or fields recording the password class for the machine; we'd still have to open and decrypt the external password file.

We also version our passwords. So for example, say all machines are on password class IPMI-1. When it's time to change this, we create a new random password IPMI-2. We then go round machines changing IPMI-1 to IPMI-2. We keep the IPMI-1 secret around for historical purposes, in case we ever come across an overlooked machine which is still using it.

The approach Netbox supports/promotes seems to be:

  • every device has a unique root password
  • every device has a unique SNMP community string
  • every device has a unique IPMI password
  • etc.

I can see benefits to this approach, particularly with regards auditing who has seen which passwords and therefore logged into which machines. However I think we'd find this too tedious in practice, especially with SNMP communities.

Since we set ssh to allow root access only with keys, the root password is only usable if you have console access to the box (or VM). Similarly, SNMP and IPMI are on separate management VLAN. Hence these all have an additional layer of protection anyway, which makes a degree of sharing acceptable IMO.

Incidentally, I note that in Netbox, "secret roles" seem to perform two distinct functions:

  • Labelling the purpose of the secret (e.g. "root password", "SNMP community")
  • Authorising access to specific users and/or groups

So if different people have access to these, I'd need to create distinct secret roles such as:

  • Login for storage servers
  • SNMP for storage servers
  • IPMI for storage servers
  • Login for switches
  • SNMP for switches
  • ...

It occurs to me that if the secret role itself contained a secret, this would basically achieve what I'm looking for. e.g. if role "SNMP for storage servers" contained an (encrypted) SNMP string, that could act as the default used by all storage servers. You could still store device-specific passwords as overrides at the device level.

You'll also likely end up with a list of seemingly redundant secrets (e.g. "root," "root2," "root password," "new root password," etc.).

It would be things like STORAGE-ROOT-1, STORAGE-ROOT-2, ... SWITCH-ADMIN-1, SWITCH-ADMIN-2, ... etc.

If I need a machine called 'foo' which needs its own unique password, then yes it would get its own password FOO-1 (and then FOO-2 when it changes)

GPG-encrypted secrets could be used, eliminating the need to handle private keys in the browser

I'm not sure what you have in mind here, but it doesn't seem like it would be bound to device assignment.

I mean that for secret FOO-1, you store it as a file (or db blob) foo-1.gpg, encrypted with the public keys of all the users who are permitted to see it. There's then no decryption occuring server-side.

I wrote this when I didn't fully understand the netdot encryption/decryption model, which is now clearer thanks to answers in #68.

As I understand it:

  1. There is a single random master key, and every secret is stored in the DB encrypted with this key
  2. The database stores a separate copy of the master key encrypted with each activated user's public key
  3. When a user wants to view a secret, they post their private key (via browser) to the server
  4. The server decrypts the master key with the private key, and then decrypts and returns the secret, assuming the user has rights to that secret

It makes me a uncomfortable that anyone who breaks into the server, intercepts any activated user's private key (e.g. between HTTPS frontend and gunicorn), and has access to the SQL database, will be able to decrypt all secrets. But it can of course be argued that client-side decryption in Javascript has its own set of problems.

@candlerb commented on GitHub (Aug 11, 2017): This wish comes from supporting a particular way of working. The way we work here is to have "password classes". All machines in the same password class have the same root password (for example). If we have 12 storage servers, they all have the same password, and building a 13th storage server we just use the same one again. We also use the same SNMP community string for similar classes of device (e.g. all switches, all access points) and the same IPMI login creds for similar classes of device. As you say, we could use lastpass type approach for this: indeed, we currently have a GPG password file with all the various password classes in it. To integrate this with netbox we'd need to add a custom field or fields recording the password class for the machine; we'd still have to open and decrypt the external password file. We also version our passwords. So for example, say all machines are on password class IPMI-1. When it's time to change this, we create a new random password IPMI-2. We then go round machines changing IPMI-1 to IPMI-2. We keep the IPMI-1 secret around for historical purposes, in case we ever come across an overlooked machine which is still using it. The approach Netbox supports/promotes seems to be: - every device has a unique root password - every device has a unique SNMP community string - every device has a unique IPMI password - etc. I can see benefits to this approach, particularly with regards auditing who has seen which passwords and therefore logged into which machines. However I think we'd find this too tedious in practice, especially with SNMP communities. Since we set ssh to allow root access only with keys, the root password is only usable if you have console access to the box (or VM). Similarly, SNMP and IPMI are on separate management VLAN. Hence these all have an additional layer of protection anyway, which makes a degree of sharing acceptable IMO. Incidentally, I note that in Netbox, "secret roles" seem to perform two distinct functions: * Labelling the purpose of the secret (e.g. "root password", "SNMP community") * Authorising access to specific users and/or groups So if different people have access to these, I'd need to create distinct secret roles such as: * Login for storage servers * SNMP for storage servers * IPMI for storage servers * Login for switches * SNMP for switches * ... It occurs to me that if the secret role itself contained a secret, this would basically achieve what I'm looking for. e.g. if role "SNMP for storage servers" contained an (encrypted) SNMP string, that could act as the default used by all storage servers. You could still store device-specific passwords as overrides at the device level. > You'll also likely end up with a list of seemingly redundant secrets (e.g. "root," "root2," "root password," "new root password," etc.). It would be things like STORAGE-ROOT-1, STORAGE-ROOT-2, ... SWITCH-ADMIN-1, SWITCH-ADMIN-2, ... etc. If I need a machine called 'foo' which needs its own unique password, then yes it would get its own password FOO-1 (and then FOO-2 when it changes) > > GPG-encrypted secrets could be used, eliminating the need to handle private keys in the browser > > > I'm not sure what you have in mind here, but it doesn't seem like it would be bound to device assignment. I mean that for secret FOO-1, you store it as a file (or db blob) `foo-1.gpg`, encrypted with the public keys of all the users who are permitted to see it. There's then no decryption occuring server-side. I wrote this when I didn't fully understand the netdot encryption/decryption model, which is now clearer thanks to answers in #68. As I understand it: 1. There is a single random master key, and every secret is stored in the DB encrypted with this key 2. The database stores a separate copy of the master key encrypted with each activated user's public key 3. When a user wants to view a secret, they post their private key (via browser) to the server 4. The server decrypts the master key with the private key, and then decrypts and returns the secret, assuming the user has rights to that secret It makes me a uncomfortable that anyone who breaks into the server, intercepts any activated user's private key (e.g. between HTTPS frontend and gunicorn), and has access to the SQL database, will be able to decrypt all secrets. But it can of course be argued that client-side decryption in Javascript has its own set of problems.
adam commented 2025-12-29 15:30:37 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 18, 2017):

The way we work here is to have "password classes". All machines in the same password class have the same root password (for example). If we have 12 storage servers, they all have the same password, and building a 13th storage server we just use the same one again.

The primary advantage of storing secrets in NetBox is the ability to associate them with specific devices. If you don't need this ability, you might as well keep them in a separate application like Vault or LastPass that include features like versioning.

It makes me a uncomfortable that anyone who breaks into the server, intercepts any activated user's private key (e.g. between HTTPS frontend and gunicorn), and has access to the SQL database, will be able to decrypt all secrets. But it can of course be argued that client-side decryption in Javascript has its own set of problems.

Yeah, that's the compromise I had to make in ensuring that secrets could be retrieved via the REST API. I originally started with an in-browser decryption client (and even got a rough POC working, if you can believe it!) but quickly realized that it wouldn't allow for automatically generating things like RADIUS server configs without a special client. Given that an attacker would need both the SQL database and a valid private key, I feel this is an acceptable approach. Obviously, other purpose-built credentials management tools like the ones I linked above provide stronger security, but aren't as easily integrated with other NetBox data.

Since I don't plan to implement this feature in NetBox, and the FR has been open for over a year with no community contribution, I'm going to close it out.

@jeremystretch commented on GitHub (Aug 18, 2017): > The way we work here is to have "password classes". All machines in the same password class have the same root password (for example). If we have 12 storage servers, they all have the same password, and building a 13th storage server we just use the same one again. The primary advantage of storing secrets in NetBox is the ability to associate them with specific devices. If you don't need this ability, you might as well keep them in a separate application like [Vault](https://www.vaultproject.io/) or [LastPass](https://www.lastpass.com/) that include features like versioning. > It makes me a uncomfortable that anyone who breaks into the server, intercepts any activated user's private key (e.g. between HTTPS frontend and gunicorn), and has access to the SQL database, will be able to decrypt all secrets. But it can of course be argued that client-side decryption in Javascript has its own set of problems. Yeah, that's the compromise I had to make in ensuring that secrets could be retrieved via the REST API. I originally started with an in-browser decryption client (and even got a rough POC working, if you can believe it!) but quickly realized that it wouldn't allow for automatically generating things like RADIUS server configs without a special client. Given that an attacker would need both the SQL database _and_ a valid private key, I feel this is an acceptable approach. Obviously, other purpose-built credentials management tools like the ones I linked above provide stronger security, but aren't as easily integrated with other NetBox data. Since I don't plan to implement this feature in NetBox, and the FR has been open for over a year with no community contribution, I'm going to close it out.
adam commented 2025-12-29 15:30:38 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Sep 14, 2017):

you might as well keep them in a separate application like Vault or LastPass that include features like versioning

For reference: I came across an open source application which works in exactly the way I wanted. It's passbolt.

  • Secrets are encrypted using PGP, and each user has their own PGP key. There is no master key.
  • All encryption/decryption is done in the browser. The server cannot decrypt anything.
  • When sharing a secret, it is encrypted with multiple keys
  • When you change the sharing settings of a secret, it is re-encrypted to the new set of eyes
  • Ditto for adding/removing members of a group
  • Lots of other neat features, e.g. every passphrase prompt displays a token so that you know you're talking to the trusted application.
@candlerb commented on GitHub (Sep 14, 2017): > you might as well keep them in a separate application like Vault or LastPass that include features like versioning For reference: I came across an open source application which works in exactly the way I wanted. It's [passbolt](https://www.passbolt.com/). * Secrets are encrypted using PGP, and each user has their own PGP key. There is no master key. * All encryption/decryption is done in the browser. The server cannot decrypt anything. * When sharing a secret, it is encrypted with multiple keys * When you change the sharing settings of a secret, it is re-encrypted to the new set of eyes * Ditto for adding/removing members of a [group](https://medium.com/passbolt/meet-passbolt-new-group-feature-f20261f2ff51) * Lots of other neat features, e.g. every passphrase prompt displays a [token](https://www.passbolt.com/faq) so that you know you're talking to the trusted application.
adam commented 2025-12-29 15:30:38 +01:00
Author
Owner
Copy Link

@Zorlin commented on GitHub (Sep 14, 2017):

@candlerb Excellent find. I definitely need to check that out.

@4dolio - finally a shared password manager you can use?

@Zorlin commented on GitHub (Sep 14, 2017): @candlerb Excellent find. I definitely need to check that out. @4dolio - finally a shared password manager you can use?
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#43
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?