Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Kubernetes Network Policy Support

SUMMARY Juniper Cloud-Native Contrail® Networking (CN2) lets you deploy Kubernetes network policies within the Contrail firewall security policy framework. You must use a Container Network Interface (CNI) that supports NetworkPolicy, like Contrail, to deploy a network policy. This topic provides information about how to deploy a Kubernetes network policy in environments running Cloud-Native Contrail Networking.

Kubernetes Network Policy Overview

Kubernetes network policies let you specify how pods communicate with other pods and network endpoints. A Kubernetes NetworkPolicy resource enables a pod to communicate with:

  • Other pods in the allowlist (a pod cannot block access to itself).

  • Namespaces in the allowlist.

  • IP blocks, or Classless Inter-Domain Routing (CIDR).

Kubernetes network policies apply only to pods within a namespace and define ingress (source) and egress (destination) rules. Kubernetes network policies have the following characteristics when applied to a pod:

  • Pod specific and apply to a single pod or a group of pods. Network policy rules dictate the traffic to that pod.

  • Define traffic rules for a pod for ingress traffic, egress traffic, or both. If you don't specify a direction explicitly, the policy applies to the ingress direction by default.

  • Must contain explicit rules that specify traffic from the allowlist in the ingress and egress directions. Traffic that does not match the allowlist rules is denied.

  • Permitted traffic includes traffic matching any of the network policies applied to a pod.

Kubernetes network policies have the following additional characteristics:

  • When not applied to a pod, that pod accepts traffic from all sources.

  • Act on connections rather than individual packets. For example, if traffic from pod A to pod B is allowed by the configured policy, then the packets from pod B to pod A are also allowed, even if the policy in place does not allow pod B to initiate a connection to pod A.

A Kubernetes network policy comprises the following sections:

  • spec: Describes the desired state of a Kubernetes object. For a network policy, the podSelector and policyTypes fields within the spec specify the rules for that policy.

  • podSelector: Selects the groups of pods to which the policy applies. An empty podSelector selects all pods in the namespace.

  • policyTypes: Specifies whether the policy applies to ingress traffic from selected pods or egress traffic to selected pods. If no policyTypes are specified, the ingress direction is selected by default.

  • ingress: Allows ingress traffic that matches the from and ports sections. In the following example, the ingress rule allows connections to all pods in the dev namespace with the label app: webserver-dev on TCP port 80 from:

    • Any pod in the default namespace with the label app: client1-dev.

    • All IP addresses within the range.

    • Any pod in the default namespace with the label project: jtac.

  • egress: Allows egress traffic that matches the to and portssections. In Example 1, the egress rule allows connections from any pod in the default namespace with the label app: dbserver-dev to port TCP 80.

  • ipBlock: Selects IP CIDR ranges to allow as ingress sources or egress destinations. The ipBlock section of a network policy contains the following two fields:

    • cidr (ipBlock.cidr): The network policy allows egress traffic to, or ingress traffic from, the specified IP range.

    • except (ipBlock.except): Kubernetes expects traffic in the specified IP range not to match the policy. The network policy denies ingress traffic to, or egress traffic from, the IP range specified in except.

      Note: If you use except in a network policy, Kubernetes expects the identified traffic in the except IP range not to match the policy. CN2 does not support this specific scenario where you use the except term. As a result, we recommend that you avoid using except.

The following NetworkPolicy resource example shows ingress and egress rules:

In this example, ingress TCP traffic from IPs within CIDR from port: 80 is allowed. Egress traffic to pods with matchLabels app: dbserver-dev to TCP port: 80 is allowed.

Deploy a Kubernetes Network Policy in Cloud-Native Contrail Networking

In CN2, after you configure and deploy a Kubernetes network policy, that policy is created automatically in Contrail. Here's an example of a Kubernetes network policy:

This policy results in the following objects being created in CN2:


Address Groups

Firewall Rules

Firewall Policy

Table 1: Tags
Key Value
role db
namespace default
project myproject
role frontend
Table 2: Address Groups
Name Prefix
Table 3: Firewall Rules
Rule Name Action Service Endpoint1 Direction Endpoint2
default-ingress-test-network-policy-0-ipBlock-0-17x.xx.1.0/24-0 deny tcp:6379 role=db && namespace=default ingress Address Group:
default-ingress-test-network-policy-0-ipBlock-0-cidr-17x.xx.0.0/16-0 pass tcp:6379 role=db && namespace=default ingress Address Group:
default-ingress-test-network-policy-0-namespaceSelector-1-0 pass tcp:6379 role=db && namespace=default ingress project=myproject
default-ingress-test-network-policy-0-podSelector-2-0 pass tcp:6379 role=db && namespace=default ingress namespace=default && role=frontend
default-egress-test-network-policy-ipBlock-0-cidr- pass tcp:5978 role=db && namespace=default egress Address Group:
Table 4: Firewall Policy
Name Rules

default-ingress-test-network-policy-0-ipBlock-0-, default-ingress-test-network-policy-0-ipBlock-0-cidr-


default-ingress-test-network-policy-0-podSelector-2-0, default-egress-test-network-policy-ipBlock-0-cidr-