작동하던 서비스가 멈췄을 때: K8s NetworkPolicy Default Deny 안전 도입 가이드

"어제까지는 완벽하게 통신하던 서비스인데, 오늘 아침부터 특정 마이크로서비스 간 통신이 갑자기 끊겼다."

쿠버네티스 환경에서 이러한 경험을 해보신 분이라면, 네트워크 정책(NetworkPolicy)을 한 번쯤 깊이 고민해 보셨을 겁니다. NetworkPolicy는 클러스터의 보안 수준을 비약적으로 끌어올려주는 강력한 기능이지만, 그만큼 '양날의 검'과 같습니다. 정책 하나를 잘못 적용하거나, CNI의 동작 방식을 이해하지 못하면, 가장 중요한 순간에 서비스 전체를 마비시키는 원인이 될 수 있습니다.

이 가이드는 단순히 NetworkPolicy를 적용하는 방법을 나열하는 것을 넘어, 운영 환경에서 발생 가능한 의도치 않은 서비스 중단(DoS) 시나리오를 예측하고, CNI별 특성을 이해하여 '기본 거부(Default Deny)' 정책을 가장 안전하게 도입하는 체계적인 방법론을 제시합니다.

네트워크 정책의 원리와 '기본 거부(Default Deny)'의 함정

NetworkPolicy란 무엇인가?

NetworkPolicy는 특정 파드(Pod)나 네임스페이스(Namespace)에 대해 '누가, 어디로, 어떤 트래픽을 보낼 수 있는지'를 명시적으로 정의하는 규약입니다. 기본적으로 쿠버네티스 클러스터는 모든 파드 간의 통신을 허용하는 'Permissive' 모드에 가깝습니다. NetworkPolicy를 적용한다는 것은 이 기본 허용 규칙을 깨고, **'명시적으로 허용된 트래픽만 통과시킨다'**는 원칙을 세우는 것입니다.

Default Deny의 매력과 위험성

'Default Deny'는 가장 강력한 보안 모델입니다. 이는 "명시적으로 허용되지 않은 모든 트래픽은 무조건 차단한다"는 의미를 가지며, Zero Trust Architecture(ZTA)의 핵심 원칙과 일치합니다.

⚠️ 경고: Default Deny의 함정 Default Deny를 무작정 적용하는 것은 매우 위험합니다. 만약 애플리케이션이 의존하는 백엔드 데이터베이스, 캐시 서버, 혹은 모니터링 에이전트 등 사소해 보이는 서비스 중 하나라도 정책에 빠뜨리면, 해당 서비스는 아무런 경고 없이 '통신 불가' 상태에 빠지게 됩니다. 이는 단순한 장애가 아닌, 보안 정책으로 인한 '서비스 거부' 상태일 수 있습니다.

CNI 플러그인별 정책 처리 방식의 근본적 차이 분석

NetworkPolicy를 실제로 클러스터에 적용하는 주체는 CNI(Container Network Interface) 플러그인입니다. Calico와 Cilium은 대표적인 플레이어이며, 이들이 정책을 처리하는 방식의 차이를 이해하는 것이 디버깅의 핵심입니다.

실무 관점의 조언: 만약 클러스터 규모가 매우 크고, 복잡한 애플리케이션 레벨의 제어(예: "특정 API 경로만 허용")가 필요하다면, eBPF 기반의 Cilium이 장기적으로 더 유연하고 성능상의 이점을 제공할 수 있습니다. 하지만 기존에 Calico 환경에 익숙하거나, 오직 IP/Port 레벨의 제어만 필요하다면, 현재 환경에 맞춰 점진적으로 접근하는 것이 안전합니다.

[실습 가이드] 3단계로 안전하게 Default Deny 정책 도입하기

'Default Deny'를 도입하는 과정은 '완벽한 허용 목록 작성'의 과정입니다. 다음 3단계의 순서를 반드시 지켜주세요.

1단계: Baseline (현재 상태) 파악 및 로깅 모드 운영

가장 먼저, 정책을 차단(Deny)하는 것이 아니라, '어떤 트래픽이 정책 위반으로 시도되는지'를 기록(Log)만 하도록 CNI 설정을 변경합니다.

• 목표: 모든 서비스 간의 정상적인 트래픽 흐름을 100% 기록합니다.
• 실행: NetworkPolicy를 적용하되, policyTypes: [Ingress, Egress]를 설정하고, 차단 대신 로깅 기능이 활성화된 모드로 테스트합니다.

2단계: Whitelist (화이트리스트) 작성 및 적용

로그 분석을 통해 필수적인 통신 쌍(Source Pod A $\rightarrow$ Destination Pod B: Port X)을 모두 식별합니다. 이 목록을 기반으로 최소한의 허용 규칙만 담은 NetworkPolicy를 작성합니다.

💡 Default Deny 적용 예시 YAML (Namespace secure-app에 적용)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: secure-app
spec:
  podSelector: {} # 이 네임스페이스의 모든 파드에 적용
  policyTypes:
  - Ingress
  - Egress
  # 아래 규칙이 없으면, 모든 트래픽은 기본적으로 차단됨 (Default Deny)
  # 따라서, 여기에 '허용해야 할' 규칙만 명시적으로 추가해야 함.
  # 예시: Ingress로만 특정 네임스페이스의 Pod A로부터의 8080 포트만 허용
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
      namespaceSelector:
        matchLabels:
          name: ingress-ns
    ports:
    - protocol: TCP
      port: 8080

3단계: 검증 및 롤아웃 (Gradual Rollout)

작성된 정책을 전체 네임스페이스에 한 번에 적용하지 않습니다. 가장 중요도가 낮은 서비스 그룹부터 순차적으로 적용하고, 해당 그룹의 모니터링 지표(Latency, Error Rate)를 24시간 이상 관찰해야 합니다.

🚨 트래픽 차단이 의심될 때의 5단계 디버깅 플로우

정책 적용 후 통신 장애가 발생했다면, 다음 순서대로 체계적으로 접근해야 합니다.

1. Scope 확인: 문제가 발생한 파드/네임스페이스에 NetworkPolicy가 적용되어 있는지 확인합니다.
2. 정책 검토: 적용된 모든 정책(Ingress/Egress)을 확인하고, 통신에 필요한 포트와 프로토콜이 명시적으로 허용되었는지 검토합니다.
3. 네트워크 트레이스: tcpdump 또는 netshoot 같은 도구를 사용하여, 통신 시 패킷이 아예 도달하지 않는지 (L3/L4 문제) 아니면 응답만 오지 않는지 (애플리케이션 문제) 확인합니다.
4. 정책 임시 우회: 문제가 되는 정책을 일시적으로 비활성화하고, 통신이 정상화되는지 확인하여 원인 정책을 특정합니다.
5. 최소 권한 원칙 재적용: 원인을 찾았다면, 해당 통신에 필요한 최소한의 권한만 허용하도록 정책을 수정하고 재적용합니다.

이 과정을 통해, '막연한 실패'가 아닌 '어떤 규칙에 의해 차단되었는지'를 정확히 파악할 수 있습니다.