Security Policies

Security Policy Overview

Security policies can be used on Layer 2 IPv4-enabled blueprints with Cisco NX-OS and Arista EOS physical network devices only. Ipv6-enabled blueprints cannot use security policies.

Apstra provides policy constructs to express security/segmentation intent with different levels of granularity. Granularity level is a function of reference design, but policy constructs are able to express a wide range of granularity levels.

With security policies you can simplify security management when using multiple vendors. You can also isolate virtual machines and control the allowed application flows between virtual networks.

To add granularity to your security policies you add endpoints. Endpoint connectivity is determined by reachability (the correct forwarding state in the network) and security (the policy must allow connectivity). Specifically, you must specify security policies between L2 and L3 domains (already modeled in Apstra) and between more granular L2/L3 IP endpoints.

You can specify a wide range of granularity levels.

Endpoints/groups that can be subject to security policies are as follows:

  • Virtual networks (contain subnet)
  • Internal IP endpoints associated with virtual networks (contain IP /32 address)
  • Internal IP endpoint groups
  • External IP endpoints (contain /32 or subnet)
  • External IP endpoint groups
  • Security zone (logical collection of all virtual networks and internal IP endpoints)

You can associate one or more security policy with endpoints/groups. You can indicate if you want to log actions taken by specific rules.

Policy controls traffic in and out of the endpoint/group to which it is applied, in this case, the subnet or IP endpoint. Policy is expressed via “policy” node type, which contains the description of the policy and its association with endpoints/groups using relationships “from” and “to”, indicating the directionality. For a bi-directional security policy, two instances of the policy must be created, one for each direction. A policy contains a list of rules. An actual rule consists of 5-tuple (Source IP, Destination IP, Source Port, Destination Port, Protocol) and an action (deny, deny+log, allow, allow+log, log_only). Each subnet/IP endpoint can have one or more security policies applied to it.

Source IP and Destination IP are derived from properties of endpoints/groups attached to the policy.

Actions that include “logging” merely indicate that ACL is configured to log matches using whatever mechanism is supported on the device. Parsing these logs is outside scope of this document.

Policies consist of a set of rules that are stateless, meaning responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa).

Given that any endpoint can have more than one policy applied to it, it is important to deal with composition of these policies as ordering of rules has an impact on the behavior. In addition, there is implicit hierarchy between IPE, VN and SZ and policies applied at different levels of hierarchy also need to be considered from the composition perspective.

Composition (in this case ordering of rules) matters when applicable policies have “conflicting” rules which are defined as rules that have:

  • Overlapping match sets (there is a packet whose 5-tuple matches both rules)
  • Different action (for example “allow” vs “deny”)

Match sets are non-overlapping when the condition in at least one field in the 5-tuple is disjoint (non-overlapping) between the rules. Or to put it differently, match sets are overlapping when the conditions set in all the fields in the 5-tuple are overlapping.

When conflicting rules are present, there are two situations. First one is when one rule’s match set contains the other’s match set (full containment case). In this situation the ordering can be driven by a policy knob such as:

  • More specific rule is executed first (“exception” focus/mode)
  • Less specific executes first (“override” focus/mode)

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 less specific rule and more specific rule becomes what is called a “shadow” rule. Apstra alerts you at the time conflicting rules are detected and what is the resolution.

With its built-in hierarchy and the nature/semantics of endpoints/groups, Apstra helps to identify the presence of conflicting rules. A few cases are described below:

  • Rules in policies between different pairs of IPEs (even if one IPE is common to both pairs) are non-overlapping given that the pairs of IP addresses are different. This will cause disjoint match set from the sIP/dIP perspective (different “IP signature”).
  • Rules in policies between the same IPEs can overlap (such as Destination Port) fields and Apstra checks for this.
  • Rules in policies between different pairs of VNs (even if one VN is common to both pairs) are non-overlapping given that the pairs of subnets are different. This will cause disjoint match set from the Source IP / Destination IP perspective (different “IP signature”).
  • Rules in policies between the same VNs can overlap (such as Destination Port) fields and Apstra checks for this.
  • When IPECG are used they are essentially resulting in a set of IPE pairs so the above discussion related to IPE pairs applies.
  • Rules in policies between a pair of IPEs and pair of parent VNs have containment from IP signature perspective. Apstra analyzes Destination Port / Protocol overlap and classifies it as full-containment or non-full-containment conflict.
  • Rules in policies between pair of IPEs and pair of VNs where at least one VN is not parent are non conflicting (different IP signature).
  • Rules in policies between pair of IPEs and IPE-VN pair where VN is a parent have full containment from IP signature perspective so Apstra analyzes the remaining fields.
  • Rules in policies that contain EIPE or EIPECG have to be analyzed from IP signature perspective as external points are not bound by any hierarchical assumptions.
  • SZ is simply a set of VNs and IPE endpoints so the above discussions apply.

In order 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.

Apstra implements this feature by doing the following:

  • Automated creation and deployment of ACLs to Leaf switches (enforcement points).
  • Inter VLAN/VXLAN filtering.
  • Automated rule ordering and conflict resolution.
  • Config validation - useful for compliance.
  • Adding a new VXLAN Endpoint (ex. Add rack or add leaf to VN) automatically places the ACL on the VN interface.
  • Adding a new External Router External Connectivity Point (ECP) (enforcement point) automatically places ACL for external endpoint groups.

New in version 3.1: Apstra adds support for shadow relationship, user-defined conflict resolution, selective policy enablement, searching for networks impacted by policy, security policy search, per blueprint settings and views of policy changes between staged and active blueprints.

Note

Controls inter virtual network traffic (ACLs on SVIs) or external to internal traffic (ACLs in border leafs).

Note

For External Endpoints, ACL enforcement only on border leafs.

Policies

To go to security policies in the blueprint, navigate to Staged > Policies > Security Policies > Policies. (Image below is for version 3.1 which is slightly different from more recent versions.)

_images/security_policies_310.png

To see endpoints and subnets (if applicable), click on a Source Application Point or Destination Application Point.

_images/security_policy_endpoint_310.png

Creating Security Policy

  1. From the blueprint, navigate to Staged > Policies > Security Policies > Policies and click Create Security Policy.

    _images/security_policy_create_330.png
  2. Enter Common Parameters.

    Name

    32 characters or fewer, underscore, dash and alphanumeric characters only

    Description

    optional

    Enabled (as of version 3.1)

    ON to enable the policy (default)

    OFF to disable the policy

    Tags

    optional

  3. Enter Application Points.

    Source Point Type

    Internal Endpoint, External Endpoint, External Endpoint Group, Internal Endpoint Group, Virtual Network, Security Zone

    Source Point

    Source point (that was previously created) from the drop-down list

    Destination Point Type

    Internal Endpoint, External Endpoint, External Endpoint Group, Internal Endpoint Group, Virtual Network, Security Zone

    Destination Point

    Destination (that was previously created) from the drop-down list

  4. To create an allowlist-type policy in the Rules section, click Permit All to automatically create the rule.

  5. To create a blocklist-type policy in the Rules section, click Deny All to automatically create the rule.

  6. To manually create other rules, click Add Rule to open the dialog for adding a rule.

    1. Enter a name (32 characters or fewer, underscore, dash and alphanumeric characters only) and (optional) description.
    2. Select an action from the drop-down list: Deny, Deny & Log, Permit or Permit & Log
    3. Select a protocol from the drop-down list: TCP, UDP, IP, or ICMP.
    4. If you select TCP or UDP, fields appear for Source port and Destination port. You can enter specific numeric ports, and/or port-ranges (such as, 8000-8080,9000,9092). If you have previously created TCP/UDP port aliases, they will appear in the drop-down list for selection.
    5. To add an additional rule, click Add Rule and enter rule details as above.
    6. You can adjust the order of the rules by clicking the Move up or Move Down buttons in each rule.
    7. When you’re finished adding and ordering the rules, click Create to stage the addition and return to the list view.

    Note

    Log configuration is local to the network device. It is on the device and not on the Apstra server.

Errors

After creating a security policy, check the list view for errors. Errors are highlighted in red. (Image below is for version 3.1 which is slightly different from more recent versions.)

_images/security_policy_create_error1_310.png

Click the Show errors button to see details.

_images/security_policy_create_error2_310.png

After you resolve any errors, the policy is no longer highlighted red and the Errors field is blank. (Image below is for version 3.1 which is slightly different from more recent versions.)

_images/security_policy_create_error3_310.png

Editing Security Policy

  1. Either from the list view (Staged > Policies > Security Policies > Policies) or the details view, click the Edit button for the policy to edit.
  2. Make your changes.
  3. Click Edit to stage the changes and return to the list view.

Deleting Security Policy

  1. Either from the list view (Staged > Policies > Security Policies > Policies) or the details view, click the Delete button for the policy to delete.
  2. Click Delete to stage the deletion and return to the list view.

Conflicts

Apstra detects and resolves security policy rule conflicts whenever possible. More specific policies are applied before less specific ones by default, but you can change this setting. (See the Settings section below).

Any conflicts appear on the security policy list view (Staged > Policies > Security Policies > Policies) in the Rule Conflicts column. (Image below is for version 3.1 which is slightly different from more recent versions.)

_images/security_policy_conflict1_310.png

To see details of a conflict, navigate to Staged > Policies > Security Policies > Conflicts. When Apstra automatically resolves a conflict, Resolved by AOS appears in the Status column. (Image below is for version 3.1 which is slightly different from more recent versions.)

_images/security_policy_conflict2_310.png

Settings

You can configure security policy settings in the following categories (as of version 3.1).

Conflicts 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 all traffic (default)

Permit & Log - permits and logs all traffic

Deny - denies all traffic

Deny & Log - denies and logs all traffic

Updating Security Policy Settings

  1. From the blueprint, navigate to Staged > Policies > Security Policies > Settings.
  2. Select one option in each category.
  3. Click Save Changes to stage the changes.
  4. When you are ready to activate the staged changes, commit them to the blueprint.