Open PieterL75 opened 1 month ago
It will help with a snip of config as well as a suggestion for a data model to do this. Notice we have ipv4_acls
in eos_designs
which may or may not be usable for this?
This is what I would like to able to generate :
# eos_config
- name: SEC-COPP_STRICT-V4-IN
# This acl is based on the default-control-plane-acl. https://arista.my.site.com/AristaCommunity/s/article/default-control-plane-acl-explained
# Removed protocols: tcp/telnet, tcp/www, tcp/snmp, tcp/netconf-ssh, tcp/gnmi, udp/nootps, udp/bootpc, udp/ntp, udp/ptp-event, udp/ptp-general, tcp/5900-5910
# tcp/ssh, tcp/https and udp/snmp are limited within the service using vrf specific ACLs
# routing protocols are limited by dynamic ACLs based on neighbours.
counters_per_entry: true
sequence_numbers:
- sequence: 10
action: permit icmp any any
- sequence: 20
action: permit ip any any tracked
- sequence: 30
<snipped>
- sequence: 290
action: permit udp any eq lsp-ping any
# design var
default_copp_acl: SEC-COPP_STRICT-V4-IN
If then a VRF is defined in the NETWORK_SERVICES, each device where the VRF is applied should have this config is generated:
control_plane:
ipv4_access_groups:
- acl_name: SEC-COPP_STRICT-V4-IN
vrf: VRF1
- acl_name: SEC-COPP_STRICT-V4-IN
vrf: VRF2
and final config is:
system control-plane
ip access-group SEC-COPP_STRICT-V4-IN vrf VRF1
ip access-group SEC-COPP_STRICT-V4-IN vrf VRF2
if a VRF requires the default copp acl, then it can be overriden with a structured_config
vrfs:
- name: VRF3
structured_config:
system:
control_plane:
ipv4_access_groups:
- acl_name: default-control-plane-acl
vrf: VRF3
Same should got vor IPv6 ofcourse
Enhancement summary
This request is to create a design variable, that sets the default control-plane-acl and applies that to all (and default) vrf (ipv4 and ipv6) If a VRF requires more access, then it can use the structured_config to override that default
Which component of AVD is impacted
eos_designs
Use case example
The default-control-plane-acl is too open for our company standards. (allowing telnet is a red flag, even if the service is not running) This setting will lockdown the control plane more strict on a structured way.
Describe the solution you would like
A standard way to secure the control plane on all vrf's, and an exception to open more access.
Describe alternatives you have considered
We can create a more strict one, but then we need to apply that to each VRF that is added to the system. Currently we set that acl using structured_config int he 'vrfs', but it can be forgotten, opening access that is unwanted.
Additional context
No response
Contributing Guide