llm-wiki/raw/official-docs/k8s-network-policy-official.md

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title	source_type	url	archive_url	related_branches	related_projects	tags	created
official-doc / Kubernetes NetworkPolicy — Pod Isolation, Additive Semantics, CNI Prerequisite	official-doc	https://kubernetes.io/docs/concepts/services-networking/network-policies/		feature-keycloak-header-spoofing-defense	keycloak-patterns	official-doc keycloak-patterns security kubernetes network-policy	2026-07-16

Kubernetes NetworkPolicy — Pod Isolation, Additive Semantics, CNI Prerequisite

Layer: raw/ — 외부 자료(공식 문서 / 대기업 기술 블로그)의 원문 발췌·출처 기록. 본 템플릿은 raw/official-docs/ 와 raw/company-tech-blogs/ 두 폴더가 공유. 검증된 요약은 /ingest 후 wiki/concepts/에 source-summary-template 형식으로 별도 작성. 원본은 raw에 영구 보관.

source_type 허용값

frontmatter source_type: 에는 다음 중 하나만 사용:

• official-doc — 공식 레퍼런스 / 표준 / 사양 (예: Spring Boot reference, RFC, AWS docs)
• company-tech-blog — 대기업 엔지니어링 블로그 / 컨퍼런스 발표 글

본 문서는 Kubernetes 공식 concepts 문서이므로 official-doc.

Parent / 활용 branch (필수, 최소 1개+)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-keycloak-header-spoofing-defense	D3 — K8s 환경에서 ForwardAuth backend 를 격리하려면 NetworkPolicy 를 default-deny(pod가 selected 되면 isolated 됨) + ingress-namespace 명시적 allow 두 단계로 작성해야 하며 (policy 는 additive), CNI 가 NetworkPolicy 를 구현하지 않으면 manifest 가 조용히 no-op 된다는 위험의 근거

출처 / Source

• 원본 URL: https://kubernetes.io/docs/concepts/services-networking/network-policies/
• 아카이브 URL: (미확보)
• 저자 / 조직: Kubernetes SIG-Network (Kubernetes 공식 문서)
• 발행일: (공식 문서 페이지에 명시된 발행일 없음 — 지속 갱신되는 concepts 페이지)
• 마지막 확인일: 2026-07-16

왜 저장했는지 / Why archived

feature-keycloak-header-spoofing-defense D3 의 근거였던 raw/official-docs/k8s-network-policy-official 가 실제로는 raw 에 존재하지 않아 UNSUPPORTED_DECISION 상태였음(부모 branch-note Decision Evidence Map 참조). 본 문서로 그 공백을 메워, K8s NetworkPolicy 의 (1) pod 기본 non-isolated → NetworkPolicy 가 selecting 할 때만 isolated 되는 동작, (2) policy 는 additive(union 의미론), (3) CNI 가 NetworkPolicy 를 구현하지 않으면 아무 효과 없음(silent no-op) 을 공식 원문으로 뒷받침한다.

핵심 인용 / Key quotes (verbatim, 3~5문장)

[§Prerequisites] "To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect." (line 7 — 원문 전체 문단은 "Network policies are implemented by the network plugin [하이퍼링크]." 로 시작하며, 인용은 하이퍼링크 구문이 섞인 첫 문장을 제외하고 두 번째 문장부터 발췌. wiki 마크다운 링크 파서 충돌 방지를 위해 하이퍼링크 절만 제외했으며 인용 의미 손실은 없음)

[§The two sorts of pod isolation] "By default, a pod is non-isolated for ingress; all inbound connections are allowed. A pod is isolated for ingress if there is any NetworkPolicy that both selects the pod and has "Ingress" in its policyTypes; we say that such a policy applies to the pod for ingress." (line 15)

[§NetworkPolicies are additive (non-conflicting)] "Network policies do not conflict; they are additive. If any policy or policies apply to a given pod for a given direction, the connections allowed in that direction from that pod is the union of what the applicable policies allow." (line 19)

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
KNP-C1	Pod 는 기본적으로 ingress 에 대해 non-isolated 이며(모든 inbound 허용), 그 pod 를 selecting 하고 policyTypes 에 "Ingress" 를 포함하는 NetworkPolicy 가 하나라도 존재해야 비로소 ingress 에 대해 isolated 된다	[§The two sorts of pod isolation] "By default, a pod is non-isolated for ingress; all inbound connections are allowed. A pod is isolated for ingress if there is any NetworkPolicy that both selects the pod and has "Ingress" in its policyTypes; we say that such a policy applies to the pod for ingress."	official-standard	Kubernetes NetworkPolicy API v1 전반 (모든 CNI 구현체 공통 계약). ForwardAuth backend pod 에 default-deny NetworkPolicy 를 먼저 걸어야(=selecting) 비로소 격리가 시작된다는 D3 의 "왜 default-deny 가 필요한가"의 직접 근거	특정 CNI(Calico/Cilium 등)의 실제 enforcement 정확도나 성능은 증명 안 함. NetworkPolicy 가 실제로 동작하려면 Prerequisites(KNP-C3) 를 별도로 충족해야 함
KNP-C2	NetworkPolicy 는 서로 충돌하지 않고 additive 하다 — 같은 pod·방향에 적용되는 모든 policy 가 허용하는 연결의 union 이 최종 허용 집합이 되며, 평가 순서는 결과에 영향을 주지 않는다	[§NetworkPolicies are additive (non-conflicting)] "Network policies do not conflict; they are additive. If any policy or policies apply to a given pod for a given direction, the connections allowed in that direction from that pod is the union of what the applicable policies allow."	official-standard	default-deny NetworkPolicy 하나 + ingress-namespace-allow NetworkPolicy 하나를 "별도의 두 리소스"로 작성해도 안전하게 합쳐진다는 근거(D3 의 "두 단계로 작성해야" 하는 이유 — 명시적 allow 가 없으면 selecting 만으로 전체 거부 상태가 되고, allow 를 추가하면 그 union 이 최종 허용 집합이 됨)	policy 작성 순서·리소스 개수에 따른 실제 apply 지연이나 propagation latency 는 증명 안 함. non-NetworkPolicy 계층(예: L7 인증) 과의 상호작용은 범위 밖
KNP-C3	network plugin(CNI)이 NetworkPolicy 를 구현하지 않은 클러스터에서 NetworkPolicy 리소스를 생성해도 아무 효과가 없다(no effect) — 이것이 NetworkPolicy 사용의 전제조건이다	[§Prerequisites] "To use network policies, you must be using a networking solution which supports NetworkPolicy. Creating a NetworkPolicy resource without a controller that implements it will have no effect."	official-standard	D3 의 silent-failure 위험(kubectl apply 는 성공하지만 실제 격리가 전혀 일어나지 않는 상태) 의 직접 근거. flannel 기본 설정처럼 NetworkPolicy 를 구현하지 않는 CNI 를 쓰는 클러스터에서 이 문서의 다른 모든 claim(KNP-C1, KNP-C2) 이 무의미해질 수 있음을 뒷받침	어떤 CNI 가 NetworkPolicy 를 구현하는지/안 하는지 목록은 본 인용에 없음(별도 network-plugins 링크 페이지). kubectl get networkpolicy 로 enforcement 여부를 판별할 수 있는지/없는지도 본 인용 범위 밖 — 부모 branch-note 의 "Claims To Verify" 항목으로 남아있는 실측 필요 사항

Strength 허용값

• official-standard — RFC, 표준 사양, 언어/프로토콜 표준
• official-vendor-doc — Spring, Keycloak, AWS, Google 등 공식 벤더 문서
• official-reference — 공식 reference/API 문서
• company-case-study — 대기업/실무 기술 블로그의 특정 사례
• engineering-blog — 개인/팀 블로그의 엔지니어링 해설
• tutorial — 튜토리얼/가이드. 일반화 금지
• needs-confirmation — 원문만으로는 적용 판단 불가

Usage Boundaries / 적용 경계

• 이 자료가 직접 증명하는 것:
  • KNP-C1: pod 는 기본 non-isolated 이며 NetworkPolicy 가 selecting 해야 isolated 시작 — "왜 default-deny 를 먼저 걸어야 하는가"의 근거
  • KNP-C2: NetworkPolicy 는 additive/union 의미론 — "default-deny + 별도 allow policy 를 두 리소스로 나눠 작성해도 안전하게 합쳐진다"는 근거
  • KNP-C3: CNI 가 NetworkPolicy 를 구현하지 않으면 리소스를 만들어도 아무 효과가 없다 — silent no-op 위험의 공식 근거
• 이 자료가 증명하지 않는 것:
  • 특정 CNI(Calico, Cilium, flannel 등)가 NetworkPolicy 를 실제로 구현하는지 여부의 목록 — 별도 network-plugins 페이지 확인 필요
  • kubectl get networkpolicy 만으로 enforcement 여부를 판별할 수 있는가 — 본 페이지는 이에 대해 언급하지 않음
  • egress NetworkPolicy 의 상세 동작(본 문서에 존재하나 이번 발췌에서는 ingress 중심으로 인용 — ForwardAuth backend 보호는 ingress 방향이 핵심)
  • DNS egress 허용(kube-dns/CoreDNS) 을 default-deny 와 함께 작성하는 구체적 예시 — 이 페이지의 발췌 범위 밖(별도 확인 필요)
• 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
  • 학습 프로젝트의 실제 CNI(예: k3s 기본 flannel vs Calico) 가 NetworkPolicy 를 구현하는지 확인 — KNP-C3 에 의해 이것이 확인되지 않으면 D3 전체가 silent no-op
  • default-deny + ingress-namespace-allow 2-리소스 NetworkPolicy YAML 예시를 실제 클러스터에 적용 후 backend pod 직접 curl 시도로 enforce 여부 실측 (부모 branch-note Claims To Verify 항목과 동일)

메모 / Notes

나중에 wiki로 옮길 때 참고할 짧은 메모. 검증되지 않은 내 추론은 여기에 두지 말 것.

• 인용 1 해석 후보 (미검증): "Creating a NetworkPolicy resource without a controller that implements it will have no effect" 는 kubectl apply 자체는 API server 에 정상 저장되고 에러가 나지 않는다는 뜻으로 읽힘 — 즉 리소스 생성 성공 여부로는 enforcement 여부를 구분할 수 없다는 추론. 이 추론은 원문이 직접 말한 것이 아니므로 KNP-C3 의 "Does not prove" 에 남겨둠.
• 추가로 봐야 할 동일 출처 페이지: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/ (어떤 CNI 가 NetworkPolicy 를 지원하는지), egress 예시 및 DNS 허용 패턴을 다루는 NetworkPolicy 레시피 페이지(커뮤니티 저장소는 비공식 — official-doc 으로 인용 불가).

Related / 관련

• 같은 주제 다른 official-doc: raw/official-docs/aws-ec2-security-group-official (검토 후보 — 부모 branch-note TODO 에 명시된 EC2 SG 대안, 아직 raw 미보존 시 별도 dispatch 필요)
• 이 자료를 인용한 wiki 요약: (미생성 — /ingest 이후 wiki/concepts/ 에 생성 시 링크)