EXPEDIA GROUP TECHNOLOGY — ENGINEERING

Starting from the basics of Kubernetes networking and managing network policies, we discuss Calico. It is a third-party open-source network plugin which enhances built-in networking features. We show the ease of configuration as well as functionality, all through real-life examples.

Kubernetes Network Policies

Network policy is the primary tool for securing a Kubernetes network. It allows you to easily restrict network traffic in your cluster to allow only the traffic that you want.

The main features of Kubernetes network policies are:

• Policies are namespace scoped (i.e. you create them within the context of a specific namespace just like, for example, pods)
• Policies are applied to pods using label selectors
• Policy rules can specify the traffic that is allowed to/from other pods, namespaces, or CIDRs
• Policy rules can specify protocols (TCP, UDP, SCTP), named ports or port numbers

The problem with Kubernetes Network Policies is that they have limitations that for many users would be a problem:

• Default policies which are applied to all namespaces or pods
• The ability to log network security events (for example connections that are blocked or accepted).
• You cannot deny traffic, only allow
• You can’t route traffic through a common gateway
• You cannot block localhost traffic

Some of these issues are addressed by third parties tools such as Calico. We’re going to look at this briefly below.

Calico Network Policies

In addition to enforcing Kubernetes network policy, Calico supports its own namespaced NetworkPolicy and non-namespaced GlobalNetworkPolicy resources. These provide additional features beyond those supported by Kubernetes network policy. This includes support for:

• Policy ordering/priority
• Deny and log actions in rules
• More flexible match criteria for applying policies and in policy rules, including matching on Kubernetes ServiceAccounts, and (if using Istio & Envoy) cryptographic identity and layer 5–7 match criteria such as HTTP & gRPC URLs
• Ability to reference non-Kubernetes workloads in polices, including matching on NetworkSets in policy rules
• Kubernetes network policy applies only to pods, whereas Calico network policy can be applied to multiple types of endpoints including pods, VMs, and host interfaces

Concepts

Endpoints

Calico network policies apply to endpoints. In Kubernetes, each pod is a Calico endpoint. However, Calico can support other kinds of endpoints. There are two types of Calico endpoints: workload endpoints (such as a Kubernetes pod ) and host endpoints (an interface or group of interfaces on a host).

Namespaced and global network policies

Calico network policy is a namespaced resource that applies to pods/containers/VMs in that namespace.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-tcp-6379
  namespace: production

Calico global network policy is a non-namespaced resource and can be applied to any kind of endpoint (pods, VMs, host interfaces) independent of namespace.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allow-tcp-port-6379

Because global network policies use kind: GlobalNetworkPolicy, they are grouped separately from kind: NetworkPolicy.

Ingress and egress

Each network policy rule applies to either ingress or egress traffic. From the point of view of an endpoint (pod, VM, host interface), ingress is incoming traffic to the endpoint, and egress is outgoing traffic from the endpoint. In a Calico network policy, you create ingress and egress rules independently (egress, ingress, or both).

You can specify whether policy applies to ingress, egress, or both using the types field. If you do not use the types field, Calico defaults to the following values.

Network traffic behaviours: deny and allow

The Kubernetes network policy specification defines the following behavior:

• If no network policies apply to a pod, then all traffic to/from that pod is allowed.
• If one or more network policies apply to a pod containing ingress rules, then only the ingress traffic specifically allowed by those policies is allowed.
• If one or more network policies apply to a pod containing egress rules, then only the egress traffic specifically allowed by those policies is allowed.

For compatibility with Kubernetes, Calico network policy follows the same behavior for Kubernetes pods. For other endpoint types (VMs, host interfaces), Calico network policy is default deny. That is, only traffic specifically allowed by network policy is allowed, even if no network policies apply to the endpoint.

Examples

Here we will share the various examples where we can use Calico Network Policy.

Control traffic to/from endpoints in a namespace

In the following example, ingress traffic to endpoints in the namespace: production with label color: red is allowed, only if it comes from a pod in the same namespace with color: blue, on port 6379.

To allow ingress traffic from endpoints in other namespaces, use a namespaceSelector in the policy rule. A namespaceSelector matches namespaces based on the labels that are applied in the namespace. In the following example, ingress traffic is also allowed from endpoints in namespaces that match shape == circle.

Control traffic to/from endpoints independent of namespace

The following Calico network policy is similar to the previous example, but uses kind: GlobalNetworkPolicy so it applies to all endpoints, regardless of namespace.

In the following example, incoming TCP traffic to any pods with label color: red is denied if it comes from a pod with color: blue.

As with kind: NetworkPolicy, you can allow or deny ingress traffic from endpoints in specific namespaces using a namespaceSelector in the policy rule:

Control traffic to/from endpoints using IP addresses or CIDR ranges

Instead of using a selector to define which traffic is allowed to/from the endpoints in a network policy, you can also specify an IP block in CIDR notation.

In the following example, outgoing traffic is allowed from pods with the label color: red if it goes to an IP address in the 1.2.3.4/24 CIDR block.

Apply network policies in specific order

To control the order/sequence of applying network policies, you can use the order field (with precedence from the lowest value to highest). Defining policy order is important when you include both action: allow and action: deny rules that may apply to the same endpoint.

In the following example, the policy allow-cluster-internal-ingress (order: 10) will be applied before the policy drop-other-ingress (order: 20).

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: drop-other-ingress
spec:
  order: 20
  ...deny policy rules here...---apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allow-cluster-internal-ingress
spec:
  order: 10
  ...allow policy rules here...

Conclusion

Calico Network Policies provide extensive support for creating various Network Policies which are not supported by Kubernetes by default. They are handy for laying out cluster wide policies for pod and node traffic control.

Learn more about technology at Expedia Group