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 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 designated protocols. The policies and rules are stateless, meaning that the network policy does not consider the previous state of network connections. Instead, it makes decisions based solely on the characteristics of individual network packets, such as their source and destination addresses and ports. Endpoints are administratively defined IP ranges within an Apstra Blueprint or external to the Blueprint.

Using an analogy, addresses within an IP network are like stations along train tracks - Policies utilize endpoints and endpoint groups to specify which sections of track, or IP ranges within a Virtual Network (VN), specific rules will apply to. If you aim to create a policy applied to an entire VN - think the whole rail network - you can consider endpoints optional because the policy will cover the entire IP address space within that VN.

Policies have five components:

  • Source

  • Destination

  • IP Protocol

  • Port

  • Action (Permit, Permit & Log, Deny, Deny & Log)

Source/Destination objects within a policy can be selected from any of the following:

  • Internal Endpoints

  • Internal Endpoint Groups

  • External Endpoints

  • External Endpoint Groups

  • Virtual Networks

  • Routing Zones (all Virtual Networks within an SZ)

IP Protocol can be any of the following:

  • IP

  • TCP

  • UDP

  • ICMP

Ports can be individual port numbers (ex., TCP 22 for SSH) or ranges of ports.

The action component specifies the intended behavior of the rule when a packet that matches the four identifiers is detected. This behavior may include allowing the packet to pass through, blocking the packet entirely, or dropping the packet. Optionally you can add traffic logging in each policy, which will write the policy log locally to the network device.

Remember, for a bi-directional security, you need to create two policies, one for each direction, and you can apply more than one policy to each subnet/endpoint, meaning the ordering of rules impacts behavior.

Policy Group Objects

Apstra provides policy constructs to express security/segmentation intent with different levels of granularity.

Endpoints/groups that are possible subjects of security policies are as follows:

  • VN (virtual networks, contain subnet)

  • IPE (internal IP endpoints associated with VN, have IP /32 address)

  • IPECG (IP endpoints custom groups)

  • EIPE (External IP endpoints, contain /32 or subnet)

  • EIPCG (External IP endpoint custom groups)

  • RZ (Routing Zone, logical collection of all VNs and IPE)

Segmentation and Policies have many available use cases, such as:

  • Customers have multiple vendor types and want simplified security management.

  • Customers wish to isolate VMs and control the allowed application flows between VNs.

Internal Endpoints

Internal Endpoints are IP subnets or individual IP addresses within a virtual network that is part of the Apstra Blueprint. These addresses are associated with a VN but can be a smaller subnet of the larger VN. For example:

  • Virtual Network 100 (vlan100): 192.168.0.0/24

  • Internal Endpoint: 192.168.0.128/26

  • This correlates to the upper half of the full /24

Note:

When creating Internal Endpoints, the defined IP range cannot overlap with the Apstra-configured SVI addresses used for Virtual Route Redundancy Protocol (VRRP).

External Endpoints

External Endpoints are IP subnets that exist outside of the Blueprint. These IP addresses are located beyond the Apstra external routers. Examples of external endpoints include:

  • NTP source (located outside of the Apstra Blueprint)

  • Network Operation Center (NOC) management subnet (located outside of the Apstra Blueprint)

  • Trusted API endpoints (IP addresses or ranges) on the internet

  • 3rd party IP addresses

Internal Endpoint Groups

Internal Endpoint Groups combine multiple internal endpoints into a logical group that shares similar security requirements. Using endpoint groups will simplify the management of policies within an enterprise environment. Examples of effective use of Internal Endpoint Groups:

  • All database servers

  • Finance department servers

External Endpoint Groups

External Endpoint Groups combine multiple external endpoints into a logical group that shares similar security requirements. Using endpoint groups will simplify the management of policies within an enterprise environment. Examples of effective use of External Endpoint Groups:

  • Corporate NTP/DNS server (if these servers are not on the Apstra-managed fabric)
  • Corporate Directory and Key servers (security)
  • Partner API endpoint IPs (Internet)

Using groups in this manner, you can easily create a policy that states:

  • Permit ALL servers to reach corporate NTP/DNS
  • Deny ALL other NTP/DNS sources (by TCP ports)

Endpoint Group Notes:

  • Group Based Policy elements, including endpoint groups, are defined within each Apstra Blueprint.

Virtual Networks

Virtual Networks (VNs) are objects used to define all L2 and L3 endpoints within a VLAN or VXLAN. Whereas Endpoint Groups define subnets within a Virtual Network, the VN correlates to all IP addresses within the network.

Routing Zones

Routing Zones (RZ) are the highest-level objects. RZ is directly aligned with a Virtual Routing and Forwarding instance (VRF). VRFs offer isolation at the routing table level, separating tenants from being able to reach each other at L3. VRFs do not directly provide encapsulation or encryption, the routing tables are entirely isolated, but packets in flight from multiple VRFs share the same forwarding plane. As a best practice, Inter-VRF communication should be sent to a network firewall for stateful inspection.

Enforcement Points

All connections to the external routers are enabled as Enforcement Points by default. This includes:

  • Physical interfaces

  • 802.1q sub-interfaces

Policy Enforcement

The policy is applied as an L3 ACL on the applicable Enforcement Points within a blueprint. This means that the policy elements that are irrelevant to a particular enforcement point are not rendered. This causes a radical simplification of the size of the final ACL.