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

Plugin Installation via Backend UI #10922

New Issue
Closed
opened 2025-12-29 21:37:47 +01:00 by adam · 3 comments
adam commented 2025-12-29 21:37:47 +01:00
Owner
Copy Link

Originally created by @carlosalbertorg on GitHub (Mar 19, 2025).

NetBox version

v4.2.5

Feature type

New functionality

Proposed functionality

Description:

Currently, installing plugins in NetBox requires manual modification of the configuration.py file and deployment restarts. This process is cumbersome, especially in Kubernetes environments where configurations are managed via ConfigMaps.

We propose the addition of a feature that allows administrators to install and manage plugins directly via the NetBox backend UI, eliminating the need for manual configuration file edits and deployment restarts.

Proposed Solution:

Introduce a UI section under Administration -> Plugins to list installed plugins and allow new ones to be added.

Implement a mechanism to dynamically load/unload plugins without requiring a full service restart.

Store enabled plugins in the database instead of relying solely on configuration.py.

Optionally, allow plugin installation from an internal or external repository.

Challenges & Considerations:

Ensuring security and preventing execution of unauthorized code.

Managing plugin dependencies dynamically.

Handling database migrations required by plugins.

References:

Similar implementations in other Django-based applications.

Existing plugin management mechanisms in other infrastructure tools (e.g., Grafana, Jenkins).

Would love to hear thoughts from the community and maintainers on the feasibility of this feature!

Use case

This feature would be particularly beneficial for:

Administrators managing NetBox in cloud environments (e.g., Kubernetes, Docker, etc.).

Users who lack direct file system access but need to enable/disable plugins.

Streamlining the deployment process, reducing downtime and human error.

Database changes

If this proposal includes storing enabled/disabled plugins in the database, potential changes might include:
✅ Adding a new table to store information about installed plugins.
✅ Possible new columns in existing tables to support dynamic plugin activation/deactivation.
✅ Database migration scripts to apply these schema changes.

If no database changes are required:
❌ No changes to the database schema.

External dependencies

If the implementation requires external dependencies for downloading or managing plugins, you could mention:
✅ Possible use of an internal package manager for NetBox (e.g., integration with PyPI or private repositories).
✅ Dependency on a secure mechanism for validating and dynamically executing third-party code.

If no new external dependencies are needed:
❌ No new external dependencies required.

Originally created by @carlosalbertorg on GitHub (Mar 19, 2025). ### NetBox version v4.2.5 ### Feature type New functionality ### Proposed functionality Description: Currently, installing plugins in NetBox requires manual modification of the configuration.py file and deployment restarts. This process is cumbersome, especially in Kubernetes environments where configurations are managed via ConfigMaps. We propose the addition of a feature that allows administrators to install and manage plugins directly via the NetBox backend UI, eliminating the need for manual configuration file edits and deployment restarts. Proposed Solution: Introduce a UI section under Administration -> Plugins to list installed plugins and allow new ones to be added. Implement a mechanism to dynamically load/unload plugins without requiring a full service restart. Store enabled plugins in the database instead of relying solely on configuration.py. Optionally, allow plugin installation from an internal or external repository. Challenges & Considerations: Ensuring security and preventing execution of unauthorized code. Managing plugin dependencies dynamically. Handling database migrations required by plugins. References: Similar implementations in other Django-based applications. Existing plugin management mechanisms in other infrastructure tools (e.g., Grafana, Jenkins). Would love to hear thoughts from the community and maintainers on the feasibility of this feature! ### Use case This feature would be particularly beneficial for: Administrators managing NetBox in cloud environments (e.g., Kubernetes, Docker, etc.). Users who lack direct file system access but need to enable/disable plugins. Streamlining the deployment process, reducing downtime and human error. ### Database changes If this proposal includes storing enabled/disabled plugins in the database, potential changes might include: ✅ Adding a new table to store information about installed plugins. ✅ Possible new columns in existing tables to support dynamic plugin activation/deactivation. ✅ Database migration scripts to apply these schema changes. If no database changes are required: ❌ No changes to the database schema. ### External dependencies If the implementation requires external dependencies for downloading or managing plugins, you could mention: ✅ Possible use of an internal package manager for NetBox (e.g., integration with PyPI or private repositories). ✅ Dependency on a secure mechanism for validating and dynamically executing third-party code. If no new external dependencies are needed: ❌ No new external dependencies required.
adam added the type: feature label 2025-12-29 21:37:47 +01:00
adam closed this issue 2025-12-29 21:37:47 +01:00
adam commented 2025-12-29 21:37:47 +01:00
Author
Owner
Copy Link

@alehaa commented on GitHub (Mar 20, 2025):

Frankly, I do not like the idea of loading code dynamically. In my opinion, e.g. a prebuilt Docker container (or whatever is used for deployment) should contain the application as it is. Loading executable code dynamically would introduce auditing headaches, especially for plugins that have a large chance of breaking things (accidentally or mailiciously).

I think a better approach would be to use something like rolling releases. This would minimize downtime.

@alehaa commented on GitHub (Mar 20, 2025): Frankly, I do not like the idea of loading code dynamically. In my opinion, e.g. a prebuilt Docker container (or whatever is used for deployment) should contain the application as it is. Loading executable code dynamically would introduce auditing headaches, especially for plugins that have a large chance of breaking things (accidentally or mailiciously). I think a better approach would be to use something like rolling releases. This would minimize downtime.
adam commented 2025-12-29 21:37:47 +01:00
Author
Owner
Copy Link

@carlosalbertorg commented on GitHub (Mar 20, 2025):

Frankly, I do not like the idea of loading code dynamically. In my opinion, e.g. a prebuilt Docker container (or whatever is used for deployment) should contain the application as it is. Loading executable code dynamically would introduce auditing headaches, especially for plugins that have a large chance of breaking things (accidentally or mailiciously).

I think a better approach would be to use something like rolling releases. This would minimize downtime.

I understand the concerns about dynamically loading code, especially regarding security and auditing. However, many applications successfully implement plugin management systems without compromising security:

Grafana – Allows installing plugins dynamically via the UI, but only from its official repository or verified sources, ensuring security.
Jenkins – Provides a robust plugin management system with strict versioning, rollback capabilities, and administrative controls.

Here are some ways NetBox could achieve this safely:

Strict Permission Controls – Only administrators with specific privileges could install or enable plugins.
Code Signing & Verification – Plugins could require digital signatures from trusted sources before being loaded.
Rollback & Safety Mechanisms – If a plugin misbehaves, the system could automatically disable it or revert to a stable state.
Official Plugin Repository – Instead of allowing arbitrary code execution, NetBox could introduce a curated marketplace where only vetted plugins are available.

A well-implemented plugin manager would improve NetBox’s extensibility while maintaining security.

@carlosalbertorg commented on GitHub (Mar 20, 2025): > Frankly, I do not like the idea of loading code dynamically. In my opinion, e.g. a prebuilt Docker container (or whatever is used for deployment) should contain the application as it is. Loading executable code dynamically would introduce auditing headaches, especially for plugins that have a large chance of breaking things (accidentally or mailiciously). > > I think a better approach would be to use something like rolling releases. This would minimize downtime. I understand the concerns about dynamically loading code, especially regarding security and auditing. However, many applications successfully implement plugin management systems without compromising security: Grafana – Allows installing plugins dynamically via the UI, but only from its official repository or verified sources, ensuring security. Jenkins – Provides a robust plugin management system with strict versioning, rollback capabilities, and administrative controls. Here are some ways NetBox could achieve this safely: Strict Permission Controls – Only administrators with specific privileges could install or enable plugins. Code Signing & Verification – Plugins could require digital signatures from trusted sources before being loaded. Rollback & Safety Mechanisms – If a plugin misbehaves, the system could automatically disable it or revert to a stable state. Official Plugin Repository – Instead of allowing arbitrary code execution, NetBox could introduce a curated marketplace where only vetted plugins are available. A well-implemented plugin manager would improve NetBox’s extensibility while maintaining security.
adam commented 2025-12-29 21:37:48 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Mar 20, 2025):

This would be a fantastic addition but is such a huge and complex undertaking that it would require major commitment of resources and milestone planning.

@bctiemann commented on GitHub (Mar 20, 2025): This would be a fantastic addition but is such a huge and complex undertaking that it would require major commitment of resources and milestone planning.
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 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#10922
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?