쿠버네티스 네트워크 정책 운영: 흔한 실수와 교정 방법
네트워크 정책의 목적과 기본 개념을 오해하는 경우
많은 운영팀이 NetworkPolicy를 배포하면 클러스터 전체 트래픽이 차단된다고 오해합니다. 실제로 NetworkPolicy는 기본적으로 모든 트래픽을 차단하지 않으며, 오직 PodSelector로 선택된 파드에만 적용됩니다. 어떤 NetworkPolicy에도 포함되지 않은 파드는 들어오고 나가는 트래픽이 모두 허용됩니다.
- PodSelector: 같은 네임스페이스 안의 파드를 선택합니다. 정책을 적용하려면 정확한 selector로 대상 파드를 지정해야 합니다.
- NamespaceSelector: 피어를 지정할 때 네임스페이스 범위를 정합니다. 네임스페이스 수준으로 허용 대상을 지정할 뿐, 개별 파드 선택과는 별개입니다.
- policyTypes: Ingress와 Egress 중 어떤 방향을 제어할지 명시합니다. Egress를 제어하려면 'Egress'를 포함하거나 egress 룰을 반드시 추가하세요. 구현에 따라 명시하지 않으면 동작을 추론할 수 있으니 주의해야 합니다.
교정 포인트: 파드를 '격리(deny-by-default)'하려면 해당 파드를 선택하는 NetworkPolicy를 생성하고 빈 ingress/egress(또는 policyTypes 명시)를 통해 허용 항목만 열어야 합니다. 또한 사용 중인 CNI가 NetworkPolicy를 지원하는지 확인하고, hostNetwork, 노드 대상 트래픽, 서비스 IP 경로처럼 예외가 존재할 수 있는 부분도 점검하세요. 실무 체크리스트 예시 — 1) 대상 파드가 정확히 선택되는지, 2) 필요한 Ingress/Egress 규칙이 빠짐없이 포함되었는지, 3) CNI와 서비스/노드 트래픽 처리 방식을 검증했는지 순서대로 확인하면 효과적입니다. 이 내용은 쿠버네티스 네트워크 정책 운영 시 흔한 실수 및 교정 방법의 핵심 포인트입니다.
디폴트 거부(deny-by-default) 미적용으로 생기는 보안 취약점
쿠버네티스는 네트워크 폴리시를 적용하지 않으면 기본적으로 모든 파드 간·외부 트래픽을 허용한다. 이로 인해 서비스 노출, 횡적 이동(lateral movement), 민감 데이터 유출 등 현실적 위험이 발생하며, 권한 분리나 감사 요구가 엄격한 환경에서는 규정 위반으로 이어질 수 있다.
- 도입 방법: 먼저 각 네임스페이스에 모든 파드를 대상으로 하는 default-deny NetworkPolicy를 적용해 ingress와 egress를 모두 차단한다. 이후 신뢰되는 통신만 허용하도록 정책을 단계적으로 추가한다.
- 라벨 설계: role=frontend/backend/db, env=prod/stage처럼 의미 있는 라벨로 파드를 그룹화하라. 빈 podSelector는 의도치 않은 범위 확대로 이어지므로 사용을 피한다.
- 네임스페이스 설계: 트러스트 경계를 네임스페이스 단위로 나누고 namespaceSelector를 사용해 최소 권한으로 네임스페이스 간 통신을 허용한다.
- 운영 팁: 먼저 CNI가 NetworkPolicy를 지원하는지 확인하라. 스테이징에서 점진적으로 롤아웃하고 모니터링을 병행한다. kube-system 등 핵심 네임스페이스는 별도 검토해 예외를 관리하라. 실무 체크리스트 예: (1) CNI 지원 여부 확인, (2) 스테이징 적용 후 로그와 연결성 검증, (3) 정책 위반 경보 설정, (4) 핵심 네임스페이스 예외 문서화. 참고로 쿠버네티스 네트워크 정책 운영 시 흔한 실수 및 교정 방법 관점을 반영하면 초기 시행착오를 줄일 수 있다.
너무 넓은 셀렉터나 포트 규칙으로 최소 권한 원칙을 위반하는 실수
광범위한 레이블이나 포트 규칙은 쿠버네티스 네트워크 정책에서 흔히 발생하는 실수입니다. 애매한 podSelector(app: "")나 모든 포트를 허용하는 규칙은 최소 권한 원칙을 무력화해 횡적 이동(lateral movement), 데이터 노출, 권한 남용으로 이어질 수 있습니다. 특히 레이블 네이밍이 일관되지 않으면 의도하지 않은 대상에 정책이 적용되기 쉽습니다.
- 구체적 셀렉터: matchLabels와 matchExpressions로 가능한 한 세밀하게 지정하고 namespaceSelector로 범위를 좁혀야 합니다.
- 포트 명시: 서비스 포트와 프로토콜(TCP/UDP)을 명확히 적시하고 필요하지 않은 포트는 허용하지 마십시오.
- 정책 분해: 하나의 광역 allow 정책을 역할·기능별로 분리해 최소 권한을 보장하세요.
- 검증 자동화: dry-run과 로그·메트릭으로 영향 범위를 확인하고 CI 파이프라인에 정책 검사를 포함해 배포 전 검증을 자동화합니다.
레이블 관리 정책과 템플릿을 도입하면 셀렉터 오용을 근본적으로 줄일 수 있습니다. 실무 체크리스트 예: 레이블 네이밍 규칙 수립, 정책 변경 시 dry-run 수행, 정책 리뷰 주기 설정. 쿠버네티스 네트워크 정책 운영 시 흔한 실수 및 교정 방법을 적용하면 위험을 크게 낮출 수 있습니다.
정책 변경으로 연결이 끊기고 서비스가 중단되는 대표적 운영 실수
정책을 한꺼번에 적용하거나 무차별적으로 'deny-all' 규칙으로 전환하면 기존 세션이 끊기고 서비스 중단으로 이어질 수 있습니다. 아래는 실무 관점에서 정리한 쿠버네티스 네트워크 정책 운영 시 흔한 실수 및 교정 방법입니다.
- 모든 트래픽을 차단하는 실수 — 네임스페이스나 라벨 단위로 범위를 제한해 단계적으로 롤아웃하세요. 한 번에 적용하지 않는 것이 안전합니다.
- 변경을 즉시 전체에 반영하는 실수 — Canary 방식으로 일부 파드에 먼저 적용하고 지표와 로그로 안정성을 확인한 뒤 점진적으로 확대합니다.
- 변경 전 테스트를 생략하는 실수 — --dry-run, 테스트 전용 네임스페이스, 합성 트래픽(헬스체크, TCP/UDP) 등을 사용해 사전 검증하세요.
- 세션 유지와 conntrack 타임아웃을 간과하는 실수 — 그레이스풀 종료, PodDisruptionBudget 설정, kube-proxy/conntrack 타임아웃 조정, 그리고 필요하면 keepalive로 세션을 유지해야 합니다.
- 권장 작업 — 정책 적용 전후로 스모크 테스트(헬스체크, 응답 지연, 연결 유지)를 자동화하고, 롤백 플레이북을 준비하세요. 체크리스트 예: 변경 전 영향 범위 식별 → 백업/롤백 절차 확인 → 스모크 테스트 실행 → 모니터링 경보 설정.
CNI(네트워크 플러그인) 차이를 간과해 정책이 기대만큼 동작하지 않는 문제
같은 NetworkPolicy YAML이라도 CNI마다 구현 범위와 작동 원리가 달라, "정책이 먹히지 않는다"는 사례의 상당수가 CNI 차이에서 비롯됩니다. 예를 들어 Flannel은 기본적으로 NetworkPolicy를 강제하지 않고, Calico는 전역 정책이나 계층(tiers)과 세밀한 매칭을 제공하며, Cilium은 BPF 기반으로 L7까지 제어할 수 있습니다. 반면 iptables 기반 CNI는 구조적 한계가 있어 동일한 정의라도 기대와 다른 동작을 보일 수 있습니다. 쿠버네티스 네트워크 정책 운영 시 흔한 실수 및 교정 방법을 고민할 때 이 점을 먼저 확인하세요.
- 호환성 체크리스트: CNI 종류·버전, 정책 엔진(iptables vs BPF), L3/L4/L7 지원 여부, default‑deny 적용 방식, Selector/Label 매칭의 한계 점검
- 운영 확인: CNI 구성 파일(
/etc/cni/net.d) 확인, 노드 에이전트의 상태와 버전 점검. 실무 팁 — 노드에서 구성 파일을 확인한 뒤 에이전트 로그(또는 상태 명령)를 보고, 버전 불일치가 있으면 우선순위로 해결하세요.
디버깅 우선순위는 명확해야 합니다. 플러그인 로그를 먼저 확인하세요(예: journalctl -u calico-node, cilium status). 벤더 도구로 정책 결정 경로를 추적하면 원인 파악이 빠릅니다(calicoctl, cilium policy trace 등). 실제 패킷 흐름은 파드 간 nc 테스트로 확인하고, 노드나 파드에서 tcpdump로 캡처해 흐름을 검증하세요. 필요하면 iptables-save 등으로 iptables/nft/conntrack 룰을 검토합니다. 이런 단계로 CNI의 제한인지 정책 설정의 문제인지 가려내면 교정이 훨씬 수월합니다.
관찰성·테스트 부족으로 정책 효과를 검증하지 못하는 경우
네트워크 정책을 배포하고도 실제 트래픽에서 차단·허용이 어떻게 이루어지는지 모르면 규칙이 의도대로 동작하는지 확인할 수 없습니다. 운영 검증 루프는 테스트 시나리오, 자동화, 트래픽 캡처·흐름 메트릭, 정책 감사를 조합해 구성해야 합니다. 이 네 가지를 함께 활용하면 예상치 못한 차단이나 허용 누락을 조기에 발견할 수 있습니다. 쿠버네티스 네트워크 정책 운영 시 흔한 실수 및 교정 방법의 핵심도 바로 이런 검증 루프에 있습니다.
- 테스트 시나리오 정의: 서비스 간 정상·비정상 통신 케이스(포트, IP, 네임스페이스, 프로토콜)를 표준화해 케이스 목록을 만듭니다. 간단 체크리스트로는 필수 포트, 예상 허용/거부, 네임스페이스 경계, 비정상 패턴을 포함하세요.
- CI 통합 자동화: PR 머지 시 정책 시뮬레이션과 회귀 테스트를 자동으로 실행해 배포 전에 이상을 잡아냅니다. 네임스페이스 격리나 허용·거부 행위를 시뮬레이션하는 것이 중요합니다.
- 트래픽 캡처·흐름 메트릭: eBPF나 tcpdump, 서비스 메쉬·CNI의 흐름 로그(예: Calico, Cilium), Prometheus 메트릭을 결합해 거부·허용 비율과 이상 패턴을 수집합니다.
- 정책 감사와 알림: 주기적 감사(정책 커버리지, 중복·충돌 검사)를 수행하고 거부 급증 시 즉시 경보를 보내 운영자가 빠르게 대응하도록 합니다.
- 피드백 루프 구성: 감사 결과와 흐름 데이터를 바탕으로 테스트 케이스를 보완하고 CI 규칙을 갱신해 정책 품질을 지속적으로 개선합니다.
경험에서 배운 점
쿠버네티스 네트워크 정책을 운영하면서 가장 흔한 실수는 처음부터 지나치게 허용(allow-all)하거나, 반대로 모든 것을 차단한 뒤 서비스 간 의존성을 충분히 파악하지 않고 정책을 적용하는 것입니다. CNI(예: Calico, Cilium)의 동작 차이, 네임스페이스 경계, hostNetwork 및 호스트 포트 예외 같은 세부를 간과하면 곧바로 서비스 장애로 이어집니다. 특히 DNS, kube-apiserver 통신, 헬스체크와 프로브 트래픽 같은 기본 인프라 흐름을 정책에서 빠뜨리는 사례가 많습니다.
교정은 원칙적으로 '작게 시작해서 확장'해야 합니다. 기본은 deny-by-default로 두고 단계적으로 허용 규칙을 추가하며, 스테이징 환경에서 충분히 검증하세요. 플로우 로그나 포드 간 통신 시각화 같은 관찰 도구로 실제 트래픽 패턴을 먼저 파악한 뒤 라벨·셀렉터 규칙을 일관되게 설계하는 것이 효과적입니다. 정책 변경 시 자동화된 테스트와 모니터링(프로브 실패, 재시작, 연결 거부 로그)을 준비해 즉시 롤백할 수 있는 절차를 마련해 두세요. 이 내용은 쿠버네티스 네트워크 정책 운영 시 흔한 실수 및 교정 방법을 실제 경험에 비추어 정리한 것입니다.
실무 체크리스트:
• 현재 통신 맵(서비스→서비스, DNS, 컨트롤플레인 등)을 문서화하고 의존성 목록을 작성하세요
• 네임스페이스·라벨 전략을 표준화해 정책 범위를 명확히 지정합니다
• 최소 권한 원칙(deny-by-default)을 적용하되 단계적으로 규칙을 추가하고 검증합니다
• DNS·API 서버·메트릭·로그 수집기 등 기본 egress는 명시적으로 허용하세요
• 스테이징에서 트래픽 생성기로 영향 테스트를 진행하고, 모니터링으로 부작용을 감지합니다
• 각 CNI의 특징과 네트워크 정책 구현 차이를 체크리스트에 반영하세요(예: 적용 범위, 지원 정책 종류)
• 정책 변경에 대한 자동화 테스트·리뷰 프로세스와 신속한 롤백 절차를 마련합니다
• 정책 소유자 지정, 문서화, 주기적 감사 루틴을 운영해 규칙 누수와 관리를 방지합니다
• 사례 기록: DNS 접근 차단으로 특정 서비스가 실패했던 사건과 그 복구 절차를 문서화해 재발 방지에 활용하세요
댓글
댓글 쓰기