Kubernetes Network Policies

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 10.169.25.20/32 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 10.169.25.20/32 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:

Tags

Address Groups

Firewall Rules

Firewall Policy

Kubernetes Network Policy matchExpressions

Starting in Cloud-Native Contrail Networking (CN2) version 22.3, CN2 supports Kubernetes Network Policy with matchExpressions. For more information about matchExpressions, see "Resources that support set-based requirements" in the Kubernetes documentation.