쿠버네티스 NetworkPolicy: Zero Trust 기반 서비스 통신 제어 실습 가이드

쿠버네티스 Network Policy 완벽 가이드: Zero Trust 기반 서비스 통신 제어하기

마이크로서비스 아키텍처(MSA)가 대세가 되면서, 애플리케이션의 복잡성은 기하급수적으로 증가했습니다. 수많은 서비스들이 서로 통신하며 거대한 생태계를 이루지만, 이 '연결성'이야말로 가장 큰 보안 취약점이 될 수 있습니다. 마치 내부망에 들어온 공격자가 마치 합법적인 직원인 것처럼 자유롭게 돌아다닐 수 있는 환경과 같습니다.

이러한 환경에서 "우리 서비스는 A 서비스와만 통신해야 하는데, 왜 C 서비스와도 통신하는 거지?"라는 근본적인 질문에 답하는 것이 바로 **쿠버네티스 네트워크 정책(Network Policy)**입니다. 이 가이드는 단순한 개념 설명을 넘어, 실제 운영 환경에서 어떻게 제로 트러스트(Zero Trust) 원칙을 네트워크 레벨에서 구현할 수 있는지 구체적인 실습 지침을 제공합니다.

🛡️ 왜 쿠버네티스 환경에서 네트워크 정책이 필수인가?

전통적인 데이터센터 보안 모델은 '경계 방어(Perimeter Defense)'에 의존했습니다. 즉, 외부에서 들어오는 트래픽만 막으면 내부에서는 안전하다고 가정하는 방식입니다. 하지만 MSA 환경은 이 가정이 무너집니다. 컨테이너는 격리되어 있지만, 파드(Pod) 간의 통신은 기본적으로 허용되는 경우가 많습니다.

이러한 기본 동작 방식은 개발 초기 단계에서는 편리하지만, 보안 관점에서는 치명적인 허점입니다. 만약 한 서비스(예: 인증 모듈)가 해킹당했을 때, 공격자는 이 정책의 허점을 이용해 다른 민감한 서비스(예: 결제 모듈)로 측면 이동(Lateral Movement)을 시도할 수 있습니다.

핵심은 '신뢰하지 않는 것(Never Trust)'입니다. 네트워크 정책은 이 신뢰의 개념 자체를 폐기하고, 오직 명시적으로 허가된 통신 경로만을 열어주는 방화벽 역할을 수행합니다. 이것이 바로 제로 트러스트 아키텍처의 네트워크 구현 핵심입니다.

⚙️ 네트워크 정책의 작동 원리와 기본 구조 이해하기

네트워크 정책은 쿠버네티스 파드(Pod) 레벨에서 L3(IP) 및 L4(포트/프로토콜) 수준의 트래픽을 제어하는 규칙 집합입니다. 이 정책은 클러스터에 배포된 CNI(Container Network Interface) 플러그인(예: Calico, Cilium)에 의해 실제로 네트워킹 규칙으로 변환되어 적용됩니다.

가장 기본적인 정책은 특정 네임스페이스 또는 파드 셀렉터(Pod Selector)를 대상으로 지정하며, Ingress(들어오는 트래픽)와 Egress(나가는 트래픽)을 각각 제어할 수 있습니다.

💡 기본 YAML 예시: 특정 포트만 허용하기

다음은 frontend 네임스페이스의 api-server 파드가 외부에서 8080 포트로만 접근 가능하도록 Ingress를 제한하는 예시입니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-api-ingress
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: ingress-controller # Ingress Controller에서 오는 트래픽만 허용
      ports:
        - protocol: TCP
          port: 8080

이 코드를 이해하는 핵심은 from 필드입니다. from에 명시되지 않은 모든 소스(Source)로부터의 트래픽은 기본적으로 차단됩니다.

🧱 심층 분석: 최소 권한 원칙(Principle of Least Privilege) 적용

네트워크 보안에서 '최소 권한 원칙'은 "각 주체(서비스)는 자신의 업무 수행에 필요한 최소한의 리소스에만 접근할 권한을 가져야 한다"는 보안 원칙입니다. 네트워크 정책으로 이를 구현한다는 것은, **"이 서비스는 이 포트와 이 서비스와만 통신할 권한이 있다"**라고 명시하는 것과 같습니다.

🌐 Ingress와 Egress 제어의 구체적 Use Case

1. Ingress 제어 (들어오는 트래픽 제한):
   • Use Case: 사용자 인증 서비스(auth-svc)는 오직 로드 밸런서(Ingress Controller)에서 오는 443 포트의 HTTPS 트래픽만 받아야 합니다. 다른 내부 서비스의 직접 접근은 차단해야 합니다.
2. Egress 제어 (나가는 트래픽 제한):
   • Use Case: 결제 서비스(payment-svc)는 외부 PG사 API 서버(특정 IP/도메인)와 통신해야 합니다. 내부의 다른 마이크로서비스로 임의로 데이터를 전송하는 것은 막아야 합니다.

📊 보안 수준 비교: Default Allow vs. Default Deny

🚨 실전 적용 및 고급 고려사항: Default Deny 전략

가장 강력한 보안 전략은 '기본적으로 모든 것을 차단하고, 필요한 것만 허용하는(Default Deny)' 방식입니다.

만약 네임스페이스에 아무런 NetworkPolicy도 적용하지 않았다면, 기본적으로 모든 트래픽이 허용됩니다. 따라서 가장 먼저 해야 할 일은, 해당 네임스페이스의 모든 파드에 대해 기본적으로 모든 Ingress/Egress를 차단하는 정책을 적용하는 것입니다.

⚠️ 정책 설정 오류 시 디버깅 가이드 (실패 사례)

가장 흔한 실수는 **'필요한 통신 경로를 누락'**하는 것입니다. 예를 들어, user-service가 database-svc에 접속해야 하는데, 정책에 database-svc의 레이블 셀렉터를 빠뜨리면, 서비스는 마치 통신이 안 되는 것처럼 보입니다.

디버깅 팁:

1. kubectl describe networkpolicy <policy-name>: 정책이 실제로 어떤 셀렉터와 포트를 대상으로 하는지 확인합니다.
2. CNI 로그 확인: 사용 중인 CNI(예: Calico)의 로그를 확인하여, 해당 트래픽이 정책에 의해 명시적으로 차단(Dropped)되었는지 확인하는 것이 가장 확실합니다.

[실무자의 경험적 조언] 저는 초기 프로젝트에서 이 부분을 간과하여, 서비스 간의 로깅(Logging) 트래픽이 차단되는 바람에 장애를 겪은 적이 있습니다. 네트워크 정책을 설계할 때는 '비즈니스 트래픽' 외에 **'모니터링/로깅 트래픽'**에 대한 예외 규칙을 반드시 별도로 정의하는 것이 안정적인 운영의 핵심입니다.

🚀 결론: 네트워크 보안을 통한 아키텍처 성숙도 높이기

네트워크 정책의 도입은 단순한 보안 패치를 넘어, 아키텍처의 성숙도를 한 단계 끌어올리는 과정입니다. 이는 개발팀에게 "당신들이 어떤 통신을 할지 명확히 문서화하고 코드로 증명하라"는 요구를 하는 것과 같습니다.

다음 단계 로드맵:

1. Audit: 현재 클러스터의 모든 서비스 간 통신 흐름을 매핑합니다.
2. Define: 각 통신에 필요한 최소한의 포트, 프로토콜, 소스/목적지 파드를 정의합니다.
3. Implement: 'Default Deny' 정책을 최상위 레벨에 적용하고, 필요한 통신에 대해 예외 정책을 순차적으로 추가합니다.

이 과정을 거치면, 여러분의 쿠버네티스 클러스터는 단순한 컨테이너 묶음이 아닌, 강력하게 통제되는 '보안 경계가 명확한 시스템'으로 진화할 것입니다.

자주 묻는 질문 (FAQ)

Q1. NetworkPolicy를 적용하려면 모든 파드가 동일한 네임스페이스에 있어야 하나요? A1. 아닙니다. podSelector를 사용하여 특정 레이블을 가진 파드 그룹에 정책을 적용할 수 있으며, from 필드에서도 레이블 셀렉터를 사용하여 다른 네임스페이스의 파드까지 참조할 수 있습니다.

Q2. NetworkPolicy를 적용했는데 통신이 안 되는 경우, 가장 먼저 확인해야 할 것은 무엇인가요? A2. 가장 먼저 확인해야 할 것은 사용 중인 CNI 플러그인(Calico, Cilium 등)이 NetworkPolicy를 지원하는지, 그리고 해당 네임스페이스에 정책이 실제로 배포되었는지(kubectl get netpol -n <namespace>) 확인하는 것입니다.

Q3. 서비스 메시(Service Mesh)를 사용하면 NetworkPolicy가 필요 없나요? A3. 아닙니다. 서비스 메시(Istio, Linkerd 등)는 L7(HTTP 헤더, 메서드) 레벨의 정책 제어를 제공하여 보안성을 높이지만, 네트워크 정책은 L3/L4 레벨의 근본적인 트래픽 흐름을 차단하는 '최후의 방어선' 역할을 하므로, 두 가지를 함께 사용하는 것이 가장 강력한 보안 조합입니다.