写了策略，和策略被遵守，是两回事

한 줄 요약

kubectl apply 가 성공했다는 것은 정책이 저장됐다는 뜻일 뿐입니다. 데이터플레인이 없으면 아무것도 막히지 않습니다.

왜 진짜 Cilium 이어야 하나

앞 모듈들에서 CiliumNetworkPolicy 를 여러 개 썼습니다. 그런데 그 실습들이 도는 곳은 CRD 만 적재된 클러스터라서, kubectl apply 가 성공했다는 것 외에는 아무것도 확인되지 않았습니다.

이 모듈에서는 VM 안에 진짜 Cilium 을 세우고 같은 정책을 다시 씁니다. 그러면 세 가지가 새로 보입니다.

1. 아이덴티티는 실제 번호다

kubectl get ciliumendpoint에서 아이덴티티 번호와 보안 관련 라벨 집합을 함께 확인합니다. app 라벨 하나가 같아도 namespace 등 다른 보안 라벨이 다르면 신원도 다를 수 있습니다. 같은 보안 라벨 집합의 엔드포인트는 신원을 공유합니다. 정책에는 변하는 파드 IP나 영구성을 보장하지 않는 숫자 ID를 직접 고정하기보다 허용하려는 라벨의 의미를 담습니다.

기본 Kubernetes NetworkPolicy도 파드·네임스페이스 선택자를 지원합니다. Cilium만 라벨 정책을 제공하는 것이 아니라, API가 표현한 의도를 어떤 데이터플레인으로 강제하고 FQDN·L7 같은 범위를 어떻게 확장하는지가 비교할 지점입니다.

2. L7 거부는 403 이다

Cilium 이 HTTP 를 보려면 패킷을 Envoy 로 넘겨야 합니다. 그래서 L7 에서 막힐 때는 연결이 끊기는 것이 아니라 403 이 돌아옵니다.

이것이 L3 차단보다 낫습니다. 타임아웃은 "네트워크가 이상한가, 서버가 죽었나, 방화벽인가" 를 구분할 수 없지만 403 은 명확한 거부입니다. 클라이언트가 재시도할지 말지를 바로 판단할 수 있고 로그에도 원인이 남습니다.

3. Hubble 은 "왜" 를 알려 준다

hubble observe --type policy-verdict 는 각 흐름이 어느 방향에서 어떤 판정을 받았는지 보여 줍니다. 이것이 없으면 정책 스무 개를 하나씩 지워 가며 범인을 찾게 됩니다.

정책이 안 먹을 때 보는 순서

정책을 썼는데 막히지 않거나, 막히면 안 되는 것이 막힐 때가 있습니다. 순서대로 봅니다.

1. 정책이 그 파드를 고르고 있는가.

kubectl get cep -n <ns> <pod> -o jsonpath='{.status.identity.labels}'
kubectl describe cnp <정책> | sed -n '/Endpoint Selector/,/Ingress/p'

셀렉터의 라벨과 엔드포인트의 라벨이 문자 하나까지 같아야 합니다. app: api 와 app: api 는 다릅니다.

2. 방향을 맞게 걸었는가. 통신 하나에는 나가는 쪽과 들어오는 쪽 정책이 둘 다 있습니다. 출발지에 egress 를, 도착지에 ingress 를 모두 허용해야 통합니다. 한쪽만 열고 "정책을 썼는데 안 된다" 로 헤매는 일이 가장 흔합니다.

3. 기본 차단이 켜졌는가. Cilium 은 그 엔드포인트를 고르는 정책이 하나라도 생기는 순간 그 방향의 기본이 차단으로 바뀝니다. ingress 규칙만 쓴 정책을 붙이면 egress 는 그대로 열려 있지만, egress 규칙을 하나 쓰는 순간 나머지 egress 가 전부 막힙니다. DNS(포트 53)를 빠뜨려 이름 조회부터 죽는 것이 대표적입니다.

egress:
  - toEndpoints:
      - matchLabels:
          k8s:io.kubernetes.pod.namespace: kube-system
          k8s:k8s-app: kube-dns
    toPorts:
      - ports: [{port: "53", protocol: UDP}]
        rules:
          dns: [{matchPattern: "*"}]

4. Hubble 로 판정을 본다.

hubble observe --type policy-verdict --verdict DROPPED --last 20

DROPPED 줄에 어느 정책이 어느 방향에서 막았는지 나옵니다. 여기까지 오면 대개 1~3 중 하나로 되돌아갑니다.

L7 정책의 대가

L7 규칙(rules.http)을 붙이면 그 트래픽은 Envoy 를 거칩니다. 얻는 것과 잃는 것이 분명합니다.

	L3/L4 정책	L7 정책
처리 위치	eBPF (커널)	Envoy (사용자 공간)
지연 추가	거의 없음	수백 µs~수 ms
거부 방식	패킷 드롭(타임아웃)	403 응답
볼 수 있는 것	IP·포트	메서드·경로·헤더

그래서 모든 통신에 L7 을 걸지 않습니다. 외부에서 들어오는 경계나 민감한 서비스 앞에만 두고, 내부 서비스 사이는 L3/L4 로 둡니다.

실무에서 진짜 중요한 것

정책은 IP 가 아니라 아이덴티티로 판단합니다. 그래서 파드를 재시작해 IP 가 바뀌어도 정책이 흔들리지 않고, 규칙 수가 파드 수가 아니라 아이덴티티 수를 따릅니다. 라벨 설계가 곧 정책 규모 설계입니다.

L7 거부가 403 으로 오는 것은 운영에서 큰 이득입니다. 타임아웃은 네트워크·서버·방화벽을 구분해 주지 못하지만 403 은 명확한 거부라, 클라이언트가 재시도할지 말지를 바로 판단할 수 있고 로그에도 원인이 남습니다.

막혔을 때 정책을 하나씩 지우지 말고 Hubble 에 물어봅니다. hubble observe --type policy-verdict 가 어느 방향에서 어떤 판정이 났는지 알려 줍니다. 이것이 없으면 스무 개짜리 정책 묶음에서 범인을 이진 탐색하게 됩니다.

다음 실습에서 이 셋을 직접 확인합니다.