[Feature]: Assign a ACL to multiple devices

[balpoint]

NetBox version

v3.3.5

Feature type

Add a function

Proposed functionality

Can we give the plugin a option to assign a ACL to multiple devices so that we can assign it to multiple interfaces accross multiple devices if needed.

Use case

It will clean up number of acl's that need to be created within the netbox plugin in order to apply a certain ACL to multiple devices.

External dependencies

No response

[github-actions]

Thanks for opening this Issue! We really appreciate the feedback & testing from users like you!

[ryanmerolle]

@abhi1693 please chime in. I am totally not against this. I have the same use case.

BUT its not truly how the actual model works. @balpoint may be really strict on ACL names and ACL definitions, but that is not always the case. You could say "well then people should not associate that ACL to another device." But what do we do if someone intends to use the same exact ACL defintion on 2 different devices, then their peer or their replacement comes along and wonders why they cannot edit/split the ACL so that the ACL is now 2 different ACLs (one per device).

Long story short, if we do this, we may want a feature to allow users to "fork" the ACL thus breaking the relationship, but cloning all the ACL rule lines.

I guess this is a bigger can of worms, we need to think through is my point.

[abhi1693]

One way could be to do it like Contacts assignment to objects work. Basically, create another model which works like a glue to between the AccessList and related objects. Although, I'm not sure if that's the path we should take at the moment.

[ryanmerolle]

That's not a bad idea, but we would need to think about it some more. It's honestly more of an abstraction that does not exist on its own in a network.

[Kani999]

I've run into the same problem as @balpoint
We have an access list used on almost every device with the same name.
It's a little messy when a lot of "duplicates" is stored in the plugin.

But I guess I could use something as context_data for this.

[ryanmerolle]

I’m game for adding to the models for an abstraction.

We just need some ideas to allow users to define something like a standardized multi-device ACL. We also need a way to clone one of these ACLs to a single device ACL so that users can model the real world when they need to edit an ACL on a single device to be outside of the “standard.”

This sort of abstraction is not found anywhere currently in netbox or many (if any plugins) besides like config context. I’ll have some free time in August to think about this some more. In the meantime I’d be game for ideas, a draft of the model update, and even a PR.

[ryanmerolle]

The other approach could be to implement a template like approach. For example similar to devices and devicetypes. The template would apply only at creation.

What are everyone’s thoughts for the two approaches?

[Kani999]

The approach of "template-like" solutions does not seem right to me. It would create a massive amount of records on my side.
For example, if I have the same access list on 100 devices with 20 rules in them it would create 2000 standard rules which would be always the same. The editing would be a little bit of a pain (of course not via API).
There is a problem with the UI. If all "common access lists" are named the same, when it comes to selecting the ACL when assigning it to the interface it looks like this:

I like the idea of an @abhi1693 that suggests using an "access list assignment" model in which you could assign an ACL to a Device, Interface, or other models.

I think when it comes to "splitting" the common ACL like you described:

But what do we do if someone intends to use the same exact ACL definition on 2 different devices, then their peer or their replacement comes along and wonders why they cannot edit/split the ACL so that the ACL is now 2 different ACLs

But when you use "common access list" then the logic of "oh I will just edit this rule on this particular device" disrupts the logic of the "common access-list" and shouldn't be done. But If it comes, the common access list should be removed from the device and a new one (specific for the device) will be created which will have different rules in it.
If there would be an option to copy/clone the existing ACLs with the rules, it would be a great help.

That's just my opinion, maybe I'm missing something.

[ryanmerolle]

Option 1

@abhi1693 and I talk on slack a bit about this. The method he described is the first options I was poorly describing. Its a an approach that would STILL allow user to granularly map 1 ACL to device to model the real world because 1 device as no understanding of another device's ACL definitions, BUT ALSO introduce a new model to share across devices as your abstraction layer. From a user perspective this makes sense for me for the same reasons you mentioned @Kani999. It is still confusing because you would have 2 different types of associations.

Option 1 Variation

Another variation of that approach could be to edit the existing model and just have some sort of boolean/checkbox to signify the type of ACL (device or global).

Option 2

The template model is not ideal if you update NetBox using the UI only, but there is a few reasons why people might prefer the template model.

1. ACLs can be generated from the current template just like the real world. I have a design, and I apply at first build.
2. Like the real world, you can model the current state of ACLs applied to device
3. You can build scripts (we can even add to the plugin) that would show you where your applied ACLs differ from a template.

TLDR for this option is that it models the real world just like most of the NetBox core models. IE NetBox core is currently not a SDN controller that abstracts this sort of logic (for better or worse). The exception to this is really models like VLANs and config_context.

Final Thoughts

• We can hammer out the above and set a poll up.
• I am totally not biased to any option, just trying to represent them all (ie I would represent option 1 more if you said you liked option 2).
• I think NetBox/Nautobot/Device42/etc all do not handle abstractions well in their current state.

[Kani999]

@ryanmerolle Great summarization.
I would prefer option 1 from my point of view.

[balpoint]

Hello everyone,

As the person who initiated the feature request, I wanted to join the discussion again. It's fantastic to see the community coming together and brainstorming ways to improve this plugin with a wider range of methods. Kudos to everyone involved!

Regarding the ongoing discussion, I want to thank @ryanmerolle for summarizing the options discussed outside of the feature request. In my opinion, option 1 seems the most convenient and straightforward. By simply checking a box, we can make an Access Control List (ACL) global, allowing it to be applied to multiple interfaces across multiple devices. This approach would provide a one-to-many status for the ACL, streamlining its usage.

[cs-1]

Thanks for looking into this feature request. We have another use case for this: in fabric constructs (VXLAN + EVPN-BGP) you have L3 router interfaces for the same LAN on different machines but need to make sure that all ACLs are in sync. It would be great to be able to assign the same ACL to different machines. So I definitely second this FR.

[aoforb]

We have several thousand routers and switches with four standard ACLs.

• VTY line ACL allowing only hand full of management sources
• RP multicast address
• SNMP ACL
• NTP ACL

When I installed this plugin today, I was expecting to maintain only four ACLs on Netbox. The current model would mean MANY duplicated ACLs would need updating when the standard changes.

Glad to see some discussion on the topic, how far away is the solution?

[jfinkhaeuser]

This was more or less the initial feedback from my networking guys, that documenting the current state is one thing, but planning the intended state is also important.

From that point of view, you'd like to have ACLs that are not associated with any device, which you can build and then apply to multiple devices. An alternative would be to manage device groups, and give the ACLs e.g. a "planned" state (such as some other core functionality of netbox offers).