CiliumNetworkPolicy로 트래픽 격리하기

Cilium을 CNI로 쓰면 Kubernetes 기본 NetworkPolicy 대신 CiliumNetworkPolicy(CNP)를 쓸 수 있다. CNP가 L7까지 제어할 수 있고, 식별자 매칭도 더 유연하다.

왜 기본 NetworkPolicy가 아닌 CiliumNetworkPolicy인가

Kubernetes 기본 NetworkPolicy는 L3/L4만 지원한다. 파드 셀렉터, IP 블록, 포트로만 트래픽을 제어할 수 있다. CiliumNetworkPolicy는 여기에 더해서:

• L7 프로토콜(HTTP method, path, 헤더) 매칭
• fromEntities: world, fromEndpoints 같은 Cilium 특유의 식별자
• FQDN 기반 egress 제어 (DNS 매칭)

이번에 필요했던 건 ingress 포트 제한과 외부/클러스터 내부 구분이었으니, CNP로 충분했다.

구성 예시

프론트엔드와 API 서버의 ingress를 제한하는 정책이다. 프론트엔드는 외부와 클러스터 내부에서 80포트로 접근을 허용하고, API 서버는 80과 8080만 열어둔다.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: front-policy
  namespace: my-app
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/name: front
  ingress:
  - fromEntities:
    - world
    - cluster
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
---
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-policy
  namespace: my-app
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/name: api
  ingress:
  - toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      - port: "8080"
        protocol: TCP

fromEntities: world는 클러스터 외부에서 들어오는 트래픽을 의미한다. cluster는 클러스터 내부 파드를 의미한다. 둘 다 쓰면 외부와 내부 모두에서 접근이 가능하다.

IMPORTANT

CiliumNetworkPolicy를 적용하면 명시하지 않은 트래픽은 기본적으로 차단된다. 정책을 너무 좁게 잡으면 서비스가 안通되니, 적용 전에 어떤 파드가 어디로 통신하는지 먼저 파악해야 한다. Hubble로 흐름을 확인하면 편하다.

Hubble으로 트래픽 확인

Cilium에 포함된 Hubble로 실제 트래픽 흐름을 볼 수 있다. 정책 적용 전에 어떤 파드가 어디로 통신하는지 확인해두면, 차단 후에 “왜 안通되지?” 하는 일을 줄일 수 있다.

# Hubble UI에서 흐름 시각화
hubble observe --verdict DROPPED

DROPPED verdict이 보이면 정책이 트래픽을 차단하고 있다는 뜻이다. 이걸로 의도한 차단인지 아닌지 구분한다.