쿠버네티스 네트워크 정책은 차단보다 관찰 모드로 시작하라

NetworkPolicy가 없는 클러스터에서는 같은 네트워크에 있는 Pod 사이 통신이 예상보다 넓을 수 있다. 한 워크로드가 침해되면 서비스 탐색과 내부 API 접근이 쉬워지고, 개발·운영 네임스페이스의 경계가 이름뿐인 상태가 될 수 있다. 그렇다고 운영 클러스터에 default-deny를 한 번에 적용하면 DNS, 메트릭, 웹훅, 결제 콜백처럼 문서화되지 않은 경로가 끊어진다.

여기서 말하는 “관찰 모드”는 표준 NetworkPolicy 객체의 기능명이 아니다. CNI 흐름 로그, 서비스 메시, eBPF 관측, 애플리케이션 텔레메트리로 후보 정책의 영향을 먼저 계산하는 운영 단계다. 사용하는 CNI가 NetworkPolicy를 지원하지 않으면 객체가 생성돼도 트래픽이 차단되지 않을 수 있으므로, 배포 전에 실제 집행 테스트가 필요하다.

시작 전 확인할 네 가지 전제

1. 정책 엔진: CNI와 버전이 ingress·egress NetworkPolicy를 지원하고 실제로 집행하는가.
2. 라벨 품질: Pod와 네임스페이스 라벨이 소유자·환경·서비스 역할을 안정적으로 나타내는가.
3. 흐름 가시성: 출발 Pod, 목적지, 포트, 프로토콜, 허용·차단 결과를 볼 수 있는가.
4. 복구 경로: 정책을 제거하거나 이전 버전으로 되돌릴 권한과 긴급 접속 수단이 있는가.

테스트 네임스페이스에서 허용 정책 없이 ingress와 egress를 거부한 뒤, 예상 통신이 실제로 실패하는지 확인한다. 이 검증이 없으면 “정책이 배포됐다”는 상태만 남고 격리는 작동하지 않을 수 있다.

흐름 인벤토리는 서비스 이름으로 만든다

IP 주소만 모으면 Pod 재시작과 오토스케일링 때 의미가 사라진다. 다음 필드를 서비스 단위로 집계한다.

필드	용도
출발 네임스페이스·워크로드·서비스 계정	누가 연결했는지 식별
목적 네임스페이스·서비스 또는 외부 FQDN	업무 의존성 확인
포트·프로토콜	최소 허용 범위 결정
빈도·바이트·시간대	정상 배치와 이상 통신 구분
소유 팀·변경 티켓	허용 근거와 만료 관리
마지막 관찰 시각	오래된 예외 제거

최소 한 번의 배포 주기, 정기 배치, 백업, 장애 조치 훈련을 포함해 관찰한다. 짧은 평일 낮 표본만 보면 월말 정산과 야간 백업 경로가 빠진다. 다만 관찰 기간이 끝없이 연장되지 않도록 종료 날짜를 정한다.

단계별 적용 순서

1단계: 수신 경계부터 작은 네임스페이스에 적용

외부 입력이 적고 소유자가 분명한 비운영 네임스페이스를 고른다. 먼저 모든 ingress를 거부하고 인그레스 컨트롤러, 필요한 내부 호출, 모니터링만 허용한다. 정책 선택자가 의도한 Pod를 실제로 선택하는지 확인한다.

2단계: egress 기본 거부 전 DNS와 기반 서비스를 분리

egress를 막으면 DNS 조회 자체가 실패할 수 있다. 클러스터 DNS의 네임스페이스·라벨·포트가 환경마다 다르므로 실제 배치를 확인해 허용한다. 그 다음 인증, 비밀 관리, 메트릭, 로그, 메시지 큐, 데이터베이스, 외부 API를 서비스 소유자별 규칙으로 추가한다.

3단계: 운영은 카나리 워크로드 또는 네임스페이스로 확대

동일 서비스의 일부 Pod만 별도 라벨로 선택하거나 영향이 낮은 네임스페이스부터 전환한다. 정책 배포와 애플리케이션 배포를 같은 변경 창에서 섞지 않는다. 그래야 오류 원인을 구분하고 되돌릴 수 있다.

4단계: 임시 허용을 제거하고 정책을 코드로 관리

광범위한 0.0.0.0/0, 전체 네임스페이스, 모든 포트 허용은 긴급 복구에만 쓰고 소유자와 만료일을 붙인다. 정책은 코드 리뷰, 자동 검증, 스테이징 테스트를 거쳐 배포하며 클러스터에서 직접 수정된 드리프트를 탐지한다.

최소 정책 구조 예시

아래 예시는 개념을 보여 주는 시작점이다. 라벨과 DNS 대상은 실제 클러스터에서 검증해야 한다.

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

기본 거부 뒤에는 필요한 통신만 별도 정책으로 허용한다. 한 파일에 모든 예외를 넣기보다 allow-from-ingress, allow-to-dns, allow-to-database처럼 목적과 소유자가 드러나는 단위가 검토와 폐기에 유리하다.

놓치기 쉬운 실패 모드

실패 모드	증상	대응
CNI가 정책을 집행하지 않음	금지 테스트가 계속 성공	지원 여부·설정 확인, 실제 패킷 테스트
DNS 허용 누락	이름 조회 실패, 재시도 급증	DNS Pod·서비스·포트 실측 후 최소 허용
라벨 변경으로 정책 이탈	새 릴리스 Pod만 차단 또는 무제한	필수 라벨 검증과 admission 정책
모니터링·웹훅 누락	메트릭 공백, 배포·인증 실패	플랫폼 의존성 목록을 별도 관리
외부 API IP 변동	간헐적 연결 실패	CNI의 FQDN 기능 여부 검토 또는 egress 프록시
hostNetwork·노드 경로 오해	정책 밖 통신이 남음	구현별 범위 확인, 노드 방화벽과 병행

NetworkPolicy는 L3/L4 경계다. HTTP 경로, 사용자 권한, TLS 신뢰, 데이터베이스 권한을 대신하지 않는다. 서비스 계정과 워크로드 신원은 제로 트러스트 신원 경계와 함께 설계한다.

탐지 지표와 중단 기준

배포 전 기준선과 비교해 다음을 본다.

• DNS 오류율과 조회 지연
• TCP 연결 실패·재전송·타임아웃
• 5xx, 큐 적체, 배치 지연, 외부 콜백 실패
• 정책별 허용·차단 흐름과 새 목적지
• 긴급 허용 정책 수와 만료 초과 건수

핵심 사용자 흐름의 오류율 또는 지연이 사전에 정한 임계값을 넘거나, 관측이 끊겨 원인을 판단할 수 없으면 확대를 중단한다. 롤백은 전체 정책 엔진을 끄는 대신 마지막 변경 정책만 되돌리고, 필요한 경우 좁은 임시 허용을 시간 제한으로 추가한다.

운영 체크리스트

• CNI가 정책을 실제 집행하는지 금지 통신으로 시험했다.
• 배포·배치·백업·장애 조치를 포함해 흐름을 관찰했다.
• DNS, 인그레스, 모니터링, 웹훅, 인증 경로를 별도 확인했다.
• 네임스페이스와 워크로드 라벨의 소유자·규칙이 있다.
• 기본 거부를 비운영·카나리부터 단계적으로 적용한다.
• 광범위 허용에는 사유·소유자·만료일이 있다.
• 오류율·연결 실패·차단 로그를 함께 보는 중단 기준이 있다.
• 정책 변경과 애플리케이션 릴리스를 분리해 원인과 롤백을 단순화했다.

컨테이너 실행 권한은 쿠버네티스 Pod Security 기준선에서, 배포 자격증명은 CI/CD 시크릿 관리에서 이어서 점검할 수 있다.

참고 기준

• Kubernetes Network Policies
• Kubernetes Security Checklist
• CNCF Cloud Native Security Whitepaper

좋은 네트워크 정책은 연결을 많이 차단한 정책이 아니다. 서비스가 왜 통신하는지 소유자가 설명할 수 있고, 새로운 경로가 생기면 검토되며, 잘못된 차단은 좁은 범위에서 빠르게 되돌릴 수 있는 정책이다.