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.
We designed network policies to be as easy to express as a sentence in the English language.
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
*.googleapis.comwould contain the traffic between processing units and
cloudtrace.googleapis.com, and so on. Microsegmentation disallows the following syntactical variations:
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
https://ip-ranges.amazonaws.com/ip-ranges.jsonand Cloudflare publishes its ranges at
https://www.cloudflare.com/ips-v4. 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
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.
- Command-line/API example: You can also define network policies as YAML objects and exchange them with the Microsegmentation Console API via
apoctlor your own client. Examples of subject/object selection in YAML follow.
name: Allow internet to front end action: Allow applyPolicyMode: IncomingTraffic logsEnabled: true subject: - - 'ext:name=internet' object: - - 'app=frontend'
name: Allow internet to front end action: Allow applyPolicyMode: IncomingTraffic logsEnabled: true subject: - - 'ext:name=internet' - '$identity=externalnetwork' object: - - 'app=frontend' - '$identity=processingunit'
name: Allow shopping cart or ad service to redis action: Allow applyPolicyMode: Bidirectional logsEnabled: true subject: - - 'app=cartservice' - '$identity=processingunit' - - 'app=adservice' - '$identity=processingunit' object: - - '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.
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.