Kubernetes NetworkPolicy는 적용 대상 Pod와 ingress·egress 방향별 허용 규칙으로 통신을 제한합니다. 적용되는 정책이 여러 개면 허용 규칙은 합집합으로 누적되며, 한 Pod에서 다른 Pod로 연결하려면 송신측 egress와 수신측 ingress가 모두 허용해야 합니다.
정책 객체가 API에 존재하는 것만으로 실제 패킷이 차단됐다고 증명할 수 없습니다. 클러스터 네트워크 플러그인의 NetworkPolicy 지원, 실제 라벨 선택, hostNetwork 여부와 승인된 연결 관측을 확인해야 합니다.
정책은 방향별로 Pod를 격리하고 허용 집합을 만듭니다
Kubernetes 공식 문서는 NetworkPolicy가 선택된 Pod의 ingress, egress 또는 양쪽을 격리할 수 있다고 설명합니다. 특정 방향을 격리하기 시작하면 그 방향은 적용 가능한 정책에서 허용한 트래픽만 통과합니다. 반대로 그 방향에 정책이 적용되지 않는 Pod의 기본 상태는 격리되지 않은 것으로 봅니다. 따라서 ‘정책이 하나 있다’는 말 대신, 어떤 정책이 어떤 Pod의 어느 방향을 선택하는지부터 계산합니다.
정책들은 서로 우선순위를 두고 덮어쓰지 않습니다. 선택된 Pod와 방향에 적용되는 모든 정책의 허용 규칙이 더해집니다. 또한 연결은 양방향 점검입니다. 송신 Pod가 egress 격리돼 있으면 송신 egress 규칙이 허용해야 하고, 수신 Pod가 ingress 격리돼 있으면 수신 ingress 규칙도 허용해야 합니다. 한쪽이 막히면 연결은 허용되지 않습니다.
두 네임스페이스와 세 Pod의 라벨을 확인합니다
| Pod | namespace | labels | 정책이 선택하는 방향 |
|---|---|---|---|
| frontend | shop | app=web | 이 예시에서는 ingress·egress 미격리 |
| api | shop | app=api | 정책 P1 ingress 격리, P2 egress 격리 |
| db | data | app=db | 정책 P3 ingress 격리 |
P1은 shop 네임스페이스의 app=api Pod를 선택하고, ingress에서 shop의 app=web Pod가 TCP 8443으로 보내는 연결을 허용합니다. P2는 같은 api Pod의 egress를 격리하고 data의 app=db로 향하는 TCP 5432만 허용합니다. P3는 db Pod의 ingress를 격리하고 shop의 app=api에서 오는 TCP 5432를 허용합니다. namespace와 Pod selector가 한 peer 항목 안에 함께 있으면 둘 다 같은 상대 Pod를 만족해야 합니다.
송신 egress와 수신 ingress를 함께 계산합니다
| 연결 시도 | 송신 egress | 수신 ingress | 결과 |
|---|---|---|---|
| frontend → api TCP 8443 | frontend 미격리라 허용 | P1이 app=web에서 허용 | 허용 |
| api → db TCP 5432 | P2가 db:5432 허용 | P3가 api:5432 허용 | 양쪽 조건 충족 |
| frontend → db TCP 5432 | frontend 미격리라 허용 | P3는 api만 허용 | db ingress에서 차단 |
| api → 임의 외부 목적지 | P2는 db:5432만 허용 | 수신측 조건과 무관 | api egress에서 차단 |
표에서 frontend가 db로 바로 연결할 수 없는 이유는 송신 egress가 막혀서가 아니라 db의 ingress 허용 주체가 api로 좁혀졌기 때문입니다. 반면 api에서 외부로 나가는 연결은 api의 egress 격리 규칙에 db만 허용되어 차단됩니다. 만약 다른 NetworkPolicy가 api의 egress에 더 넓은 허용 규칙을 추가한다면 두 정책의 허용 집합이 합쳐져 결과가 달라질 수 있습니다. ‘차단 정책을 추가했으니 우선 적용될 것’이라고 생각하면 안 됩니다.
통신이 계속될 때 점검하는 순서
- 문제가 된 송신·수신 Pod의 현재 namespace와 실제 labels를 읽고 selector가 일치하는지 표로 대조합니다.
- 각 Pod에 ingress·egress isolation이 시작되는지, 해당 방향에 적용되는 정책이 무엇인지 목록으로 만듭니다.
- 적용 가능한 모든 allow 규칙을 합산합니다. 정책 순서나 하나의 deny가 다른 정책의 허용을 취소한다고 가정하지 않습니다.
- 연결 방향과 포트·protocol을 맞춰 송신 egress와 수신 ingress를 각각 판정합니다.
- 사용 중인 CNI가 NetworkPolicy를 구현하는지, 정책 처리·전파가 완료됐는지 확인합니다. API에는 처리 시점을 알리는 필드가 없을 수 있습니다.
- hostNetwork Pod나 서비스 변환, 노드·외부 경로는 별도 구현 경계로 분류하고 허가된 테스트에서만 실제 패킷 결과를 확인합니다.
정책 YAML만으로 집행 결과를 보장하지 않습니다
Kubernetes 문서는 NetworkPolicy를 집행하는 네트워크 플러그인이 필요하다고 명시합니다. 플러그인이 지원하지 않으면 API 객체만으로 효과가 생기지 않을 수 있고, 새 정책이 실제 처리되기 전에는 일시적인 연결 차이가 나타날 수도 있습니다. hostNetwork Pod의 동작도 네트워크 플러그인이 이를 구별할 수 있는지에 따라 다릅니다. 따라서 구성 판독 결과와 실제 네트워크 관측 결과를 구분해 보고합니다.
복습: api에서 db로 가려면?
문제: api egress 정책은 data/db TCP 5432를 허용하지만 db ingress 정책은 shop/app=web만 허용합니다. api → db 연결이 통과할까요?
정답: 통과하지 않습니다. api의 egress는 허용하지만 db의 ingress에서 api 라벨을 허용하지 않습니다. 두 방향 조건을 모두 확인해야 합니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
창작 정책에서 api egress는 db TCP 5432를 허용하고 db ingress도 api에서 오는 TCP 5432를 허용합니다. 그런데 frontend가 db에 직접 연결하려고 합니다. frontend egress에는 정책이 없고 db ingress는 api만 허용합니다. 결과와 확인할 구현 조건을 말하세요.
정답과 해설 확인
frontend의 송신 egress는 격리되지 않아도 db ingress가 frontend를 허용하지 않으므로 연결은 허용되지 않습니다. NetworkPolicy를 실제 집행하는 CNI가 있는지와 실제 Pod 라벨이 맞는지 확인합니다.정책은 대상 Pod와 방향별로 적용되며, 연결에서는 송신측 egress와 수신측 ingress의 두 허용이 모두 필요합니다. API 정책 객체만으로 집행 여부를 알 수 없습니다.