# Kubernetes NetworkPolicy

쿠버네티스 클러스터는 기본적으로 Pod 간 통신에 어떠한 제한도 두지 않는 “모든 허용(all-allow)” 상태로 동작합니다. 운영 환경에서는 이 상태가 보안 위험이 될 수 있고, 서비스 간 불필요한 접근이나 내부 트래픽 유출 가능성도 커집니다. NetworkPolicy는 이 문제를 해결하려고 등장했으며, Pod 레벨의 네트워크 방화벽 규칙을 정의해 제로 트러스트(Zero Trust) 네트워크를 구현하는 핵심 도구입니다.

이 글에서는 NetworkPolicy의 핵심 개념과 Ingress(수신 트래픽), Egress(송신 트래픽) 동작 원리를 살펴보고, 실무에서 쓸 수 있는 고급 패턴과 보안 전략을 다룹니다.

# 1. NetworkPolicy란 무엇인가?

NetworkPolicy는 Kubernetes에서 제공하는 L3/L4 계층 기반의 네트워크 접근 제어 정책입니다. 간단히 말해, 특정 Pod가 어떤 Pod, 네임스페이스, 또는 외부 네트워크와 통신할 수 있는지를 명시적으로 허용(Whitelist)하는 방식으로 동작합니다.

네임스페이스 범위: 정책은 특정 네임스페이스 내에서만 유효하며, podSelector를 통해 적용할 Pod를 지정합니다.
화이트리스트 모델: 정책이 없는 경우 모든 트래픽이 허용됩니다. 격리는 Pod 단위, 방향 단위로 정해집니다. 어떤 Pod를 선택하면서 policyTypes에 Ingress가 들어 있는 정책이 하나라도 있으면 그 Pod의 수신 트래픽은 규칙에 맞는 것만 허용되고, Egress도 같은 방식으로 송신 트래픽에 따로 적용됩니다. 선택되지 않은 Pod나 정책이 없는 방향은 계속 모두 허용됩니다.
포트 및 프로토콜 기반 제어: TCP, UDP, SCTP 등 프로토콜과 특정 포트를 기준으로 접근을 세밀하게 제어할 수 있습니다.

# 2. Ingress와 Egress의 개념과 차이점

# 2-1. Ingress (수신 트래픽 제어)

Ingress 정책은 Pod로 들어오는 트래픽을 제한합니다. 예를 들어, role=backend Pod가 role=frontend Pod로부터 오는 요청만 수락하도록 할 수 있습니다. Ingress 규칙이 적용되면 지정된 소스 외의 모든 접근은 기본적으로 거부됩니다.

# 2-2. Egress (송신 트래픽 제어)

Egress 정책은 Pod에서 나가는 트래픽을 제어합니다. 예를 들어, role=frontend Pod가 외부 인터넷 또는 특정 CIDR 대역으로만 통신할 수 있도록 제한할 수 있습니다. 보안상 중요한 DB나 외부 API 접근을 최소화할 때 유용합니다.

# 3. 동작 메커니즘과 CNI 플러그인

NetworkPolicy 자체는 추상화된 정책 정의 리소스일 뿐, 실제로 이를 적용하는 것은 CNI(Container Network Interface) 플러그인입니다.

지원 CNI: Calico, Cilium, Weave Net, Kube-router 등.
비지원 CNI: 기본 Flannel(추가 설정이 없으면 정책 적용 불가).

CNI는 NetworkPolicy 정의를 기반으로 iptables 또는 eBPF 규칙을 생성하여 Pod 간 트래픽을 차단하거나 허용합니다. 특히 Cilium은 eBPF를 활용하여 성능 오버헤드를 줄이고, L7 레벨 정책까지 확장할 수 있다는 장점이 있습니다.

# 4. NetworkPolicy 주요 구성 요소

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: example-policy
  namespace: app
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 80
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 443

podSelector: 정책이 적용될 Pod를 선택.
policyTypes: Ingress, Egress 중 어떤 트래픽을 제어할지 명시.
ingress/from: 수신 트래픽 허용 규칙.
egress/to: 송신 트래픽 허용 규칙.
ports: 허용할 포트 및 프로토콜 정의.

# 5. 고급 예시

# 5-1. Ingress 예시

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: app
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 80

결과: backend Pod는 frontend Pod의 80포트 접근만 허용.

# 5-2. Egress 예시

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: app
spec:
  podSelector:
    matchLabels:
      role: frontend
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 443

결과: frontend Pod는 10.0.0.0/24 네트워크의 HTTPS(443)만 통신 허용.

# 5-3. Default Deny (기본 차단)

모든 트래픽을 차단하고 필요한 규칙만 허용하기 위해 아래와 같이 기본 차단 정책을 먼저 설정할 수 있습니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: app
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

# 6. 실무 설계 전략

# 6-1. Zero Trust 아키텍처

NetworkPolicy는 모든 트래픽을 기본 차단하고 필요한 통신만 허용하는 제로 트러스트 방식과 잘 맞습니다. 서비스 간 접근 경로를 최소화하고, Pod 간 권한을 명확히 구분할 수 있습니다.

# 6-2. DNS 및 외부 접근 제어

Egress 정책을 사용할 때는 DNS(port 53) 트래픽이 차단될 수 있으므로, 필요한 DNS 서버로 가는 트래픽을 허용해야 합니다. 예:

egress:
- to:
  - ipBlock:
      cidr: 10.96.0.10/32   # CoreDNS IP
  ports:
  - protocol: UDP
    port: 53

# 6-3. Observability와 정책 검증

Cilium Hubble을 사용하면 Pod 간 트래픽 흐름을 시각화하고, 정책 때문에 차단된 요청(hubble observe --verdict DROPPED)을 쉽게 파악할 수 있습니다. Kiali는 Istio 서비스 메시 트래픽을 시각화하는 도구라 NetworkPolicy에 의한 차단을 직접 보여 주지는 않습니다.
정책 테스트 시 kubectl exec 또는 netcat을 사용해 접근 허용 여부를 점검.

# 7. 성능 및 운영 고려사항

NetworkPolicy가 많아질수록 iptables 규칙이 늘어나 관리가 복잡해질 수 있습니다.
대규모 환경에서는 eBPF 기반 CNI(Cilium)를 고려해 성능 오버헤드를 줄이고, 정책 관리 효율성을 높일 수 있습니다.
Ingress/Egress를 잘못 설정하면 내부 서비스 통신이 끊길 수 있으므로, 정책을 점진적으로 적용(네임스페이스 단위 테스트 후 전체 배포)하는 편이 안전합니다.

# 8. 마무리

NetworkPolicy는 Kubernetes 네트워크 보안의 핵심 도구로, Ingress와 Egress를 적절히 조합해 최소 권한(Least Privilege) 원칙을 구현할 수 있습니다.

Ingress는 외부에서 Pod로 들어오는 트래픽,
Egress는 Pod에서 외부로 나가는 트래픽을 제어합니다.

CNI의 특성을 이해한 상태에서 기본 차단 정책 위에 필요한 트래픽만 허용하는 전략이 프로덕션 보안의 모범 사례입니다.

다음 글에서는 Calico와 Cilium이 제공하는 고급 패턴(GlobalNetworkPolicy, DNS 기반 필터링, L7 레벨 제어)을 다뤄 심화 시리즈로 이어가겠습니다.

← Gateway API와 HTTPRoute LimitRange와 ResourceQuota →