Implementing Zero Trust with K8s NetworkPolicy: Practical Ingress/Egress Traffic Control

Kubernetes NetworkPolicy Complete Guide: Practical Traffic Control for Zero Trust

Kubernetes revolutionized container orchestration, but behind that convenience sits a serious problem: network security. By default, a Kubernetes cluster lets pods talk to each other, and that model assumes trust. If an attacker compromises even one pod, that pod can reach other services as if it were on an open internal network.

Defending against those insider threats—and treating every connection as untrusted until it is verified—is the core of Zero Trust Architecture (ZTA). The most powerful, native way to implement that principle at the Kubernetes layer is NetworkPolicy.

This guide is not just concepts. It walks through how to control traffic precisely using the Principle of Least Privilege, with YAML you can use in real clusters.

Limits of Kubernetes Networking and Why NetworkPolicy Matters

Classic Kubernetes networking is mainly about L3/L4 connectivity. Service and Ingress tell you which ports are reachable, but they do little to answer who may connect, and under what conditions.

💡 An analogy: Think of the cluster as a large office building.

• Default networking: Power and internet are wired through the whole building. Connectivity is guaranteed.
• NetworkPolicy: Each office (pod) needs an access card (Selector), and you can only reach certain floors (Namespaces) at certain times (Port/Protocol)—an ACL-style access-control system.

NetworkPolicy is that access-control system: only explicitly allowed traffic passes; everything else is denied.

How NetworkPolicy Works: Default Deny and Selectors

The most important idea in NetworkPolicy is Default Deny.

Once you apply a NetworkPolicy to a namespace or a set of pods, traffic in that scope is blocked by default. Before the policy, everything was allowed. After it, nothing is allowed unless you say so.

You then explicitly Allow only the paths you need.

Core building blocks: Selectors and Pod/Namespace targeting

NetworkPolicy uses podSelector and namespaceSelector to target policies precisely.

• podSelector: The pods the policy applies to (e.g. all pods with app: backend).
• namespaceSelector: The namespaces the policy applies to.

Combine them to apply a policy only to “pods with label X inside namespaces with label Y.”

🛡️ Ingress Control: Restricting Inbound Access from Outside or Other Pods

Ingress control governs traffic into your pods from outside the cluster or from other in-cluster services. It is like managing visitors entering a company building.

[YAML example 1: Allow access only from specific pods]

This policy applies to pods labeled backend. It allows only HTTP (port 80) from pods labeled frontend and blocks everything else.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend # 이 정책이 적용될 대상 파드
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend # 오직 이 레이블을 가진 파드에서만 허용
      ports:
        - protocol: TCP
          port: 80

📤 Egress Control: Restricting Outbound Traffic from Pods

Egress control governs what a pod may send to the internet or to other in-cluster services. It is like limiting which external partners internal staff are allowed to contact.

[YAML example 2: Allow outbound traffic only to a specific IP range]

This policy restricts api-worker pods so they can only make outbound connections to a database IP range (10.0.1.0/24).

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress-to-db
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: api-worker # 이 정책이 적용될 대상 파드
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.1.0/24 # 허용할 외부 IP 대역
      ports:
        - protocol: TCP
          port: 5432 # PostgreSQL 포트

🧩 Production Scenario: Combined Policies and Troubleshooting

In production, policies often overlap, and you usually need to allow only specific ports and protocols.

[YAML example 3: Combined allow policy (HTTP and internal metrics only)]

This policy allows access to the pods, but only two kinds of traffic: port 80 (HTTP) and 9100 (Prometheus metrics).

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-http-and-metrics
  namespace: monitoring
spec:
  podSelector:
    matchLabels:
      app: web-service
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: 0.0.0.0/0 # 모든 외부 트래픽 허용 (예시)
      ports:
        - protocol: TCP
          port: 80
        - protocol: TCP
          port: 9090 # 다른 포트도 추가 가능

💡 Debugging tip: Policy order and conflicts

Network policies give the most specific rule the highest priority. If you do not want a port open, but another policy allows 0.0.0.0/0 (all IPs), that broad rule can win and open ports you did not intend. Always specify only the minimum ports and source IPs you need—that is the safest approach.

Summary:

1. Ingress (Inbound): Control traffic into containers from outside (most important).
2. Egress (Outbound): Control traffic leaving containers (required when you tighten security).
3. Principle: Allow only what you need and deny the rest by default. Stick to Default Deny.

References: Official docs

The primary source for the behavior, configuration, and errors in this article is the official documentation below. Use it for version-specific options and exact semantics.

• Kubernetes official documentation