Network policies


Network policies allow you to control layer 3 and 4 traffic between:

  • Processing units
  • Processing units and external networks

External networks and processing units

Processing units represent hosts or pods protected by enforcers. External networks represent hosts without enforcers. Because external networks don’t have enforcers, you can’t control their attempts to initiate or accept connections. However, you can control whether processing units:

  • Initiate connections to external networks.
  • Accept connections from external networks.

The following diagram illustrates the points of enforcement.

pod enforcer externalnetwork enforcer host

Sentence syntax

We designed network policies to be as easy to express as a sentence in the English language.

subject verb object

Each network policy contains:

  • Subject: initiator of the request
  • Verb: allow or reject
  • Object: recipient of the request

Network policy modes

You can set network policies to one of three modes.

  • Incoming traffic controls whether the object accepts or rejects the connection request. The object must be a processing unit.

  • Outgoing traffic controls whether the subject can initiate the connection or not. The subject must be a processing unit.

  • Bidirectional controls whether the subject can initiate a request to the object and whether the object can accept a request from the subject. Both subject and object must be processing units.


Any connection, once established, can be bidirectional. Network policies only control whether the connection gets established or dropped.

Defining external networks

Microsegmentation offers multiple ways to define an external network.

  • Domain name: Use a domain name whenever possible for greater resiliency. Microsegmentation also supports wildcards for subdomains, represented with an asterisk. For example, an external network defined as * would contain the traffic between processing units and,,, and so on. Microsegmentation disallows the following syntactical variations: *, googleapis*.com, and googleapis.*.

  • Static IP addresses: IP addresses tend to change, due to IPv4 address exhaustion and other factors. However, some services do have static IP addresses, such as DNS servers. Kubernetes reserves certain ranges of private IP addresses for pods, available via kubectl cluster-info dump | grep -i podCIDR. In addition, the three major cloud providers use the same link-local IP address for their metadata endpoints:

  • Dynamic IP addresses: Some vendors, like content delivery networks (CDNs), use dynamic ranges of public IP addresses and publish them. Amazon CloudFront publishes their current IP address ranges at and Cloudflare publishes its ranges at You can use a Microsegmentation automation to retrieve the latest ranges from the vendor and update your external network. For an example automation, refer to Blocking malicious IPs.

  • Protocol/port: You can also use protocols and ports to define the external network. Express the protocol and port as a pair.


Selecting subjects and objects

Use Microsegmentation tags to select the subjects and objects of your network policies. Microsegmentation automatically adds a number of tags to processing units. You must add tags to external networks manually. The Microsegmentation Console web interface allows you to browse through the tags assigned to processing units and external networks.

You may find that a single tag serves your purpose or you can connect the tags with AND and OR to form boolean expressions.

  • Web interface example An example of a boolean expression for the subject (referred to as “source” in the web interface) follows.

Tag expression in UI

  • Command-line/API example: You can also define network policies as YAML objects and exchange them with the Microsegmentation Console API via apoctl or your own client. Examples of subject/object selection in YAML follow.
name: Allow internet to front end
action: Allow
applyPolicyMode: IncomingTraffic
logsEnabled: true
- - 'ext:name=internet'
- - 'app=frontend'
name: Allow internet to front end
action: Allow
applyPolicyMode: IncomingTraffic
logsEnabled: true
- - 'ext:name=internet'
  - '$identity=externalnetwork'
- - 'app=frontend'
  - '$identity=processingunit'
name: Allow shopping cart or ad service to redis
action: Allow
applyPolicyMode: Bidirectional
logsEnabled: true
- - 'app=cartservice'
  - '$identity=processingunit'
- - 'app=adservice'
  - '$identity=processingunit'
- - 'app=redis'
  - '$identity=processingunit'


Observe how the hyphens allow you to specify AND and OR relationships between the tags.

Enforcer network policy retrieval and storage

The enforcer connects to the Microsegmentation Console API using mutual TLS. Any firewalls or load balancers between the enforcer and the Microsegmentation Console must allow pass-through communications. Packet modifications cause the communication to fail.

Each time a network policy gets updated, the Microsegmentation Console sends the enforcer a push notification. The enforcer also polls the Microsegmentation Console every ten minutes just in case.

The enforcer stores the network policies locally. If it loses its connection to the Microsegmentation Console, it continues enforcing the last network policies that it received.

Network policy resolution

For each request, the enforcer checks its local store of network policies to find one that matches.

Does anypolicy match? Yes Is it an allow policy? No Reject Yes Allow No Reject

If the enforcer finds no network policy that matches, it rejects the request. If it finds a network policy that allows the request and a network policy that rejects it, the reject policy takes precedence.


To reduce manual effort and ensure conformance to basic security requirements, you may wish to define some network policies and external networks in parent Microsegmentation namespaces and propagate them to the children.

Refer to Blocking malicious IPs for an example of a good candidate for propagation.