Network Policies

Kubernetes network policies provide a declarative way to control traffic between pods, ensuring secure and isolated communication within a cluster. By leveraging policies, you can enforce rules that restrict or allow traffic based on labels, IP ranges, ports, and protocols. This section covers how to configure and enforce network policies to achieve workload isolation and secure inter-pod communication.

---

Overview of Network Policies

Network policies operate at the pod level and define rules for ingress (incoming) and egress (outgoing) traffic. They are namespace-scoped by default, meaning policies apply to pods within the same namespace unless explicitly configured otherwise. Policies are enforced by the CNI (Container Network Interface) provider (e.g., Calico, Cilium, Flannel), which translates policy rules into low-level network configurations.

Key concepts:
- PodSelector: Targets specific pods using labels.
- Ingress Rules: Define allowed incoming traffic (e.g., HTTP on port 80).
- Egress Rules: Define allowed outgoing traffic (e.g., HTTPS to external IPs).
- PolicyTypes: Specify whether the policy applies to ingress, egress, or both.

---

Policy Structure

A typical network policy YAML file includes the following fields:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: example-policy
  namespace: default
spec:
  podSelector: {}  # Selects all pods in the namespace
  ingress:
    - ports:
        - protocol: TCP
          port: 80
  egress:
    - ports:
        - protocol: TCP
          port: 443
  policyTypes:
    - Ingress
    - Egress

• podSelector: Use labels to target specific pods (e.g., matchLabels: app: my-app).
• Ingress: Rules for incoming traffic (e.g., allow traffic on port 80).
• Egress: Rules for outgoing traffic (e.g., restrict to HTTPS).
• policyTypes: Set to Ingress, Egress, or both.

---

Enforcement Mechanisms

Kubernetes itself does not enforce network policies; the CNI provider handles this. For example:
- Calico uses iptables rules to filter traffic.
- Cilium leverages eBPF for high-performance enforcement.
- Flannel relies on iptables for basic policy enforcement.

Policies are applied in the order they are defined, but Kubernetes does not enforce priority. Always test policies in a staging environment before deploying to production.

---

Example Scenarios

1. Allow Intra-namespace Traffic

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-internal
  namespace: default
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: internal
      ports:
        - protocol: TCP
          port: 80
  policyTypes:
    - Ingress

This policy allows pods in the internal namespace to communicate via TCP port 8, but blocks external access.

2. Restrict Egress to Specific IPs

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: default
spec:
  podSelector: {}
  egress:
    - to:
        - ipBlock:
            cidr: 192.168.1.0/24
      ports:
        - protocol: TCP
          port: 443
  policyTypes:
    - Egress

This policy restricts pods to outgoing HTTPS traffic to the 192.168.1.0/24 IP range.

---

Best Practices

1. Start with restrictive policies: Allow only necessary traffic to minimize attack surfaces.
2. Use labels and selectors: Target specific pods or services with precise labels.
3. Test in staging: Validate policies in a non-production environment to avoid disruptions.
4. Monitor and audit: Use tools like Prometheus and Grafana to track policy compliance and traffic patterns.
5. Combine with service meshes: For advanced control, integrate with tools like Istio or Linkerd for granular traffic management.

---

Key takeaways

• Network policies in Kubernetes control traffic between pods using declarative rules.
• Policies are enforced by CNI providers like Calico or Cilium, which translate rules into network configurations.
• Use podSelector, ingress, and egress to define granular traffic controls.
• Always test policies in staging and prioritize least-privilege access.
• Combine policies with observability tools to ensure compliance and detect anomalies.