이제 나도 클라우드 네이티브 전문가: 쿠버네티스 구축부터 운영 완전 정복

앞서 우리는 쿠버네티스 클러스터의 기본 네트워크 모델이 모든 파드 간 통신을 허용하며, 이것이 보안상 취약점이 될 수 있어 네트워크 폴리시(Network Policy)를 통해 파드 간 통신을 세밀하게 제어해야 한다고 배웠습니다. 그렇다면 우리가 YAML 파일로 정의한 이 네트워크 폴리시 규칙들은 과연 어떻게 실제 네트워크 트래픽에 적용되어 특정 통신을 허용하거나 차단하는 걸까요? 네트워크 폴리시 리소스 자체는 단지 ‘원하는 통신 제어 상태’를 선언한 명세일 뿐, 그 자체로 방화벽처럼 동작하지는 않습니다.

네트워크 폴리시가 실제로 동작하기 위해서는 쿠버네티스 클러스터에 설치된 CNI(Container Network Interface) 플러그인이 네트워크 폴리시 기능을 지원하고, 이를 해석하여 실제 네트워크 트래픽 필터링 규칙(예: iptables 규칙, eBPF 프로그램 등)으로 변환하여 적용하는 과정이 반드시 필요합니다. 즉, 네트워크 폴리시는 쿠버네티스 API 레벨에서의 ‘선언’이고, 이 선언을 실제 ‘행동’으로 옮기는 것은 바로 CNI 플러그인의 역할입니다. 마치 우리가 법률(네트워크 폴리시)을 만들어도, 그 법을 집행하는 경찰(CNI 플러그인)이 있어야 실제 효력이 발생하는 것과 같습니다.

이번 절에서는 네트워크 폴리시가 어떤 원리로 동작하며, 왜 네트워크 폴리시를 지원하는 CNI 플러그인이 필수적인지, 그리고 우리가 흔히 사용하는 K3s나 Rancher Desktop과 같은 환경에서는 이 부분을 어떻게 확인해야 하는지 자세히 살펴보겠습니다.

네트워크 폴리시의 동작 원리를 이해하기 위한 가장 중요한 전제 조건은, 모든 CNI 플러그인이 네트워크 폴리시 기능을 기본적으로 지원하는 것은 아니다라는 점입니다. CNI 명세 자체는 파드 네트워킹의 기본적인 부분(IP 할당, 인터페이스 생성 등)만을 표준화하고 있으며, 네트워크 폴리시와 같은 고급 네트워킹 기능은 각 CNI 플러그인이 선택적으로 구현하여 제공합니다.

따라서, 우리가 쿠버네티스 클러스터에 네트워크 폴리시 리소스를 생성하더라도, 만약 현재 클러스터에 설치된 CNI 플러그인이 네트워크 폴리시를 지원하지 않는다면, 해당 네트워크 폴리시 규칙은 아무런 효과 없이 무시됩니다. 즉, 파드 간 통신은 여전히 기본 정책(모든 통신 허용)을 따르게 됩니다. 이는 마치 방화벽 설정을 위한 소프트웨어는 설치했지만, 실제로 방화벽 엔진 자체가 없거나 비활성화되어 있는 것과 같습니다.

네트워크 폴리시 기능을 지원하는 대표적인 CNI 플러그인들은 다음과 같습니다.

• Calico (칼리코): 앞서 CNI 플러그인 종류에서 설명했듯이, Calico는 강력한 네트워크 폴리시 기능을 핵심 기능으로 제공합니다. iptables 또는 eBPF를 사용하여 매우 유연하고 성능 좋은 방식으로 네트워크 폴리시 규칙을 적용하며, L3/L4 레벨뿐만 아니라 일부 L7 정보(eBPF 사용 시)를 기반으로 한 정책 설정도 지원합니다. Calico는 네트워크 폴리시 구현에 있어 가장 널리 알려지고 많이 사용되는 CNI 플러그인 중 하나입니다.
• Cilium (실리움): eBPF 기술을 적극적으로 활용하는 Cilium 역시 매우 강력하고 현대적인 네트워크 폴리시 기능을 제공합니다. eBPF를 통해 커널 수준에서 효율적으로 트래픽을 필터링하고 정책을 적용하므로, 기존 iptables 기반 방식보다 성능이 우수하고 더 세밀한 제어(예: API 호출 레벨의 정책)가 가능합니다.
• Weave Net (위브넷): Weave Net도 자체적인 네트워크 폴리시 구현을 제공합니다. iptables를 사용하여 기본적인 Ingress/Egress 규칙을 지원합니다.
• Antrea (안트레아): VMware에서 주도하는 CNI 플러그인으로, Open vSwitch(OVS)를 기반으로 하며 네트워크 폴리시 기능을 지원합니다.

반면, Flannel (플란넬)과 같이 단순성과 경량성에 초점을 맞춘 일부 CNI 플러그인들은 자체적으로 네트워크 폴리시 기능을 제공하지 않습니다. Flannel은 주로 L2/L3 오버레이 네트워크를 통한 파드 간 통신 연결성에만 집중합니다. 따라서 만약 클러스터에 Flannel만 CNI 플러그인으로 설치되어 있다면, 네트워크 폴리시 리소스를 생성해도 아무런 통신 제어 효과를 볼 수 없습니다.

• Flannel: 단순하고 가볍지만 네트워크 폴리시는 미지원. Rancher Desktop의 기본 CNI로 자주 사용됨.
• Calico: 가장 널리 쓰이는 CNI. 정책 기능과 운영 안정성, 퍼포먼스 모두 우수. 정책이 중요한 환경에 적합.
• Cilium: eBPF 기반으로 L7 정책, 성능, 보안에서 매우 강력. 복잡한 정책과 고성능 환경에 적합.
• Weave Net: 단순한 클러스터에 유용하며 암호화 지원. 정책은 미지원.
• Antrea: VMware 주도 개발, OVS 기반으로 기업 환경에서 인기. Traceflow, UI 시각화 등 강력한 운영 기능이 장점.

그렇다면 우리가 로컬 개발이나 테스트 목적으로 자주 사용하는 K3s나 Rancher Desktop 환경에서는 네트워크 폴리시를 사용할 수 있을까요? 이는 해당 배포판이 기본적으로 어떤 CNI 플러그인을 사용하고, 그 CNI 플러그인이 네트워크 폴리시를 지원하는지에 따라 달라집니다.

• K3s (케이쓰리에스):
  • 앞서 언급했듯이, K3s는 기본적으로 Flannel CNI 플러그인을 내장하여 사용합니다. 따라서 K3s를 기본 설정으로 설치한 경우, 네트워크 폴리시 리소스를 생성하더라도 실제 통신 제어는 이루어지지 않습니다.
  • 하지만 K3s는 매우 유연하여, 사용자가 원한다면 기본 Flannel 대신 Calico와 같은 네트워크 폴리시 지원 CNI를 사용하도록 설치 시 옵션을 지정하거나, 설치 후에 변경할 수 있습니다. 예를 들어, K3s 서버 설치 시 –flannel-backend=none 옵션과 함께 Calico를 직접 설치하는 매니페스트를 적용하는 방식으로 Calico CNI를 사용할 수 있습니다. 이렇게 Calico가 CNI로 동작하도록 설정된 K3s 클러스터에서는 네트워크 폴리시가 정상적으로 작동합니다.
  • 또한, K3s의 일부 최신 버전이나 특정 설정에서는 Flannel과 함께 Canal (Flannel의 네트워킹과 Calico의 폴리시 엔진을 결합한 프로젝트)과 유사한 방식으로 네트워크 폴리시 기능을 부분적으로 지원하려는 시도나 옵션이 있을 수도 있으므로, 사용하는 K3s 버전에 대한 공식 문서를 확인하는 것이 중요합니다.
• Rancher Desktop (랜처 데스크탑):
  • Rancher Desktop이 내부적으로 k3s 엔진을 사용하고, 이 k3s 엔진이 기본 Flannel CNI를 사용한다면, 위 K3s의 경우와 마찬가지로 네트워크 폴리시는 기본적으로 동작하지 않을 가능성이 높습니다.
  • Rancher Desktop의 설정 옵션에서 CNI 플러그인을 변경하거나 네트워크 폴리시를 지원하는 다른 쿠버네티스 배포 옵션(예: Calico를 포함한 배포)을 선택할 수 있는지 확인해 보아야 합니다. Rancher Desktop은 사용자 편의성을 중시하므로, 향후 버전에서는 네트워크 폴리시 지원이 더 강화되거나 쉽게 활성화할 수 있는 옵션이 제공될 수도 있습니다.
  • 만약 Rancher Desktop이 내부적으로 moby/dockerd 엔진을 사용하고, Docker Desktop과 유사한 네트워킹 스택을 따른다면, 해당 스택이 네트워크 폴리시를 지원하는지 여부를 확인해야 합니다. (Docker Desktop 자체는 특정 버전부터 Calico를 통한 네트워크 폴리시를 지원하기도 했습니다.

네트워크 폴리시를 지원하는 CNI 플러그인(예: Calico)이 설치되어 있다고 가정했을 때, 네트워크 폴리시의 일반적인 동작 원리는 다음과 같습니다.

1. 네트워크 폴리시 리소스 생성: 사용자는 YAML 파일을 통해 특정 파드 그룹에 대한 Ingress(수신) 또는 Egress(송신) 규칙을 정의하는 네트워크 폴리시 리소스를 쿠버네티스 API 서버에 생성합니다.
2. CNI 컨트롤러의 감시: CNI 플러그인에 포함된 컨트롤러(또는 에이전트)는 API 서버를 통해 네트워크 폴리시 리소스의 변경 사항과 영향을 받는 파드들의 정보(레이블, IP 주소 등)를 지속적으로 감시합니다.
3. 규칙 변환 및 적용: 새로운 네트워크 폴리시가 감지되거나 기존 폴리시가 변경되면, CNI 컨트롤러는 이 폴리시 규칙들을 해석하여 각 노드에서 실제 네트워크 트래픽을 필터링할 수 있는 저수준의 규칙으로 변환합니다.
   • iptables 기반: 많은 CNI 플러그인(예: Calico의 초기 버전, Weave Net)은 리눅스 커널의 iptables 방화벽 규칙을 사용하여 네트워크 폴리시를 구현합니다. 즉, 폴리시 규칙에 따라 특정 IP 주소나 포트로의 연결을 허용(ACCEPT)하거나 차단(DROP)하는 iptables 체인과 규칙들을 각 노드에 동적으로 생성하고 관리합니다.
   • eBPF 기반: 최신 CNI 플러그인(예: Cilium, Calico의 eBPF 모드)은 eBPF(extended Berkeley Packet Filter) 기술을 사용하여 네트워크 폴리시를 구현합니다. eBPF는 커널 코드 수정 없이도 커널 수준에서 네트워크 패킷을 직접 프로그래밍 방식으로 처리하고 필터링할 수 있게 해주므로, iptables보다 훨씬 더 높은 성능과 유연성, 그리고 세밀한 제어(예: L7 정책)를 제공할 수 있습니다. CNI 컨트롤러는 eBPF 프로그램을 각 노드의 네트워크 인터페이스나 특정 훅(hook) 지점에 로드하여 트래픽을 검사하고 정책을 적용합니다.
4. 트래픽 필터링: 이제 파드 간 또는 파드와 외부 간의 네트워크 트래픽이 발생하면, 각 노드에 적용된 iptables 규칙 또는 eBPF 프로그램이 해당 트래픽을 검사하여, 정의된 네트워크 폴리시 규칙에 따라 허용되거나 차단됩니다.

결론적으로, 네트워크 폴리시는 쿠버네티스 API 레벨에서 선언된 ‘의도’이며, 이 의도를 실제 네트워크 트래픽 제어라는 ‘행동’으로 옮기는 것은 네트워크 폴리시 기능을 지원하는 CNI 플러그인의 핵심적인 책임입니다. 따라서 네트워크 폴리시를 사용하고자 한다면, 가장 먼저 자신의 클러스터에 설치된 CNI 플러그인이 해당 기능을 지원하는지 확인하고, 만약 지원하지 않는다면 적절한 CNI 플러그인으로 교체하거나 추가하는 작업을 선행해야 합니다. 이것이 바로 쿠버네티스에서 효과적인 네트워크 보안을 구현하기 위한 첫걸음입니다.