로그 규칙으로 네트워크 정책 테스트하기
Calico Open Source 정책 규칙에 Log 액션을 추가해 런타임에 어떤 규칙이 트래픽과 일치하는지 디버깅하는 방법을 안내해요.
출처: 문서
본문
Use log rules to test network policy
정책에 일치하는 모든 네트워크 트래픽을 기록하는 네트워크 정책을 만들 수 있어요. 로그 규칙을 사용하면 클러스터의 모든 트래픽을 모니터링하고, 새 정책을 강제하기 전에 테스트하고, 기대대로 동작하지 않는 정책을 문제 해결할 수 있어요.
로그 규칙이란
Log 액션이 있는 Calico 네트워크 정책은 정책에 지정된 규칙과 기준에 따라 네트워크 트래픽 정보를 수집하는 진단 도구 역할을 해요. 덕분에 클러스터 관리자는 정책이 트래픽을 어떻게 평가하는지 볼 수 있어요. 로그는 트래픽이 어디서 왔는지, 어디로 가는지, 그 트래픽이 정책에 의해 허용됐는지 거부됐는지 알려줘요.
로그 규칙은 주로 다음 상황에서 사용해요:
- 클러스터의 모든 트래픽을 수집하기. 기본 거부(default deny) 정책을 설정하기 전에 클러스터에 현재 어떤 트래픽이 있는지 볼 수 있어요. 이는 예상 트래픽에 대한 명시적 허용 규칙을 만들 때 도움이 돼요.
- 새 네트워크 정책 테스트하기. 새 정책을 강제하기 전에 그 정책이 실제 트래픽을 기록하도록 설정해 기대대로 동작하는지 확인할 수 있어요.
- 기존 정책 문제 해결하기. 기대대로 동작하지 않는 것이 있다면 로그 규칙을 사용해 기존 네트워크 정책을 디버깅할 수 있어요.
Log 액션을 효과적으로 활용하려면 정책 tier의 가장 아래에 배치해 우선순위가 낮은 정책들에 명시적으로 매칭되지 않은 트래픽을 수집하세요. 이 접근은 처리되지 않은 트래픽을 찾아내고 정책 구성의 빈틈을 드러내줘요. 기록된 트래픽을 분석하면 출발지, 목적지, 프로토콜 같은 특성을 파악할 수 있고, 이를 바탕으로 특정 트래픽 패턴에 대응하는 정책을 만들 수 있어요. 구현한 후에는 해당 트래픽이 더 이상 로그에 나타나지 않는지 확인해 새 정책이 잘 처리하고 있다는 것을 검증하고, 클러스터에 큰 오버헤드를 줄 수 있으므로 Log 정책/규칙은 제거하세요.
Log 액션을 최대한 활용하려면 다음 지침을 따르세요:
- 순서가 중요해요: 로그 액션에 높은
order값을 부여해 우선순위가 낮은 모든 정책 이후에 평가되도록 하세요. - 명시적 허용 규칙: 로그 액션 바로 뒤에 항상 명시적인
Allow규칙을 짝지으세요. 그렇지 않으면 tier의 암묵적 기본 액션 때문에 트래픽이 거부될 수 있어요. - 포괄적 보호: 파드와 워크로드에 더해 호스트를 보호하는
hostEndpoint를 활성화해 namespaced 리소스와 non-namespaced 리소스를 모두 커버하세요.
로그 액션을 정책 tier의 아래쪽에 전략적으로 배치하면 처리되지 않은 트래픽을 수집하고 정책 구성의 빈틈을 식별할 수 있어요. 기록된 트래픽을 분석해 출발지, 목적지, 프로토콜에 대한 통찰을 얻고, 이 데이터로 목적에 맞는 정책을 만드세요. 구현 후에는 해당 트래픽이 더 이상 기록되지 않는지 확인해 새 정책이 효과적이라는 것을 검증하세요.
로그 출력 이해하기
Calico의 로그 출력은 사용 중인 데이터 플레인에 따라 달라져요.
iptables 로그 출력
iptables 같은 백엔드로 클러스터 보안을 구현하는 표준 Linux 데이터 플레인에서는 Log 액션이 평가되는 첫 지점, 즉 트래픽 허용·거부 같은 후속 액션이 적용되기 전에 트래픽을 기록해요. 이를 통해 특정 규칙이나 정책에 매칭되는 트래픽을 세밀하게 볼 수 있어요.
로그는 시스템에 따라 다른 위치에서 찾을 수 있어요. Calico 정책 로그는 보통 다음 방법으로 찾을 수 있어요:
journalctl유틸리티 사용./var/log/syslog검색./var/log/kern.log검색.
iptables 로그 예시:
2024-11-19T12:15:03.023805-08:00 c1-control kernel: calico-packet: IN=cali527b0801ecb OUT=eth0 MAC=ee:ee:ee:ee:ee:ee:1e:0a:36:33:f5:09:08:00 SRC=172.16.193.134 DST=69.147.80.15 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=58406 DF PROTO=TCP SPT=45588 DPT=80 WINDOW=64860 RES=0x00 SYN URGP=0
2024-11-19T12:15:28.648818-08:00 c1-control kernel: calico-packet: IN=cali527b0801ecb OUT=eth0 MAC=ee:ee:ee:ee:ee:ee:1e:0a:36:33:f5:09:08:00 SRC=172.16.193.134 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=48210 DF PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=1
2024-11-19T12:15:02.990083-08:00 c1-control kernel: calico-packet: IN=cali527b0801ecb OUT=calid3446e883f0 MAC=ee:ee:ee:ee:ee:ee:1e:0a:36:33:f5:09:08:00 SRC=172.16.193.134 DST=172.16.193.133 LEN=96 TOS=0x00 PREC=0x00 TTL=63 ID=19241 DF PROTO=UDP SPT=42896 DPT=53 LEN=76
eBPF 로그 출력
BPF 데이터 플레인은 패킷이 로그 규칙에 매칭되면 최종 판정(verdict)을 기록해요. 즉 로그 항목은 적용 가능한 규칙과 정책 전체를 평가한 뒤의 최종 결정(트래픽 허용 여부)을 반영해요.
eBPF 정책 로그는 trace pipe로 전송되며 다음 명령으로 볼 수 있어요:
kubectl exec -n calico-system -it ds/calico-node -- bpftool prog tracelog
eBPF trace 로그의 정확한 형식은 커널과 sysctl 설정에 따라 달라요. 하지만 일반적인 로그 형식에는 활성 프로세스 정보, 타임스탬프, 그리고 IP 헤더가 포함돼요.
eBPF 로그 예시:
curl-5288 [000] ..s2. 3055.982021: bpf_trace_printk: cali527b0801ecb-E: policy ALLOWED proto 6 src 172.16.193.131:56042 dest 69.147.80.12:80
<...>-4950 [001] ..s2. 2960.748464: bpf_trace_printk: cali527b0801ecb-E: policy ALLOWED proto 1 src 172.16.193.131:0 dest 8.8.8.8:8
<...>-5288 [000] ..s2. 3055.954466: bpf_trace_printk: cali527b0801ecb-E: policy ALLOWED proto 17 src 172.16.193.131:36325 dest 10.43.0.10:53
Calico eBPF 로그는 정보를 출력하기 위해 커스텀 형식을 사용해요. 형식은 다음과 같이 구성돼요:
- 프로세스 이름과 ID. 프로세스 이름이 트래픽을 담당하는 프로세스와 직접 대응하지 않을 수 있다는 점에 유의하세요.
- CPU 번호, 커널 플래그, 타임스탬프, 이 메시지를 기록한 BPF print 함수.
- 인터페이스 이름.
- 트래픽 유형. 이 예시에서는 egress예요 (
E= egress,X= XDP,I= ingress). - 정책 판정 (
ALLOWED,DENIED). - IP 프로토콜 번호. 이 예시에서 6은 TCP예요 (1은 ICMP, 17은 UDP).
- 출발지 IP와 출발지 포트.
- 목적지 IP와 목적지 포트.
사전 요구 사항
- 클러스터가 Kind 같은 컨테이너화된 Kubernetes 환경이 아니어야 해요.
- eBPF 데이터 플레인으로 Calico를 실행한다면 클러스터 노드 또는 VM 호스트가 Linux 커널 5.16 이상 기반 Linux 배포판에서 실행되고 있어야 해요.
클러스터의 모든 트래픽 기록하기
로그 규칙은 클러스터의 현재 트래픽을 보여줌으로써 네트워크 정책을 작성하는 데 도움을 줘요. 어떤 트래픽을 허용할지 알게 되면 그 트래픽을 허용하고 다른 모든 트래픽을 제한하는 정책을 작성할 수 있어요.
-
클러스터 전체의 모든 트래픽을 기록하려면 ingress와 egress에 로그 액션을 넣은
GlobalNetworkPolicy리소스를 만들어요:apiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: <log-everything-in-cluster> spec: order: 100000 tier: default types: - Ingress - Egress egress: - action: Log ingress: - action: Log
네임스페이스 트래픽 기록하기
네임스페이스 내 트래픽을 모니터링하거나 문제 해결하려면 NetworkPolicy 리소스를 사용해요. 기존 정책이 처리하지 않는 트래픽을 수집할 수 있도록 가장 높은 우선순위로 정책을 적용해요. 이를 통해 해당 네임스페이스에서 처리되지 않는 트래픽 패턴을 파악할 수 있어요.
-
특정 네임스페이스 내 모든 트래픽을 기록하려면 다음과 같은 NetworkPolicy를 만들어요:
apiVersion: projectcalico.org/v3 kind: NetworkPolicy metadata: name: log-everything-in-ns namespace: <namespace> spec: order: 100001 tier: default types: - Ingress - Egress egress: - action: Log ingress: - action: Log
non-namespaced 리소스, 호스트, VM 트래픽 기록하기
기본적으로 Calico 정책은 namespaced 리소스(예: 파드, ServiceAccounts)에만 적용돼요. non-namespaced 리소스, 호스트, VM에 로그 규칙을 사용하려면 이를 위한 호스트 엔드포인트를 만들면 돼요.
-
클러스터의 모든 트래픽을 기록하는
GlobalNetworkPolicy리소스를 만들어요. -
다음 명령을 실행해 호스트 엔드포인트를 자동 생성하도록 Calico를 구성해요:
kubectl patch kubecontrollersconfiguration default --type=merge --patch='{"spec": {"controllers": {"node": {"hostEndpoint": {"autoCreate": "Enabled"}}}}}'호스트 엔드포인트가 만들어지면 모든 트래픽이 기록돼요.
-
테스트를 마쳤다면 로그 정책을 제거해요. 그대로 두면 클러스터 성능에 큰 영향을 줄 수 있어요.
추가 리소스
완전하고 효율적인 관측성 솔루션을 위해서는 Calico Enterprise와 Calico Cloud에서 제공되는 Flow Logs 사용을 검토해 보세요.
매치 기준과 정책 액션에 대한 자세한 내용은 다음을 참고하세요:
더 알아보기 (Learn more)
Log 액션은 정책을 강제하기 전에 실제 트래픽을 관찰할 수 있는 안전한 리허설 도구예요. iptables 데이터 플레인은 첫 매칭 시점을, eBPF는 최종 판정을 기록한다는 차이도 기억해 두세요. 테스트 후에는 반드시 로그 정책을 제거해 오버헤드를 없애세요.