Juniper Apstra Policy Assurance

In This Guide

• Apstra Overview
• Introduction
• Security Policies
• Conflicts and Resolution
• Policy Assurance Operations
• Routing Constraints

Apstra Overview

Summary

Apstra manages network security and workload isolation via the Policy Assurance feature. This feature allows the creation of policies decoupled from enforcement mechanisms, enabling the specification of intent in an implementation-independent way.

Background

Using Juniper Apstra and its Intent-Based Networking approach enhances and scales security posture by addressing common causes of security mishaps like lack of visibility, consistency, and accountability. Apstra structures the operational process using a central source of reliable information, ensuring consistency in policies and workflows, and allowing for real-time testing and visibility. Its closed-loop validation capability checks for drift between the intended "Golden Configuration" and the operational state, with compliance enforcement under real-time evaluation. Violations are flagged to the user, eliminating the need for tedious device-by-device auditing. An audit trail feature tracks changes, correlating configuration changes to operator intent.

Apstra's Policy Assurance feature allows policies to be decoupled from enforcement mechanisms, enabling implementation-independent intent specification. Demos are available at www.juniper.net/us/en/dm/apstra-demos.html.

Introduction

Apstra manages network security and workload isolation through a Group Based Policy (GBP) framework, similar to concepts found in OpenStack. This feature allows policies to be decoupled from enforcement mechanisms, enabling implementation-independent intent specification. Apstra translates these policies into Access Lists (ACLs) for various Network Operating Systems (NOS), installed on L3 interfaces to control traffic flows between virtual networks and external systems.

Diagram Description: Visual representation of Global Policy mapping to Juniper, Arista, and Cisco configurations, illustrating how policies are translated for different network operating systems.

Security Policies

Security policies allow or block traffic between endpoints based on IP addresses, port numbers, and protocols. Policies can be created for each direction (ingress, egress) between endpoints, networks, or specific host IPs. The order of rules is critical. Policies define permitted or denied communications within the data center fabric. An analogy is used: Party A and Party B (groups of people) and their conversation (traffic) which can be permitted or blocked.

Diagram Description: A visual representation of Juniper Apstra's goal to decouple policies from various mechanisms, enabling policy intent enforcement without tedious management. It shows different departmental policies (Finance, HR, Compliance, IT, 3rd Party) merging into a single "Merged Intended Policy".

Apstra's Policy Assurance simplifies ACL management and reduces ACL table size. It automatically composes ACLs and applies them to routed interfaces like Switch Virtual Interfaces (SVI) or Integrated Routing and Bridging (IRB) interfaces. ACLs are rendered in the correct device syntax and applied to relevant enforcement points. Adding new endpoints to a virtual network automatically applies the ACL. Apstra can detect and resolve conflicts between overlapping policies based on user settings like "More specific first" or "More generic first". Users can search policies by source/destination object and traffic type.

Apstra ensures the network remains secure during policy provisioning, preventing an open traffic state. It uses an incremental ACL deployment process for policy changes.

Security Policy Benefits

• Simplicity
• Vendor-agnostic GUI implementation for creating ACLs
• Introspection/visibility: Understand which policies apply to an endpoint/group, or which endpoints/groups a policy applies to.
• Conflict Detection (at the policy level): Identifies security conflicts, admission control constraints, priorities, and pre-emption.
• Conflict resolution: Handles security conflicts and provides default settings like "more specific wins" or "override".

Apstra merges multiple policies and assists with conflict remediation. Policies are combined before device configuration rendering, ensuring support for multiple vendors. The resulting vendor configuration syntax accurately reflects the user's intent. Routing Policies are supported via Virtual Networks (VXLAN/VLAN) and Routing Zones (RZ), rendered as Virtual Routing and Forwarding (VRF) instances. A Role-Based Access Control (RBAC) model manages user privileges.

In This Section

• Policy Group Objects | 6
• Internal Endpoints | 6
• External Endpoints | 7
• Internal Endpoint Groups | 7
• External Endpoint Groups | 8
• Virtual Networks | 8
• Routing Zones | 9
• Enforcement Points | 9
• Policy Enforcement | 9

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. Policies are stateless, making decisions based on packet characteristics like source/destination addresses and ports. Endpoints are administratively defined IP ranges within an Apstra Blueprint or external to it.

An analogy is used where IP network addresses are like stations along train tracks, and policies use endpoints and endpoint groups to define rules for specific sections or IP ranges within a Virtual Network (VN).

Policy Components

• Source
• Destination
• IP Protocol
• Port
• Action (Permit, Permit & Log, Deny, Deny & Log)

Source/Destination Objects

• Internal Endpoints
• Internal Endpoint Groups
• External Endpoints
• External Endpoint Groups
• Virtual Networks
• Routing Zones (all Virtual Networks within an SZ)

IP Protocol Options

• IP
• TCP
• UDP
• ICMP

Ports can be individual numbers or ranges. The action component specifies the intended behavior (allow, block, drop), with an option for traffic logging.

For bi-directional security, two policies are needed, one for each direction. Multiple policies can apply to a subnet/endpoint, impacting behavior based on rule order.

Policy Group Objects

Apstra provides policy constructs for security/segmentation intent at various granularities. Endpoints/groups include:

• VN (virtual networks, contain subnets)
• IPE (internal IP endpoints associated with VN, /32 address)
• IPECG (IP endpoints custom groups)
• EIPE (External IP endpoints, /32 or subnet)
• EIPCG (External IP endpoint custom groups)
• RZ (Routing Zone, logical collection of VNs and IPE)

Use cases for Segmentation and Policies include simplified security management for multiple vendor types and isolating VMs with controlled application flows between VNs.

Internal Endpoints

Internal Endpoints are IP subnets or individual IP addresses within a virtual network part of an Apstra Blueprint. They can be smaller subnets within a larger VN. Example: Virtual Network 100 (vlan100): 192.168.0.0/24; Internal Endpoint: 192.168.0.128/26 (upper half of /24).

Note: Defined IP ranges for Internal Endpoints cannot overlap with Apstra-configured SVI addresses for VRRP.

Diagram Description: A visual representation of an "Endpoint" with an IP address (192.168.0.128/26).

External Endpoints

External Endpoints are IP subnets existing outside the Blueprint, located beyond Apstra external routers. Examples include NTP sources, Network Operation Center (NOC) management subnets, trusted API endpoints on the internet, and 3rd party IP addresses.

Internal Endpoint Groups

Internal Endpoint Groups combine multiple internal endpoints into a logical group for similar security requirements, simplifying policy management. Examples include "All database servers" and "Finance department servers".

Diagram Description: A visual representation of "Endpoint Group" containing two "Endpoint" elements.

External Endpoint Groups

External Endpoint Groups combine multiple external endpoints into a logical group for similar security requirements, simplifying policy management. Examples include corporate NTP/DNS servers, corporate directory and key servers, and partner API endpoint IPs.

Using groups allows policies like "Permit ALL servers to reach corporate NTP/DNS" or "Deny ALL other NTP/DNS sources".

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

Virtual Networks

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

Diagram Description: A visual representation of a "Virtual Network" labeled "VXLAN5001".

Routing Zones

Routing Zones (RZ) are high-level objects aligned with Virtual Routing and Forwarding (VRF) instances. VRFs provide isolation at the routing table level, separating tenants. While VRFs don't provide encapsulation or encryption, their routing tables are isolated, sharing the same forwarding plane for packets in flight. Inter-VRF communication is best sent to a network firewall for stateful inspection.

Enforcement Points

Connections to external routers are enabled as Enforcement Points by default, including:

• Physical interfaces
• 802.1q sub-interfaces

Policy Enforcement

Policies are applied as L3 ACLs on applicable Enforcement Points within a blueprint. Irrelevant policy elements are not rendered, simplifying the final ACL size.

Conflicts and Resolution

Juniper Apstra supports multiple policies on a single Blueprint. Conflicting or overlapping rules can lead to different outcomes, with Apstra sometimes resolving conflicts automatically or requiring user intervention.

Overlapping Policies

An overlapping policy occurs when all fields in the 5-tuple match another policy. Rules can have the same or different actions (e.g., "allow" vs. "deny"). Resolutions include:

• Automatic Access List (ACL) optimization by combining matching rules with the same action (Shadow Rules).
• Automatic resolution and rule ordering based on default Conflict Resolution settings.
• Manual resolution for overlapping rules with different actions that Apstra cannot auto-resolve.

Diagram Description: A diagram illustrating a conflict between "PERMIT SSH (22)" and "DENY 1-1024", labeled as "CONFLICT".

Shadow Rules

Shadow Rules are policy rules covered by a larger policy rule. If Policy-A is entirely contained within Policy-B, Policy-A is redundant and may not need rendering. Apstra displays "Shadowing" for such rules.

Automated Resolution

Apstra can automatically resolve conflicts based on global blueprint settings. The example shows Apstra auto-resolving conflicts between two policies involving Virtual Networks and Routing Zones, both denying TCP 443.

Manual Conflict Resolution

When Apstra cannot determine which rule to use (permit or deny), the conflict is flagged, prompting the user to select the priority rule. The user must resolve the conflict before committing changes.

Diagram Description: A screenshot of the Apstra UI showing a "Manual Conflict Resolution" scenario with "Policy / Rule #1" and "Policy / Rule #2", indicating a "Requires Attention" status.

The example policies include a "permit TCP 1-1024" and a "deny TCP 22-2000" between virtual networks.

Blueprint Policy Settings

Apstra attempts automatic conflict resolution based on global, per-Blueprint settings. Defaults favor more specific rules and explicit permits over denies. Settings can be configured once per Blueprint. Rule order impacts behavior, and an implicit hierarchy exists between routing zones, virtual networks, and IP endpoints. Conflicts can arise when one rule's match set contains another's.

Diagram Description: A screenshot of the Apstra UI showing "Blueprint Policy Settings" with options for "Conflicts resolution" (More specific first, More generic first, Disabled) and "Default action" (Permit, Permit & Log, Deny, Deny & Log).

Policy Search

Users can search existing policies to determine if specific traffic is affected by active policies. Searches can be based on predefined objects, IP addresses, or ranges. Examples include checking HTTP traffic allowance, server routing capabilities, or open ports between virtual networks.

Diagram Description: A screenshot of the Apstra UI "Search criteria" panel, showing options like IPv4 Subnet, Internal Endpoint, External Endpoint, Virtual Network, etc.

Policy Assurance Operations

Incremental Access List Deployment

To minimize impact on existing traffic flows during policy deployment, Apstra uses a multistep process. This ensures the network does not enter an open state while rules are pushed into Tertiary Content-Addressable Memory (TCAM).

Apstra's workflow for policy changes:

1. Install temporary Access List (ACL) as previous-acl-name_TMP.
2. Switch to the _TMP ACL.
3. Add original ACL with new rendering.
4. Switch to the original ACL.
5. Remove the TMP ACL.

Note: It is recommended not to use more than 50% of TCAM for secondary ACLs. Default ACL atomic update settings in NX-OS and EOS should be maintained. Apstra's changes improve modification by enforcing policies even when atomic updates are impossible.

Example Policy Deployment

The following is an example of a policy deployment object, showing the creation and application of temporary and updated ACLs for a VLAN interface.

ip access-list ACL_VLAN_3_IN_TMP <CREATES TMP ACL>
4 remark Policy: 'www to db ssh copy'
5 deny TCP 10.0.1.128/25 eq 22 10.0.2.128/25
9 remark Policy: 'www to db ssh'
10 permit TCP 10.0.1.128/25 range 1 1024 10.0.2.128/25
14 remark Trailing default action rule
15 permit IP 10.0.1.0/24 0.0.0.0/0
exit
!
interface vlan 3
ip access-group ACL_VLAN_3_IN_TMP in <SWITCH TO TMP ACL>
exit
no ip access-list ACL_VLAN_3_IN <REMOVE ORIGINAL ACL>
!
ip access-list ACL_VLAN_3_IN <CREATE UPDATED ORIGINAL ACL>
4 remark Policy: 'www to db ssh allow'
5 deny TCP 10.0.1.128/25 range 22 23 10.0.2.128/25
9 remark Policy: 'www to db ssh'
10 permit TCP 10.0.1.128/25 range 1 1024 10.0.2.128/25
14 remark Trailing default action rule
15 permit IP 10.0.1.0/24 0.0.0.0/0
Exit
interface vlan 3
ip access-group ACL_VLAN_3_IN in <SWITCH TO UPDATED ACL>
exit
!
no ip access-list ACL_VLAN_3_IN_TMP <REMOVE TMP ACL>

Policy Enable/Disable

Policies can be enabled or disabled via the Apstra UI or API. Disabling a policy queues the change as "Uncommitted"; administrators must "Commit" changes to the Blueprint for them to take effect.

Diagram Description: A UI element showing a toggle switch for "Enabled" and "Disabled policy".

Policy Export/Import

Policies can be imported and exported via the API. Proper import requires identical policy objects, which is useful for managing multiple Blueprints with similar policies.

Routing Constraints

Routing Zone Constraints enable policies at the management layer for VRF services on ports. Constraints can define lists of allowed/excluded VRFs or maximum VRF counts.

These constraints enforce security or data protection requirements, preventing operators from performing actions that violate business rules, such as allowing Customer_A and Customer_B services on the same port simultaneously, or limiting ports to a single VRF.

Only Trusted Use Case

This example aligns with GDPR, obliging endpoints with data from trusted networks to not contain data from untrusted networks. This translates to clustering Routing Zones (network VRFs) and their associated Virtual Networks and endpoints. Routing Constraints automatically cross-reference VN assignments to RZs, verify if the RZ is part of a "Trusted" or "Untrusted" Group, and prevent provisioning interfaces with both Trusted and Untrustworthy networks.

Routing Zone Group

The first step involves creating Routing Zone Groups (e.g., with "red" and "blue" members). "Contractors" group for VN's part of the Orange Routing Zone is an example. Trusted networks are VNs part of the "red" or "blue" Routing Zones.

Diagram Description: UI screenshots showing "Edit Routing Zone Group" and "Create Routing Zone Group" interfaces, detailing common parameters like Name, Tags, and Members (Routing Zones).

Routing Zone Constraints

Routing zone policy constraints can be defined in several ways, such as:

• One VRF maximum
• Any VRF except Management
• Only VRFs Blue and Red
• Only VRF Group Orange

Diagram Description: A UI screenshot for "Edit Routing Zone Constraints" showing fields for Name, Max Count Constraint, Routing Zones List Constraint (Allow/Deny/None), and selecting Routing Zone Groups.

Routing Zone Constraint Connectivity Policy

Once a constraint is defined, it's enforced on server-facing interfaces using connectivity templates. These templates allow specific policy assignment to individual interfaces or bulk assignment based on tags, shaping policy precisely for targeted enforcement in real time.

Diagram Description: A UI screenshot for "Edit Connectivity Template" showing a "Routing Zone Constraint" primitive named "ONLY TRUSTED" being applied.

Apply Constraints to Endpoints

After creating a connectivity template, the policy is assigned to specific interfaces for enforcement.

Diagram Description: A UI screenshot for "Assign TRUST ONLY" showing a table view of Fabric, Interface, Tags, and TRUST ONLY checkboxes, with an "Assign" button.

Operation and Validation

After policy application, Apstra validates VN configurations against routing zone constraint policies. It identifies violations, such as a VN belonging to an "Orange" RZ when the "TRUST ONLY" policy requires "red" or "blue" RZs.

Diagram Description: A UI screenshot for "Assign Badge Net" displaying "Server-side Validation Errors", highlighting an "Invalid data" message indicating a violation of the "ONLY TRUSTED" policy due to an RZ mismatch.

Summary

This document provides an overview of Juniper Apstra's Policy Assurance feature, highlighting its vendor-agnostic nature and its role in enhancing organizational security posture through Intent-Based Networking. It covers concepts and use case examples. Interactive demos are available in the Related Information section.

Related Documentation

• Demo of Policy Assurance in action
• OpenStack view of Group-Based Policy

Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. All other trademarks are property of their respective owners. Juniper Networks assumes no responsibility for inaccuracies and reserves the right to change this publication without notice. Copyright © 2024 Juniper Networks, Inc. All rights reserved.