Network Policies InterPod Security

At a high level, network policies manage traffic flow based on IP addresses and ports, effectively operating at OSI layers 3 and 4. Before diving into network policies, it's essential to revisit the OSI model.

The OSI Model

The OSI model comprises seven layers:

1. Application Layer: Determines how applications access network services.
2. Presentation Layer: Ensures data is in a usable format, including handling encryption.
3. Session Layer: Manages connections and controls ports and sessions.
4. Transport Layer: Transmits data using protocols like TCP or UDP.
5. Network Layer: Defines the physical path for data transfer through routing.
6. Data Link Layer: Specifies how data is formatted for transmission over the network.
7. Physical Layer: Transmits raw bitstreams over physical media.

In Kubernetes, the layered approach plays a critical role. For instance, an Ingress controller functions at the application layer, whereas network policies operate at the transport and network layers by regulating ports and IP addressing respectively.

Understanding Kubernetes Network Policies

Network policies in Kubernetes allow you to define how pods communicate with each other, as well as with external resources. These policies specify which endpoints (including pods, services, or entire namespaces) are allowed to exchange traffic, functioning similarly to rules enforced by routers or firewalls.

Imagine a scenario where you have two pods and require controlled traffic flow between them. Network policies let you set restrictions and permissions based on factors such as IP addresses, namespaces, and pod labels.

For example, consider the following requirements:

• Allow ingress traffic to a pod from a specific CIDR range (172.17.0.0/16), except for the subset 172.17.1.0/24.
• Permit additional traffic from pods within the namespace labeled project: myproject and pods with the label role: frontend.
• Restrict ingress traffic to only TCP port 6379 (commonly used by Redis).
• Limit egress traffic so that the pod can only communicate with IP addresses in the 10.0.0.0/24 range.

Below is an example network policy that demonstrates this configuration:

policyTypes:
  - Ingress
  - Egress
ingress:
  - from:
      - ipBlock:
          cidr: 172.17.0.0/16
          except:
            - 172.17.1.0/24
      - namespaceSelector:
          matchLabels:
            project: myproject
      - podSelector:
          matchLabels:
            role: frontend
  ports:
    - protocol: TCP
      port: 6379
egress:
  - to:
      - ipBlock:
          cidr: 10.0.0.0/24

Any traffic not matching these specified criteria will be blocked. For example, if ingress traffic comes from an IP outside the allowed ranges (e.g., 172.16.0.0 or 172.15.0.0), it will be denied.

This policy serves as a comprehensive guide for managing both inbound and outbound traffic at a granular level. Now that we've explored the core concepts and configuration details, you're ready to see these network policies in action during the demo.