Micro Segmentation Policies#

Micro Segmentation → MSMicro Segmentation Policies

The MicroSegmentationPolicy is a granular security policy designed to enforce Zero Trust principles within a network. Unlike traditional perimeter-based security that focuses on protecting the border of a network, microsegmentation divides the internal network into distinct, isolated security segments. This allows for precise control over "east-west" traffic (communication between internal resources), significantly reducing the attack surface and preventing lateral movement by unauthorized users or threats.

Network-Wide Scope: Instead of being applied to individual ports or interfaces one by one, the policy is defined at the network instance level and can be reused across multiple services.
Inheritance: Once configured, the policy is automatically inherited by all relevant connection points within that network segment, ensuring there are no "blind spots" in security coverage.
Network Design Agnostic: Because the policy references GroupTags rather than specific VLANs or IP addresses, the policy is updated automatically when group memberships or network configuration changes.

A MicroSegmentationPolicy is an ordered list of policyEntries that match certain packets and perform an action for those packets, and that are applied to one or more serviceTargets

Policy Entries#

The policyEntries are defined in an ordered list. Each packet is evaluated on ingress against all policyEntries in order. If there is no match, the packet is evaluated against the next entry and so on. Once a packet matches a particular entry, evaluation of the chain ends and the action specified in the entry is performed on the packet. This behavior is identical to Filters

Match Criteria#

Packets can be matched by their

Source GroupTag
Destination GroupTag
Source port
Destination port
Protocol
IP version

Actions#

When a packet matches the matchCriteria of a policyEntry, the following actions can be applied to the packet

Forwarding - Accept or Drop
Logging - Logs the packets to the nodes logging facility
Collect statistics - See Policy Entry Counters

Service Targets#

The MicroSegmentationPolicy can be applied to one or more services by setting serviceTargets. The following type are supported:

Dashboards#

Use the Micro Segmentation Policies dashboards for operational visibility.

Policy Entry Counters — per-entry match statistics for policies with collectStats enabled on a policy entry
Node Platform Status — platform configuration and health for nodes running micro segmentation policies, including LPM source lookup mode, chassis reboot status, and IP LPM route utilization. Useful for:
- verifying the impact on LPM scale before enabling LPM source lookup, using ip-lpm-routes utilization
- checking whether LPM source lookup mode is enabled and whether a chassis reboot is required

Alarms#

Micro segmentation can raise the following alarm when a node needs to be rebooted in order for the complate microsegmentation configuration to take effect (typically typically to enable LPM source lookup). The alarm is defined by the Components application but is triggered by group-based-policy platform configuration on SR Linux nodes.

Alarm	Severity	Triggered when	Cleared when
`NodeRebootRequired`	warning	Node level micro segmentation settings require a chassis reboot to take effect, typically when LPM source lookup mode is required	The node is rebooted and the platform setting is active or the configuration is no longer required. (`chassis-reboot-required` is no longer true)

Use the Node Platform Status dashboard or the Alarms view to find affected nodes.

MicroSegmentationPolicies can not be applied in the underlay

MicroSegmentatioPolicies are not supported in DefaultRouters.

OS-specific implementation notes#

Node reboot required

If an SR Linux device is deployed in a role that requires the source tag to be derived from the lookup of the source IP address in the Longest Prefix Match (LPM) table, the device will automatically be configured to operate in LPM source lookup mode (platform.resource-management.group-based-policy.lpm-source-lookup). Changing this setting requires a chassis reboot. EDA raises a Node Reboot Required alarm on the affected node. See Alarms and Node Platform Status.

Dependencies#

A MicroSegmentationPolicy must be applied to one or more serviceTargets of the following types:

These resources should be created first, before creating the MicroSegmentationPolicy.

Referenced resources#

Group Tags#

A MicroSegmentationPolicy typically refers to GroupTags as source or destination matchCriteria in the policyEntries.

These resources should be created first, before creating the MicroSegmentationPolicy.

Examples#

YAMLkubectl

apiVersion: microsegmentation.eda.nokia.com/v1alpha1
kind: MicroSegmentationPolicy
metadata:
  name: client-security-1
  namespace: eda
spec:
  entries:
    - action:
        collectStats: false
        forward: Accept
        log: false
      bidirectional: true
      description: allow any TCP IPv4 traffic to firewall
      match:
        destinationGroupTag:
          - firewall
        protocolName: TCP
        ipVersion: IPv4
    - action:
        collectStats: true
        forward: Accept
        log: true
      bidirectional: true
      description: quarantined hosts allow to firewall only
      match:
        destinationGroupTag:
          - firewall
        sourceGroupTag:
          - quarantine
    - action:
        collectStats: true
        forward: Drop
        log: true
      bidirectional: true
      description: block all other quarantine traffic
      match:
        sourceGroupTag:
          - quarantine
    - action:
        collectStats: false
        forward: Accept
        log: false
      bidirectional: true
      description: allow clientgroup1 and clientgroup2 traffic
      match:
        destinationGroupTag:
          - group-client2
        sourceGroupTag:
          - group-client1
    - action:
        collectStats: true
        forward: Drop
        log: false
      bidirectional: true
      description: drop by default
      match: {}
  serviceTargets:
    virtualNetworks:
      - vnet1
      - vnet2

cat << 'EOF' | kubectl apply -f -
apiVersion: microsegmentation.eda.nokia.com/v1alpha1
kind: MicroSegmentationPolicy
metadata:
  name: client-security-1
  namespace: eda
spec:
  entries:
    - action:
        collectStats: false
        forward: Accept
        log: false
      bidirectional: true
      description: allow any TCP IPv4 traffic to firewall
      match:
        destinationGroupTag:
          - firewall
        protocolName: TCP
        ipVersion: IPv4
    - action:
        collectStats: true
        forward: Accept
        log: true
      bidirectional: true
      description: quarantined hosts allow to firewall only
      match:
        destinationGroupTag:
          - firewall
        sourceGroupTag:
          - quarantine
    - action:
        collectStats: true
        forward: Drop
        log: true
      bidirectional: true
      description: block all other quarantine traffic
      match:
        sourceGroupTag:
          - quarantine
    - action:
        collectStats: false
        forward: Accept
        log: false
      bidirectional: true
      description: allow clientgroup1 and clientgroup2 traffic
      match:
        destinationGroupTag:
          - group-client2
        sourceGroupTag:
          - group-client1
    - action:
        collectStats: true
        forward: Drop
        log: false
      bidirectional: true
      description: drop by default
      match: {}
  serviceTargets:
    virtualNetworks:
      - vnet1
      - vnet2

EOF

Custom Resource Definition#

To browse the Custom Resource Definition go to crd.eda.dev.

SPEC

Micro Segmentation Policy applies a set of Policy Entries to a set of Virtual Networks, Routers, and Bridge Domains. Each entry consists of match criteria and actions to take when traffic matches the criteria. The policy is applied to all interfaces within the network-instance automatically.

#
A list of entries defining the match criteria and actions for this policy.
- #
#
The set of services to which this policy applies. At least one of Virtual Networks, Virtual Network Selectors, Routers, Router Selectors, Bridge Domains, or Bridge Domain Selectors must be set. The use of Virtual Networks is recommended. Advanced If Virtual Networks are used, the policy will automatically apply to all interfaces in the Virtual Network. If Routers or Bridge Domains are used to compose a L3 service without using Virtual Networks, Group Tags with a *global scope* should be used as with a *local scope* Group Tag would result in the IDs being allocated per individual Router or Bridge Domain.
- #
- #
- #
- #
- #
- #

STATUS

MicroSegmentationPolicyStatus defines the observed state of MicroSegmentationPolicy