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

Storing Secrets and Information for NAPALM usage #3964

New Issue
Closed
opened 2025-12-29 18:32:20 +01:00 by adam · 7 comments
adam commented 2025-12-29 18:32:20 +01:00
Owner
Copy Link

Originally created by @jameskirsop on GitHub (Aug 11, 2020).

Environment

  • Python version: 3.7
  • NetBox version: 2.8.5

Proposed Functionality

NB. This is an extension of the work that was proposed (and completed) in #2113 and is written in response to #4975.

When a request is made to NAPALM, if there are secrets with the following names attached to the device being queried, they are inserted into the parameters sent (as per #2113) so that additional information can be supplied to the request:

  • X-NAPALM-Username
  • X-NAPALM-Password
  • X-NAPALM-ssh_config_file

Indeed, it could be useful if all of the Napalm optional arguments could be passed in the headers, but that is outside the scope of this Feature Request.

In code, this functionality would work similarly to the way the header injection works for direct API requests.

I'd suggest that the following order of precedence is implemented for the API (lowest to highest):

  1. Netbox wide NAPALM configuration settings
  2. NAPALM settings pulled from per-device secrets
  3. NAPALM settings sent as header information to the API on a per-request basis

This would mean that the existing functionality would continue to work, while allowing the functionality described above.

Use Case

As an MSP, we use Netbox to manage information of not just our own internal network, but our customer's also. Many of these customers have a host which we can SSH to, to access their internal networks (as an illustration, we have Zabbix proxies running on these hosts to collect monitoring data for each customer and send it back). Similarly, many of these customer networks are not directly accessible from the host running Netbox, but are accessible from that host via using SSH to proxy requests and commands.

Allowing support for the insertion of X-NAPALM- headers into the requests sent via the Netbox UI to the REST API (and then to NAPALM) would allow us to get information of our customer's devices shown under the Status and LLDP Neighbour tabs, which does not currently work. Having this information (particularly the LLDP Neighbour details) would greatly help us keep our network configuration and documentation accurate.

I've already confirmed that specifying a username, password and SSH file is all we need to achieve this (we can deploy SSH keys for secure and password-less access via a configuration management tool) so that NAPALM can connect. I've been able to use NAPALM at the Python CLI to connect from our 'central' host directly to a customer device through an SSH proxy using the following:

driver = napalm.get_network_driver("junos")
device = driver(
    hostname="10.1.0.34",
    username="MyUserName",
    password="MyGreatAndSecurePassword",
    optional_args={
        "ssh_config_file": './test_sshconfig',
    },
)

Database Changes

I don't believe there would be a requirement for any database changes.

External Dependencies

Also unaware that there's additional libraries needed.

Originally created by @jameskirsop on GitHub (Aug 11, 2020). ### Environment * Python version: 3.7 * NetBox version: 2.8.5 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality NB. This is an extension of the work that was proposed (and completed) in #2113 and is written in response to #4975. When a request is made to NAPALM, if there are secrets with the following names attached to the device being queried, they are inserted into the parameters sent (as per #2113) so that additional information can be supplied to the request: - X-NAPALM-Username - X-NAPALM-Password - X-NAPALM-ssh_config_file _Indeed, it could be useful if all of the Napalm optional arguments could be passed in the headers, but that is outside the scope of this Feature Request._ In code, this functionality would work similarly to the way the [header injection works](https://github.com/netbox-community/netbox/blob/8709c50a9e62cfe5d1adafa84b1098ed4689c886/netbox/dcim/api/views.py#L425) for direct API requests. I'd suggest that the following order of precedence is implemented for the API (lowest to highest): 1. Netbox wide NAPALM configuration settings 2. NAPALM settings pulled from per-device secrets 3. NAPALM settings sent as header information to the API on a per-request basis This would mean that the existing functionality would continue to work, while allowing the functionality described above. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case As an MSP, we use Netbox to manage information of not just our own internal network, but our customer's also. Many of these customers have a host which we can SSH to, to access their internal networks (as an illustration, we have Zabbix proxies running on these hosts to collect monitoring data for each customer and send it back). Similarly, many of these customer networks are not directly accessible from the host running Netbox, but are accessible from that host via [using SSH to proxy requests and commands](https://pynet.twb-tech.com/blog/automation/netmiko-proxy.html). Allowing support for the insertion of `X-NAPALM-` headers into the requests sent via the Netbox UI to the REST API (and then to NAPALM) would allow us to get information of our customer's devices shown under the Status and LLDP Neighbour tabs, which does not currently work. Having this information (particularly the LLDP Neighbour details) would greatly help us keep our [network configuration and documentation accurate](https://www.youtube.com/watch?v=ha2kNRiO_Ng&t=7m27s). I've already confirmed that specifying a username, password and SSH file is all we need to achieve this (we can deploy SSH keys for secure and password-less access via a configuration management tool) so that NAPALM can connect. I've been able to use NAPALM at the Python CLI to connect from our 'central' host directly to a customer device through an SSH proxy using the following: ``` driver = napalm.get_network_driver("junos") device = driver( hostname="10.1.0.34", username="MyUserName", password="MyGreatAndSecurePassword", optional_args={ "ssh_config_file": './test_sshconfig', }, ) ``` <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes I don't believe there would be a requirement for any database changes. <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies Also unaware that there's additional libraries needed.
adam added the type: featurepending closurestatus: under review labels 2025-12-29 18:32:20 +01:00
adam closed this issue 2025-12-29 18:32:20 +01:00
adam commented 2025-12-29 18:32:20 +01:00
Author
Owner
Copy Link

@jameskirsop commented on GitHub (Aug 11, 2020):

I've forked and created a branch that addresses this feature request for review. It's a pretty minor change in context of the amount of code written. Would appreciate feedback from maintainers before creating a PR.

One hesitation I have is many of the optional_args probably don't need to be stored as Secrets, however for the sake of keeping the x-napalm- headers in the one location it makes sense to store them all as secrets against a device.

@jameskirsop commented on GitHub (Aug 11, 2020): I've forked and created [a branch that addresses this feature request](https://github.com/jameskirsop/netbox/commit/696cc7ce78be10bcb2b8d42dd972f56cb4416c62) for review. It's a pretty minor change in context of the amount of code written. Would appreciate feedback from maintainers before creating a PR. One hesitation I have is many of the `optional_args` probably don't need to be stored as Secrets, however for the sake of keeping the `x-napalm-` headers in the one location it makes sense to store them all as secrets against a device.
adam commented 2025-12-29 18:32:20 +01:00
Author
Owner
Copy Link

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

Blocked by #4346. Will revisit this once the secrets framework as a whole has been re-evaluated.

@jeremystretch commented on GitHub (Aug 18, 2020): Blocked by #4346. Will revisit this once the secrets framework as a whole has been re-evaluated.
adam commented 2025-12-29 18:32:20 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 11, 2022):

Revisiting this after some time. I'm not this is relevant any more as the secrets functionality has been moved out of NetBox core.

@jeremystretch commented on GitHub (May 11, 2022): Revisiting this after some time. I'm not this is relevant any more as the secrets functionality has been moved out of NetBox core.
adam commented 2025-12-29 18:32:21 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 11, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jul 11, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:32:21 +01:00
Author
Owner
Copy Link

@jameskirsop commented on GitHub (Jul 20, 2022):

@jeremystretch, whilst I agree secrets have been moved out of the core, the issue of how we integrate them and other pieces of non-secret data with NAPALM, which is still part of the core as fas a I can tell, remains.

We still don't have a good way of passing parameters/optional arguments to NAPALM on a per-device or per-location/org mapping. And in a situation when some of these details will change depending on the devices' context, it would be helpful to have.

@jameskirsop commented on GitHub (Jul 20, 2022): @jeremystretch, whilst I agree secrets have been moved out of the core, the issue of how we integrate them and other pieces of non-secret data with NAPALM, which is still part of the core as fas a I can tell, remains. We still don't have a good way of passing parameters/optional arguments to NAPALM on a per-device or per-location/org mapping. And in a situation when some of these details will change depending on the devices' context, it would be helpful to have.
adam commented 2025-12-29 18:32:21 +01:00
Author
Owner
Copy Link

@jameskirsop commented on GitHub (Aug 24, 2022):

@jeremystretch, I'd appreciate a response to my previous comment before you closed this issue.

I strongly believe that covering this use case as a part of the core would be beneficial to a number of Netbox users - particularly those who are MSP's and managing a diverse range of customers/organisations and hardware.

@jameskirsop commented on GitHub (Aug 24, 2022): @jeremystretch, I'd appreciate a response to my previous comment before you closed this issue. I strongly believe that covering this use case as a part of the core would be beneficial to a number of Netbox users - particularly those who are MSP's and managing a diverse range of customers/organisations and hardware.
adam commented 2025-12-29 18:32:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 25, 2022):

This issue has been closed as stale per the message above in accordance with our issue lifecycle policy.

I strongly believe that covering this use case as a part of the core would be beneficial to a number of Netbox users

Unfortunately you are the only person to have commented on the feature request in any substantial way in the two years it has been open, hence it going stale.

@jeremystretch commented on GitHub (Aug 25, 2022): This issue has been closed as stale per the message above in accordance with our [issue lifecycle policy](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md#issue-lifecycle). > I strongly believe that covering this use case as a part of the core would be beneficial to a number of Netbox users Unfortunately you are the only person to have commented on the feature request in any substantial way in the two years it has been open, hence it going stale.
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 pending closure status: under review type: feature
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#3964
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?