Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Security Policies

Security Policy Overview

Endpoint connectivity is determined by reachability (the correct forwarding state in the network) and security (connectivity must be permitted). Policies must be specified between L2 and L3 domains and between more granular L2/L3 IP endpoints. Security policies allow you to permit or deny traffic between the more granular endpoints. They control inter-virtual network traffic (ACLs on SVIs) and external-to-internal traffic (ACLs in border leaf devices, external endpoints only). ACLs are rendered in the appropriate device syntax and applied on enforcement points. Adding a new VXLAN Endpoint (for example, adding a rack or adding a leaf to a virtual network) automatically places the ACL on the virtual network interface. Adding a new generic system External Connectivity Point (ECP) (enforcement point) automatically places ACL for external endpoint groups. You can apply security policies to Layer 2 IPv4-enabled blueprints (IPv6 is not supported). For supported devices, refer to the Connectivity (from Leaf Layer) table in the Feature Matrix in the Reference section.

Security policies consist of a source point (subnet or IP address), a destination point (subnet or IP address), and rules to allow or deny traffic between those points based on protocol. Rules are stateless, meaning responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa).

Rules can include traffic logging. The ACL is configured to log matches using whatever mechanism is supported on the device. Log configuration is local to the network device; It's not on the Apstra server. Parsing these logs is outside the scope of this document.

For a bi-directional security policy, you would create two instances of the policy, one for each direction.

You can apply more than one policy to each subnet/endpoint, which means the ordering of rules has an impact on behavior. An implicit hierarchy exists between routing zones, virtual networks, and IP endpoints, so you must consider how policies are applied at different levels of hierarchy. When one rule's match set contains the other's match set (full containment), the rules can conflict. You can set the rules to execute more specific rules first (“exception” focus/mode) or less specific first (“override” focus/mode).

Rules can also conflict when there is a full containment situation between the rules but the action is the same. In this case, there is potential for compression by using the less specific rule, and the more specific rule becomes a “shadow” rule. When conflicting rules are detected, you are alerted and shown the resolution.

A few cases where conflicting rules are identified are described below:

  • Rules in policies between different pairs of IP endpoints (even if one is common to both pairs) are non-overlapping given that the pairs of IP addresses are different. This causes a disjoint match set from a source IP / destination IP perspective (different “IP signature”).
  • Rules in policies between the same IP endpoints can overlap fields (such as destination port); Apstra software checks for this.
  • Rules in policies between different pairs of virtual networks (even if one virtual network is common to both pairs) are non-overlapping given that the pairs of subnets are different. This causes a disjoint match set from the source IP / destination IP perspective (different “IP signature”).
  • Rules in policies between the same virtual networks can overlap fields (such as destination port); Apstra software checks for this.
  • When IP endpoint groups are used, they result in a set of IP endpoint pairs so the above discussion related to IP endpoint pairs applies.
  • Rules in policies between a pair of IP endpoints and a pair of parent virtual networks have containment from an IP signature perspective. Apstra software analyzes destination port / protocol overlap and classifies it as full-containment or non-full-containment conflict.
  • Rules in policies between a pair of IP endpoints and a pair of virtual networks where at least one virtual network is not parent are non-conflicting (different "IP signature").
  • Rules in policies between a pair of IP endpoints and an IP endpoint - virtual network pair where the virtual network is a parent have full containment from an IP signature perspective; Apstra software analyzes the remaining fields.
  • Rules in policies that contain external IP endpoints or endpoint groups must be analyzed from an IP signature perspective as external points are not bound by any hierarchical assumptions.
  • A routing zone is a set of virtual networks and IP endpoints so the above discussions apply.

Endpoints are not supported in security policies when:

  • Source point is an external endpoint or external endpoint group
  • Destination point is internal (internal endpoint, internal endpoint group, virtual network, routing zone)

To make composition tractable, both from an analysis point of view as well as from comprehending the resulting composition it may be useful to limit the number of security policies that may apply to any given endpoint/group.

Security Policy Parameters

Security policies include the following details:

Parameter Description
Name 32 characters or fewer, underscore, dash and alphanumeric characters only
Description optional
Enabled
  • ON to enable security policy (default)
  • OFF to disable security policy
Tags optional
Source Point Type
  • Internal Endpoint (associated with VNs - contain IP /32 address)
  • External Endpoint (contains /32 or subnet)
  • External Endpoint Group
  • Internal Endpoint Group
  • Virtual Network (contains subnet)
  • Routing Zone (logical collection of all virtual networks and internal IP endpoints)
Source Point
  • Internal Endpoint
  • External Endpoint
  • External Endpoint Group
  • Internal Endpoint Group
  • Virtual Network
  • Routing Zone
Destination Point Type Source point (previously created)
Destination Point Destination point (previously created)
Rule Actions
  • Deny
  • Deny & Log
  • Permit
  • Permit & Log
Rule Protocols
  • TCP
  • UDP
  • IP
  • ICMP
Source Port For TCP and IP protocols
Destination Port For TCP and IP protocols

From the blueprint, navigate to Staged > Policies > Security Policies > Policies to go to security policies. You can create, clone, edit and delete security policies.

Create Security Policy

Before creating security policies, create routing zones, virtual networks, endpoints and endpoint groups, in that order. They are the basis for creating security policies.

To create security policies:

  1. From the blueprint, navigate to Staged > Policies > Security Policies > Policies and click Create Security Policy.
  2. Enter a name, and if you want the policy to be enabled leave the default. Otherwise, click the Enabled toggle to disable it.
  3. Select a source point type, and enter the source point.
  4. Select a destination point type, and enter the destination point.
  5. Click Add Rule, then enter a name and (optional) description.
  6. Select an action from the drop-down list (Deny, Deny & Log, Permit, Permit & Log).
  7. Select a protocol from the drop-down list (TCP, UDP, IP ICMP).
  8. If you selected TCP or UDP, enter a port (or port range) for source and destination. (If you created TCP/UDP port aliases, they appear in the drop-down list).
  9. To add another rule, click Add Rule and configure as above.
    Note:

    To the right of the Add Rule button you can automatically create a blocklist-type policy by clicking Deny All or an allowlist-type policy by clicking Permit All.
  10. You can adjust the rule order by clicking the Move up or Move Down buttons in each rule.
  11. Click Create to stage the policy and return to the table view.

Policy Errors

  1. Check the security policy in the table view for errors, which are highlighted in red.
  2. To see details, click the Show errors button.
  3. When you resolve errors, the policy is no longer highlighted red and the Errors field is blank.

To activate staged changes, commit them to the blueprint.

Edit Security Policy

  1. From the left navigation menu, navigate to Staged > Policies > Security Policies > Policies and click the Edit button for the policy to edit.
  2. Make your changes.
  3. Click Edit to stage the changes and return to the table view.

Delete Security Policy

  1. From the left navigation menu, navigate to Staged > Policies > Security Policies > Policies and click the Delete button for the policy to delete.
  2. Click Delete to stage the deletion and return to the table view.

Security Policy Conflicts

From the blueprint, navigate to Staged > Policies > Security Policies > Conflicts to see any conflicts that have been detected (Rule Conflicts column). Conflicts are resolved automatically whenever possible. By default, more specific policies are applied before less specific ones, but you can change these security policy settings. To see conflict details, click the icon in the Rule Conflicts column.

If the conflict was resolved automatically, Resolved by AOS appears in the Status column.

Security Policy Settings

You can configure how you want to resolve conflicts and whether to permit or deny traffic.

  1. From the blueprint, navigate to Staged > Policies > Security Policies > Settings.
  2. Select options as appropriate.
    • Conflict resolution
      • More specific first - more specific IP policy is used (default)
      • More generic first - less specific IP policy is used
      • Disabled - disables conflict resolution
    • Default action
      • Permit - permits traffic (default)
      • Permit & Log - permits traffic and logs it
      • Deny - denies traffic
      • Deny & Log - denies traffic and logs it
  3. Click Save Changes to stage the changes.

To activate staged changes, commit them to the blueprint.