정책에는 '거부' 가 없다

한 줄 요약

NetworkPolicy 에는 거부라는 개념이 없습니다. 파드에 정책이 하나도 없으면 전부 허용이고, 하나라도 붙는 순간 그 방향이 허용 목록으로 뒤집힙니다.

왜 이 전환을 알아야 하나

쿠버네티스의 기본값은 전부 허용입니다. 어느 네임스페이스의 어느 파드든 다른 모든 파드에 닿습니다. 침입자가 웹 파드 하나를 잡으면 그 자리에서 데이터베이스가 보입니다.

기본값이 뒤집히는 지점

NetworkPolicy 의 동작 방식이 직관과 다릅니다.

파드에 정책이 하나도 붙지 않으면 전부 허용이고, 하나라도 붙는 순간 그 파드는 그 방향에 대해 허용 목록 방식으로 바뀝니다.

그래서 정책에는 '거부' 라는 개념이 아예 없습니다. default-deny 라는 이름의 정책도 사실은 아무것도 허용하지 않는 정책일 뿐입니다.

spec:  podSelector: {}          # 이 네임스페이스의 모든 파드  policyTypes: [Ingress]   # ingress 만 다룬다  # ingress: 항목이 없다 → 허용하는 것이 하나도 없다

이 전환을 모르면 "정책 하나 추가했을 뿐인데 관계없는 것이 끊겼다" 가 됩니다.

방향을 헷갈리지 않는 법

정책은 언제나 받는 쪽에 붙습니다.

| 필드 | 고르는 것 |
|---|---|
| podSelector | 보호받는 파드 (db) |
| ingress.from | 허용할 출처 (api) |

보내는 쪽에 붙이면 문법은 통과하고 오브젝트도 만들어지는데 아무 일도 일어나지 않습니다. 오류가 없어서 더 헷갈립니다.

여러 정책은 더해진다

같은 파드에 붙은 정책이 여럿이면 합집합입니다. 뒤에 붙인 정책이 앞의 것을 덮어쓰지 않습니다. 그래서 "좁히려고 정책을 추가했는데 더 넓어지는" 일이 생깁니다. 좁히려면 기존 정책을 고쳐야 합니다.

가장 자주 나는 사고

egress 를 기본 차단하는 순간 DNS 가 함께 끊깁니다. CoreDNS 로 나가는 53번 포트도 egress 이기 때문입니다.

증상은 "이름을 못 찾습니다" 이고, CoreDNS 는 멀쩡하며, 다른 네임스페이스는 정상입니다. 그래서 아무도 방금 붙인 네트워크 정책을 의심하지 않습니다.

실무에서 진짜 중요한 것

egress 를 막을 때는 DNS 를 같은 커밋에서 함께 엽니다. CoreDNS 로 나가는 53번도 egress 라 함께 끊기는데, 증상은 "이름을 못 찾습니다" 이고 CoreDNS 는 멀쩡하며 다른 네임스페이스는 정상입니다. 그래서 아무도 방금 붙인 정책을 의심하지 않습니다.

정책은 언제나 받는 쪽에 붙입니다. 보내는 쪽에 붙이면 문법은 통과하고 오브젝트도 만들어지는데 아무 일도 일어나지 않습니다. 오류가 없어서 더 오래 헤맵니다.

좁히려면 정책을 추가하지 말고 기존 정책을 고칩니다. 같은 파드에 붙은 정책은 합집합이라, 뒤에 붙인 것이 앞의 것을 덮어쓰지 않습니다. 좁히려고 추가했는데 더 넓어지는 일이 여기서 나옵니다.

다음 실습에서 이 사고를 직접 일으켰다가 고칩니다. 그리고 고칠 때 UDP 53 만 열면 왜 더 나쁜 상태가 되는지도 함께 봅니다.