Skip to main content
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.
The image shows the OSI Model with its seven layers: Application, Presentation, Session, Transport, Network, Data Link, and Physical.
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.
The image features a smiley face above a series of blue rectangles with text related to networking concepts, such as "Transmit Data using TCP/UDP," "Decide Physical Path," "Ports," and "IP Addressing."
Understanding the OSI model is crucial not only in Kubernetes but in networking as a whole. Network policies leverage the OSI layers to enforce secure and efficient traffic control.

​
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
  • Ingress:
    • Allows traffic from the CIDR range 172.17.0.0/16, with the exception of 172.17.1.0/24.
    • Permits traffic from pods in the namespace with the label project: myproject and pods with the label role: frontend.
    • Restricts allowed traffic to TCP port 6379.
  • Egress:
    • Limits outbound connections to IP addresses within the 10.0.0.0/24 range.
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.

Watch Video