Use the REST API to Add ACL Tags to a Switch (Use Case)
Read this topic to understand the role Access Control Lists (ACLs) play in API access control.
You can use Access Control Lists (ACLs) in the API to allow or deny traffic between clients on a connected switch. You must configure separate rules for both inbound and outbound traffic. ACLs are mainly used to control intra-VLAN traffic, whereas any inter-VLAN traffic is filtered by the stateful rules of the router or firewall.
Add ACL Tags to a Switch
In the Mist API, you can apply ACLs to all switches in a site, rather than having to manage ACLs at the device level. You can assign permissions to switches using ACL policies and ACL tags. ACL tags enable you to define permissions within them, then you assign the tags where access control is needed in the policy. In other words, ACL tags are reusable network objects that can be referenced in ACL policies.
Let's say you want to control the traffic that will be forwarded by a switch, for example, if you want to allow or deny certain traffic from a wired client to the rest of the network. To do this, you can add ACL tags in the ACL policy to control the allowed or denied traffic sources and destinations from which the switch is allowed to forward traffic.
You can set these rules in the API by adding the source and destination tags within
the acl_tags object referenced within the
acl_policies and specify the action you want the switch to take
(allow or deny) when the traffic matches the ACL tags. Remember, you must configure
separate rules for both inbound and outbound traffic due to the stateless nature of
ACLs.
You can configure this from the Mist API Reference by navigating to Update Site Device > Body > Device Switch.
Below is a sample payload of the ACL policy configuration and the definitions for each of the ACL tags are featured therein:
{
// Defines the ACL Tags - these are reusable network objects that can be referenced in policies
"acl_tags": {
"iot_device": { // Defines the Source ACL Tag - represents IoT devices
"type": "port_usage", // Type indicates this tag is based on port profile usage
"port_usage": "iot", // On which Port Profiles the ACL must be applied
"subnets": [ // Source IP addresses/ranges that match this tag
"192.168.1.30/32"
],
"specs": [ // Additional specifications for traffic matching
{}
]
},
"iot_network": { // Defines the Destination ACL Tag - represents allowed IoT services
"type": "resource", // Type indicates this tag represents a network resource/destination
"subnets": [ // Destination IP addresses/ranges for this tag
"192.168.1.0/24"
],
"specs": [ // Specifies the traffic characteristics - what protocols/ports are allowed
{
"protocol": "tcp",
"port_range": "1883"
}
],
"ether_types": [] // Ethernet frame types (empty means all types allowed)
}
},
// Defines the ACL Policies - rules that govern traffic flow
"acl_policies": [
{
"name": "iot_policy",
"src_tags": [ // Source tags that this policy applies to
"iot_device" // References the iot_device tag defined above
],
"actions": [ // What actions to take when traffic matches the source tags
{
"dst_tag": "iot_network", // Destination tag for this action
"action": "allow" // Action to take (allow/deny) for matching traffic
},
{
"dst_tag": "any", // any is implicitly defined as all destinations
"action": "deny" // Action to take (allow/deny) for matching traffic
}
]
}
]
}For more information on the available ACL tags you can add, see Acl Tag.