Allow the assignment of secrets to objects other than devices

[elmmare]

Issue type

[X] Feature request
[ ] Bug report
[ ] Documentation

Environment

• Python version: 2.7.5
• NetBox version: 2.1.4

Description

Secret cannot be attached to Sites and Racks but only to devices.

Usage cases:
*Store combination lock codes for racks or cage
*Store Site access codes

[jeremystretch]

Extending secrets from devices to multiple objects requires replacing the ForeignKey field tied to the Device model with a GenericForeignKey. This in itself is straightforward, however we have to consider how this relationship should be displayed in the API.

Currently, a secret retrieved via the API looks like this:

{
    "id": 1234,
    "device": {
        "id": 5678,
        "url": "http://localhost:8000/api/dcim/devices/5678/",
        "name": "MyDevice",
        "display_name": "MyDevice"
    },
    "role": <...>,
    "name": "root",
    "plaintext": null,
    "hash": "<hash>",
    ...
}

If we switch to a generic relationship, we need some way to indicate the type of the parent object, both while retrieving existing secrets and while creating new ones. The DRF documentation talks about this briefly, but does not suggest any particular approach.

[darkstar]

How about integrating with HashiCorp's Vault (https://www.vaultproject.io) as backend storage for secrets? If it is even remotely possible/interesting I can open a feature request issue for it.

[rlaneyjr]

I agree with darkstar. I had thought about making an attempt to integrate it in myself. Then realized I am a novice at best with Python/Django and lost with GO.

[jeremystretch]

I looked into Vault back when I was first working on secrets storage. While it can certainly be used in conjunction with NetBox (with Vault serving as a replacement for NetBox's built-in storage), I don't think it makes sense for NetBox to integrate directly with Vault. Doing so would incur a substantial new dependency while not providing any significant value as opposed to accessing Vault directly. Let's stick with the functionality we have now.

[linasjan]

Secrets for tenants also would be appreciated.

[larsuhartmann]

This feature would be highly apreciated!

[c0dyhi11]

Hello,

I'd also like to see secrets for other object. My use case is a place to store API keys during provisioning. I'm building an API wrapper around Terraform and Netbox to deploy infrastructure. I'd be nice to store the API key under the "Site" I'm deploying to.

My goal is that you only need to authenticate to NetBox's API and everything else to provision into: Route53, Packet.net, OpenStack, AWS, Etc... Will all be accessible through the NetBox secrets store. It's either this or stand up another secrets store (Like Vault or Rattic) and pull the NetBox API Key from there...

Thank you,
Cody Hill

[etfeet]

I would also like to see secrets for virtual-machines. My use case is to store salt minion public/private rsa key pairs for automagicly provisioning and accept salt minion keys on the master via querying the netbox api. I would prefer not to story that data as custom fields on the virtual-machines which is my only option right now (with netbox). Also Would it be possible to add another field to secrets for storing public/private key pairs for devices?

[larsuhartmann]

I could not find this Feature on any Roadmap / Release Plans
Is there any plan on when to implement this?
We are waiting eagerly for this to be introduced as we plan to store our automatically generated root passwords in netbox - although as i don't know how complicated it would be to implement this ... don't feel pressured by me :)