starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-13 13:53:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Allow custom scripts to specify which users and/or groups are allowed to run them #7794

New Issue
Closed
opened 2025-12-29 20:28:16 +01:00 by adam · 5 comments
adam commented 2025-12-29 20:28:16 +01:00
Owner
Copy Link

Originally created by @BarbarossaTM on GitHub (Mar 24, 2023).

NetBox version

v.3.4.6

Feature type

New functionality

Proposed functionality

Allow custom scripts to specify which users and/or groups are allowed to run them and bail out of the user isn't allowed.

Use case

We are starting to write a number of custom scripts, either to be run by operators via the WebUI or via the API, and want to enforce RBAC to scripts as we do for manual changes to the data (models).

The overall intention here is to codify processes, make sure they are followed, data is validated before put into NetBox, and also reduce toil from operators by automating multi-step tasks. One example would be to set up a link between two devices, meaning set up the Cable, create a LAG, assign IPs left and right (on the right interfaces), make sure the IPs are in the same subnet, etc. and in the future adding more steps into this process, like allocating the next-free prefix, choose ports, etc.

To keep our role-based permission managed in check we want to be able to defined who is allowed to run each script. To the best of my knowledge this isn't easily possible today.

Database changes

None.

External dependencies

None.

Originally created by @BarbarossaTM on GitHub (Mar 24, 2023). ### NetBox version v.3.4.6 ### Feature type New functionality ### Proposed functionality Allow custom scripts to specify which users and/or groups are allowed to run them and bail out of the user isn't allowed. ### Use case We are starting to write a number of custom scripts, either to be run by operators via the WebUI or via the API, and want to enforce RBAC to scripts as we do for manual changes to the data (models). The overall intention here is to codify processes, make sure they are followed, data is validated before put into NetBox, and also reduce toil from operators by automating multi-step tasks. One example would be to set up a link between two devices, meaning set up the Cable, create a LAG, assign IPs left and right (on the right interfaces), make sure the IPs are in the same subnet, etc. and in the future adding more steps into this process, like allocating the next-free prefix, choose ports, etc. To keep our role-based permission managed in check we want to be able to defined who is allowed to run each script. To the best of my knowledge this isn't easily possible today. ### Database changes None. ### External dependencies None.
adam added the type: featurepending closurestatus: under review labels 2025-12-29 20:28:17 +01:00
adam closed this issue 2025-12-29 20:28:17 +01:00
adam commented 2025-12-29 20:28:17 +01:00
Author
Owner
Copy Link

@BarbarossaTM commented on GitHub (Mar 24, 2023):

Our current approach is a wrapper class for our Scripts which does the checking. I think it might be worth having this as part of the NetBox Script class, so this available for everyone. Maybe the same is even relevant for Reports?

Our current approach looks like this:

from extras.scripts import Script

from utilities.exceptions import AbortScript

from django.contrib.auth.models import User

class ACMEScript(Script):
    """Common wrapper class for all ACME NetBox scripts.

    No script should directly inherit from this class, but rather from
    - ACMEUIScript for interactive scripts, or
    - ACMEAPIScript for scripts to be called via the API
  
    This class handles permission handling and acts according to the presence (or absence)
    of the following class-level variables:
    - require_user_and_group (bool): If True, validate user and group list, by default one is enough.
    - allowed_users (list): List of usernames allowed to execute this scripts
    - allowed_groups (list): List of groups (of users) allowed to execute this scripts
    """

    def validate_permissions(self):
        # Lots of checks here, raise Exception if user/group is not allowed

I'm happy to open a PR to add this to the base class if this is deemed useful :-)

@BarbarossaTM commented on GitHub (Mar 24, 2023): Our current approach is a wrapper class for our Scripts which does the checking. I think it might be worth having this as part of the NetBox Script class, so this available for everyone. Maybe the same is even relevant for Reports? Our current approach looks like this: ``` from extras.scripts import Script from utilities.exceptions import AbortScript from django.contrib.auth.models import User class ACMEScript(Script): """Common wrapper class for all ACME NetBox scripts. No script should directly inherit from this class, but rather from - ACMEUIScript for interactive scripts, or - ACMEAPIScript for scripts to be called via the API This class handles permission handling and acts according to the presence (or absence) of the following class-level variables: - require_user_and_group (bool): If True, validate user and group list, by default one is enough. - allowed_users (list): List of usernames allowed to execute this scripts - allowed_groups (list): List of groups (of users) allowed to execute this scripts """ def validate_permissions(self): # Lots of checks here, raise Exception if user/group is not allowed ``` I'm happy to open a PR to add this to the base class if this is deemed useful :-)
adam commented 2025-12-29 20:28:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 28, 2023):

In NetBox v3.5, report and script modules will manifest as database objects, which opens the door for object-based permissions controls. This would only be granular to the module and not individual reports/scripts, but that may be sufficient.

@jeremystretch commented on GitHub (Mar 28, 2023): In NetBox v3.5, report and script modules will manifest as database objects, which opens the door for object-based permissions controls. This would only be granular to the module and not individual reports/scripts, but that may be sufficient.
adam commented 2025-12-29 20:28:18 +01:00
Author
Owner
Copy Link

@ziggekatten commented on GitHub (Mar 31, 2023):

Our current approach is a wrapper class for our Scripts which does the checking. I think it might be worth having this as part of the NetBox Script class, so this available for everyone. Maybe the same is even relevant for Reports?

Our current approach looks like this:


from extras.scripts import Script



from utilities.exceptions import AbortScript



from django.contrib.auth.models import User



class ACMEScript(Script):

    """Common wrapper class for all ACME NetBox scripts.



    No script should directly inherit from this class, but rather from

    - ACMEUIScript for interactive scripts, or

    - ACMEAPIScript for scripts to be called via the API

  

    This class handles permission handling and acts according to the presence (or absence)

    of the following class-level variables:

    - require_user_and_group (bool): If True, validate user and group list, by default one is enough.

    - allowed_users (list): List of usernames allowed to execute this scripts

    - allowed_groups (list): List of groups (of users) allowed to execute this scripts

    """



    def validate_permissions(self):

        # Lots of checks here, raise Exception if user/group is not allowed

I'm happy to open a PR to add this to the base class if this is deemed useful :-)

This. We do the same by matching a permission to a value of the Meta in each class, thus making it possible to set permissions on class level. Works like a charm.

@ziggekatten commented on GitHub (Mar 31, 2023): > Our current approach is a wrapper class for our Scripts which does the checking. I think it might be worth having this as part of the NetBox Script class, so this available for everyone. Maybe the same is even relevant for Reports? > > > > Our current approach looks like this: > > > > ``` > > from extras.scripts import Script > > > > from utilities.exceptions import AbortScript > > > > from django.contrib.auth.models import User > > > > class ACMEScript(Script): > > """Common wrapper class for all ACME NetBox scripts. > > > > No script should directly inherit from this class, but rather from > > - ACMEUIScript for interactive scripts, or > > - ACMEAPIScript for scripts to be called via the API > > > > This class handles permission handling and acts according to the presence (or absence) > > of the following class-level variables: > > - require_user_and_group (bool): If True, validate user and group list, by default one is enough. > > - allowed_users (list): List of usernames allowed to execute this scripts > > - allowed_groups (list): List of groups (of users) allowed to execute this scripts > > """ > > > > def validate_permissions(self): > > # Lots of checks here, raise Exception if user/group is not allowed > > ``` > > > > I'm happy to open a PR to add this to the base class if this is deemed useful :-) This. We do the same by matching a permission to a value of the Meta in each class, thus making it possible to set permissions on class level. Works like a charm.
adam commented 2025-12-29 20:28:18 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 30, 2023):

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 (Jun 30, 2023): 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 20:28:18 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 31, 2023):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Jul 31, 2023): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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#7794
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?