Extend permission constraint feature to support Custom Scripts

[gmurman770]

Hello, community!

Currently we can give (or not) users permissions to run Custom Scripts. And it's great!
But I think that it's a common case when you have some really dangerous scripts (that triggers serious network changes for ex.) that you don't want to share with tech support team or managers. So we definitely need to separate the access here.

The reason we can not use constraints in permissions to achieve that currently is that:
Script is a "Dummy model used to generate permissions for custom scripts. Does not exist in the database."
So currently we can not filter Custom Scripts.

But may be we can hack it some how??:)

Thanks) Have a good day everybody!

[candlerb]

A simple hack would be for the custom script itself to check your policy, and refuse to run for unauthorized users.

See: https://netbox.readthedocs.io/en/stable/additional-features/custom-scripts/#accessing-request-data

Of course, all scripts are still visible to all users.

[gmurman770]

Wow I missed that! Thx, I'll give that approach a try :)

[ziggekatten]

We had to add our own extra stuff on top, making us able to set permission on class level in the scripts.

Core of the soulution is that we have a 'permission' property in the class Meta with a permission name(in effect filename.classname), and a check that validates that a user are member of that permission.

Yes, all can see the scripts, but will get an 'not authorized' if not member of that permission.

To simplify deployment of scripts with new classes, we always create the needed permission at first run if it does not exist, so we only need to add users/groups to the permissions afterward.

Works quite well.

[gmurman770]

@ziggekatten Thank you for the answer!

Core of the soulution is that we have a 'permission' property in the class Meta with a permission name(in effect filename.classname), and a check that validates that a user are member of that permission.

Sorry, but it's not clear for me how to implement that. Do we need to create our own CustomScript class based on core Script, but with extra logic?
I decided to create a decorator in separate module for the run function based on @candlerb answer, check this out:

def check_permission(groups: List[str]):
    """
    Constrains access to Custom Scripts.
    """
    def decorator(function):
        @functools.wraps(function)
        def wrapper(*args, **kwargs):
            user = User.objects.get(username=args[0].request.user.username)
            if user.groups.filter(name__in=groups).exists():
                return function(*args, **kwargs)
            
            args[0].log_failure(f"**Access Denied**")
        return wrapper
    return decorator

So

@check_permissions(groups=['fellowship-of-the-ring'])
def run(self, data, commit):
    # reboot all core routers

[ziggekatten]

Your solution is similar as mine. I use a common function, you a decorator. The difference is that we have a more granular setup, where each class in the script have its own permissions, thus we also pass the class name.