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 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); the 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); the 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. The 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; the 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
IP Version

  • IPv4

  • IPv6

  • IPv4-IPv6 Dual Stack
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.

User interface of a network management application showing tabs like Dashboard, Analytics, Staged, and Active. The Staged tab, Policies section, and Security Policies sub-section are highlighted. Security Policies table includes columns for Name, Source Application Point, Destination Application Point, Rule Count, Rule Conflicts, Tags, Enabled, Errors, and Actions, with example data. Create Security Policy button and search and filter options are visible.

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. Starting in HPE Networking Apstra Data Center Director version 6.2.0, on NX-OS, EOS, Junos OS, and Junos OS Evo devices, you can select the IP version you want to use. You can choose one of the following types of IP versions: IPv4, IPv6, or IPv4-IPv6 Dual Stack.
    User interface for creating a security policy with fields for name and description set to test, enabled toggle on, and IP version set to IPv4-IPv6 Dual Stack.

    The sysem automatically filters and extracts only the relevant subnets that match the chosen IP version from the source and destination application points. The system then generates the appropriate Access Control List (ACL) rules.

    If an application point doesn't have any configured objects for the selected IP version, a validation error is raised as a build error.

    Policy Errors: Issues with policy test1 where destination and source application points are linked to empty IPv6-enabled object sets.
  4. Select a source point type, and enter the source point.
  5. Select a destination point type, and enter the destination point.
  6. Click Add Rule, then enter a name and (optional) description.
  7. Select an action from the drop-down list (Deny, Deny & Log, Permit, Permit & Log).
  8. Select a protocol from the drop-down list (TCP, UDP, IP ICMP).
  9. 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).
  10. 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.
  11. You can adjust the rule order by clicking the Move up or Move Down buttons in each rule.
  12. 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.

See Also