-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow secrets to be associated with multiple devices #69
Comments
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. |
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.
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.
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.).
Each secret already includes a
I'm not sure what you have in mind here, but it doesn't seem like it would be bound to device assignment. |
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:
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:
So if different people have access to these, I'd need to create distinct secret roles such as:
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.
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)
I mean that for secret FOO-1, you store it as a file (or db blob) 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:
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. |
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.
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. |
For reference: I came across an open source application which works in exactly the way I wanted. It's passbolt.
|
Proposal for discussion: that the same secret can be associated with multiple devices; and that secrets are versioned.
Current: (device, secret role, username, secret)
Proposed: (device, secret role, username, secret class, secret version)
Secrets: (class, version, secret, timestamp, comment)
Secret classes can have an overall description:
This would mean:
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.
The text was updated successfully, but these errors were encountered: