- Productionize existing configuration management software jnt (potentially renaming it)
- Integrate with Netbox for device selection and topology data gathering
- Add safe push method for the configuration: interactive and sequential
- [stretch] Evaluate Netbox to store network secrets
[stretch] Evaluate Netbox to store network secrets
After playing a bit with secrets in our Netbox test box I've come to the conclusion that they might not be suitable for our use case. To summarize their current state in Netbox:
- Secrets are attached to a device, meaning that it seems not possible to "share" a secret between multiple devices or have generic secrets not attached to any device.
- Secrets have roles (that allow to restrict users/groups that access) but AFAICT no ACLs, so it seems not possible to create a RO access role for example.
- When setting up secrets the admin needs to create a UserKey (RSA) and Netbox will automatically generate a master key that will be encrypted with the admin's key.
- To manage secrets each user have to set a UserKey (RSA) and then be activated by a previously activated user. The activation procedure decrypt the master key with the activated user's private key and save an encrypted copy of it (with the new user's public key) to their profile. So basically there are multiple copies of the master key encrypted with each user's public key.
- To manage secrets via the API you need a session key, to get one an activated user needs to POST their private RSA key to get a Session Key. So basically in order to allow the software to retrieve secrets from Netbox we'll either need to set an RSA key for the sre_bot Netbox user and have its private key at hand on the management hosts or require the operator to generate a user key and pass it to the software at runtime.
In particular limitation (1, secrets attached to a device) seems mostly a blocker to me for our use case. Also requirement (5, Session Key) seems suboptimal to me for our workflow.
I'd like to hear other thoughts too.