Cilium 환경에서 host는 nftables, k8s 네트워크는 Cilium 정책으로 분리 운영하는 사례가 있을까요?

Ask a Question
,
1

안녕하세요. 질문이 있습니다.

Cilium을 공부하면서 실무 적용을 고민하고 있는데요,
legacy iptables 기반 방화벽이나 기본 Kubernetes NetworkPolicy 대신 아래와 같은 방식으로 운영하는 사례가 있는지 궁금합니다.

제가 고려 중인 운영 방식은 다음과 같습니다.

  1. 호스트(Node) 레벨

    • Ansible로 nftables를 관리

    • 노드 자체에 대한 접근은 SSH(22/tcp)만 허용

    • SSH는 bastion/사무실 IP 등 허용된 IP만 접근 가능

    • 즉, nftables는 host security perimeter 용도로만 사용

  2. Kubernetes 네트워크 정책

    • Pod/Service 간 트래픽은 nftables가 아닌

      • CiliumNetworkPolicy

      • CiliumClusterwideNetworkPolicy

    • 를 사용하여 제어

    • 정책은 GitOps 방식으로 관리 (Git + Ansible 또는 ArgoCD 등)

예시: host-only nftables 설정

define SSH_ALLOWED_V4 = {
  ip1,         # bastion
  ip2/24        # office
}

table inet filter {

  chain input {
    type filter hook input priority 0; policy drop;

    # Loopback
    iif "lo" accept

    # Established connections
    ct state established,related accept

    # SSH from approved IPs only
    ip saddr $SSH_ALLOWED_V4 tcp dport 22 ct state new accept

    # ICMP
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }
}

궁금한 점

  • 실제로 이런 구조로 운영 중인 회사/팀이 있는지

  • 운영/트러블슈팅/보안 측면에서의 장단점이나 주의사항

실제 운영 사례나 경험 공유해주시면 감사하겠습니다

1 Like
2

제시하신 구조는 충분히 합리적이고 현실적인 선택입니다.

노드 레벨에서는 OS 보안 경계를 명확히 닫고, 접근 경로를 최소화하는 역할까지만 맡기고
쿠버네티스 내부 트래픽 제어는 전부 CNI(NetworkPolicy) 계층으로 올리는 방식은
운영·보안·트러블슈팅 측면에서 가장 책임 구분이 깔끔한 구조에 가깝습니다.
특히 kubeadm이나 kubespray로 직접 클러스터를 구성하는 환경이라면 더 그렇습니다.

노드 방화벽을 host security perimeter 용도로만 쓰겠다는 판단도 타당합니다.
SSH 접근을 제한하고, 관리 트래픽만 허용하고,
Pod 간 통신이나 Service 흐름에는 관여하지 않겠다는 선을 그어두면
문제가 생겼을 때 “어디를 봐야 하는지”가 바로 드러납니다.
이 경계가 흐려질수록, 운영 난이도는 기하급수적으로 올라갑니다.

Cilium을 선택해서 NetworkPolicy와 ClusterwidePolicy로 트래픽을 제어하는 것도
기술적으로 과한 선택이라기보다는,
“쿠버네티스 네트워크를 쿠버네티스답게 관리하겠다”는 선언에 가깝다고 봅니다.
다만 그만큼 정책 설계와 변경에 대한 책임은 전부 운영팀 몫이 되고,
eBPF 특성상 디버깅 역량이 없는 상태에서는 체감 난이도가 급격히 올라갈 수는 있습니다.

그래서 이 구조의 성패는 기술 선택보다는,
운영 원칙을 얼마나 엄격하게 지키느냐에 달려 있다고 봅니다.
노드 방화벽으로 Pod 트래픽을 건드리지 않기,
문제 발생 시 항상 CNI 정책부터 의심하기,
정책은 반드시 Git으로 관리하고 수동 변경을 금기시하기,
이 정도가 지켜지면 구조 자체는 충분히 안정적으로 굴러갑니다.

요약하면,
상용 플랫폼을 전제하지 않은 순수 리눅스 + 쿠버네티스 환경에서는
질문 주신 방식이 “가장 이상적이진 않더라도, 가장 설명 가능한 구조”에 가깝습니다.
운영자가 모든 레이어를 이해하고 있다는 전제만 충족된다면,
굳이 더 복잡한 추상화가 필요하지도 않아 보입니다.

VMware VCF 9.0, 정확히는 VMware Cloud Foundation 9.x 기준에서 보면, 질문 주신 구조와 생각 자체는 크게 다르지 않습니다. 다만 구현 방식과 책임 분리가 조금 다를 뿐입니다.

VCF에서는 기본적으로 호스트 보안과 쿠버네티스 네트워크 보안을 명확히 분리합니다.
ESXi 호스트 레벨에서 iptables나 nftables로 뭔가를 직접 만지는 구조는 거의 권장되지 않고, 그 역할은 NSX 쪽으로 올라가 있습니다. 즉, 질문에서 말한 *“host security perimeter”*는 VCF에서는 NSX Distributed Firewall(DFW) 이 담당합니다.

개념적으로 보면 이렇게 대응됩니다.

질문하신 구조에서
노드 레벨 nftables로 SSH만 허용하고 나머지는 차단하는 부분은
VCF에서는 ESXi/워크로드 VM 단위의 DFW 규칙으로 처리됩니다.
bastion IP만 SSH 허용, 관리 트래픽만 허용 같은 패턴은 굉장히 흔합니다.
다만 이걸 각 노드에 설정 파일로 관리하지 않고, 중앙 정책으로 밀어넣는 차이입니다.

그리고 쿠버네티스 내부 트래픽 제어 쪽은,
VCF 9.0에서 VKS를 쓸 경우 기본 CNI가 Antrea이고,
Antrea NetworkPolicy 또는 Antrea ClusterPolicy를 사용합니다.
이 역할이 질문에서 언급하신 CiliumNetworkPolicy / ClusterwidePolicy와 거의 동일한 위치에 있습니다.

즉 구조만 놓고 보면,

  • 호스트/노드 접근 제어:
    nftables → VCF에서는 NSX DFW

  • Pod/Service 간 통신 제어:
    CiliumNetworkPolicy → VCF에서는 Antrea NetworkPolicy

  • 정책의 선언적 관리:
    GitOps → VCF에서도 충분히 가능 (정책 소스는 다를 뿐)

이렇게 역할이 대응됩니다.

운영 관점에서 보면, VCF가 선택한 이유도 질문하신 고민과 거의 같습니다.
호스트 레벨 방화벽과 쿠버네티스 네트워크 정책을 한 계층에서 섞기 시작하면,
장애가 났을 때 “이게 노드 문제인지, CNI 문제인지”가 바로 안 보이기 때문입니다.

VCF 쪽에서는
“호스트에 붙는 트래픽은 여기까지,
쿠버네티스 안에서 도는 트래픽은 여기부터”
이 경계를 굉장히 강하게 가져갑니다.

다만 차이점도 분명합니다.
질문 주신 구조는 리눅스 친화적이고, 투명하며, 손에 잡히는 대신
운영자가 모든 계층을 이해하고 책임져야 합니다.
VCF 구조는 중앙 통제와 가시성은 강하지만, 내부 동작은 블랙박스에 가깝습니다.

그래서 정리해 보면,
“nftables + Cilium”로 설계하신 구조는
VCF 9.0이 지향하는 보안 경계 분리 철학과는 일치하지만,
구현은 더 로우레벨이고, 운영 책임은 훨씬 엔지니어 쪽에 가깝습니다.

VCF는 이걸

  • NSX로 호스트/워크로드 경계 고정

  • CNI 정책으로 쿠버네티스 내부 제어

  • 중앙 가시성과 감사 로그 확보

이렇게 패키징해 놓은 셈이고요.

그래서 결론적으로는,
“질문 주신 구조가 비현실적이냐?”는 전혀 아니고,
오히려 VCF가 상용 환경에서 채택한 구조를 오픈소스로 직접 구현한 형태에 가깝다고 보셔도 무리가 없습니다.

질문 주신 구조를 Red Hat 진영 기준으로 보면, 생각하신 방향이 꽤 정확한 편입니다.
다만 Red Hat 쪽에서는 이걸 “가능한가?”라기보다 **“어디까지를 플랫폼이 책임지고, 어디부터를 사용자가 책임질 것인가”**로 정리해 두었습니다.

Red Hat / OpenShift 기준에서 보면, 기본 전제는 이렇습니다.
호스트(OS)는 최대한 건드리지 말고, 네트워크 정책은 쿠버네티스 계층에서 끝내자는 쪽에 가깝습니다.

노드 레벨 보안부터 보면, OpenShift에서는 질문하신 것처럼 각 노드에 nftables를 직접 관리하는 패턴을 거의 권장하지 않습니다. RHEL 자체에는 nftables가 당연히 있고, 내부적으로도 쓰이지만, 운영자가 Ansible로 직접 룰을 관리하는 영역은 보통 “최소 접근 제어” 정도로 한정됩니다. 예를 들면 SSH 접근을 bastion IP로만 제한하는 수준까지는 현실적인 선택이고, 그 이상을 노드 방화벽으로 가져가면 문제 생겼을 때 책임 경계가 흐려집니다.

그래서 Red Hat 쪽 문맥에서는,
노드 보안은 OS hardening + 접근 경로 제한 정도로 닫고,
네트워크 통제의 주 무대는 쿠버네티스 안으로 가져옵니다.

쿠버네티스 네트워크 정책 쪽은 훨씬 명확합니다.
OpenShift에서는 CNI가 사실상 두 갈래로 정리돼 있습니다.

하나는 OVN-Kubernetes 기반이고,
다른 하나는 Calico 입니다.

이 둘 모두 NetworkPolicy / Cluster-wide 정책을 “플랫폼 표준 기능”으로 다루고 있고,
정책은 YAML로 선언하고 GitOps로 관리하는 게 전혀 낯설지 않은 구조입니다.

질문에서 말하신
“Pod/Service 간 트래픽은 호스트 방화벽이 아니라 CNI 정책으로 제어한다”는 접근은
OpenShift 기준으로 보면 정석에 가깝습니다.
실제로 Red Hat 쪽에서는,
노드 방화벽으로 Pod 트래픽을 만지기 시작하면
“그건 쿠버네티스가 아니다”라는 식의 반응이 나오는 경우도 많습니다.

Cilium 이야기를 하면, 이 부분이 중요합니다.
OpenShift는 기본적으로 Cilium을 공식 CNI로 채택하지 않습니다.
기술적으로 못 써서라기보다는,
eBPF 기반 CNI를 플랫폼 기본값으로 가져가기엔
디버깅, 지원, 책임 분리가 아직 어렵다는 판단이 큽니다.

그래서 Red Hat 월드에서는
Cilium은 **“특정 요구가 있는 환경에서 선택적으로 검토할 수 있는 기술”**이지,
플랫폼 표준으로 전제되는 구성은 아닙니다.

이걸 질문 주신 구조에 대입해 보면,

노드 레벨에서는
SSH 접근 제어 정도까지만 OS 방화벽으로 닫고,

쿠버네티스 내부에서는
OVN-Kubernetes나 Calico NetworkPolicy로 트래픽을 통제하고,

정책 관리는
GitOps(ArgoCD 등)로 선언적으로 가져가는 것,

이게 Red Hat 기준에서 가장 “말이 되는” 운영 모델입니다.

운영과 트러블슈팅 관점에서도,
Red Hat 쪽은 일관되게
“문제는 한 레이어에서만 나야 한다”는 철학을 가져갑니다.
노드 방화벽, CNI, 서비스 메시가 섞여서 동시에 의심받는 구조를 극도로 싫어합니다.

그래서 결론적으로 보면,
질문하신 구조는 Red Hat 월드에서는 이렇게 번역됩니다.

  • nftables: 가능은 하지만, 최소한으로

  • Pod 네트워크 제어: 무조건 CNI 정책으로

  • 정책 관리: GitOps 전제

  • eBPF(Cilium): 표준보다는 선택지

VCF가 NSX로 이걸 패키징했다면,
Red Hat은 **“OS는 단순하게, 쿠버네티스는 명확하게”**로 정리해 둔 셈입니다.

Rancher 기준으로 보면, 질문 주신 구조는 “특이한 실험”이라기보다는
꽤 전형적인 엔터프라이즈 멀티 클러스터 운영 고민에 가깝습니다.
Rancher가 만들어진 배경 자체가 이런 고민에서 출발했기 때문입니다.

Rancher / SUSE 월드에서는, 기본 전제가 하나 있습니다.
**“쿠버네티스는 제각각이어도 되고, 네트워크도 다를 수 있다”**는 점입니다.
VCF나 OpenShift처럼 “이게 정석이다”를 강하게 밀지 않습니다.

그래서 호스트 레벨부터 보면,
Rancher 환경에서는 노드 OS가 굉장히 다양합니다.
RKE/RKE2, k3s, 클라우드 매니지드 노드, 온프레미스 VM까지 섞이는 게 자연스럽죠.
이 때문에 노드 방화벽을 중앙에서 정교하게 통제하려는 접근은 보통 포기합니다.

다만 질문 주신 것처럼
SSH 접근을 bastion이나 특정 IP로만 제한하고,
노드 자체는 최대한 닫아두는 방식은 Rancher 월드에서도 흔합니다.
이걸 “네트워크 보안”이라기보다는
OS 접근 최소화(hardening) 정도로 봅니다.
Ansible로 nftables를 관리하는 것도 전혀 이상하지 않습니다.

대신 Rancher 쪽에서 훨씬 중요하게 보는 건,
“노드에서 무슨 패킷이 오가느냐”보다
**“클러스터 안에서 누가 누구랑 통신하느냐”**입니다.

그래서 Pod/Service 간 통신 제어를
호스트 방화벽이 아니라 CNI 정책으로 가져가려는 질문 주신 접근은
Rancher 기준에서는 아주 자연스럽습니다.

Rancher의 특징은 CNI를 하나로 고정하지 않는다는 점입니다.
현실적으로는
Calico,
Cilium,
클라우드 기본 CNI가 섞여 있는 경우가 많습니다.

그래서 Rancher world에서는
“Cilium을 쓰느냐, Calico를 쓰느냐”보다
**“정책을 클러스터마다 다르게 써도 관리가 되느냐”**가 더 큰 이슈입니다.

이 지점에서 GitOps가 거의 필수가 됩니다.
정책을 YAML로 정의하고,
클러스터별로 적용 범위를 나누고,
Rancher는 그걸 ‘보여주고 묶어주는 역할’에 가깝습니다.
정책 자체를 Rancher가 마법처럼 해결해 주지는 않습니다.

Cilium을 기준으로 보면,
Rancher world는 VCF나 OpenShift보다 훨씬 관대합니다.
eBPF를 쓰는 것도,
CiliumNetworkPolicy / ClusterwidePolicy를 쓰는 것도
“운영팀이 감당할 수 있으면 된다”는 쪽에 가깝습니다.
대신 그만큼 트러블슈팅 책임도 전부 운영팀 몫입니다.

그래서 실제 Rancher 환경에서는 이런 경계가 생깁니다.

노드 레벨에서는
– 접근 경로만 최소화
– nftables는 host-only perimeter 용도

쿠버네티스 내부에서는
– CNI 정책으로만 통신 제어
– 클러스터 단위로 정책 책임 분리

그리고 그 위에서
– Rancher는 ‘통합 관리 창구’ 역할
– GitOps가 실질적인 정책 배포 수단

질문 주신 구조를 그대로 대입하면,
Rancher world에서는
“이론적으로 맞다”가 아니라
**“운영자가 책임질 각오만 돼 있으면 충분히 현실적인 구조”**라고 보셔도 됩니다.

VCF가 NSX로 강하게 가드를 치고,
Red Hat이 플랫폼 규율을 강조한다면,
Rancher는 자유도를 주는 대신 통제는 직접 하라는 쪽입니다.

그래서 이 구조가 잘 맞는 조직은
이미 네트워크, 쿠버네티스, OS 레이어를
구분해서 생각할 수 있는 팀이고,
안 맞는 조직은
“누가 어디까지 책임지는지”가 아직 불명확한 경우입니다.

3 Likes
3

답변 감사합니다 :slight_smile:

1 Like
4

읽다 보니 생각이 조금 바뀌었습니다.

Cilium을 쓰는 전제라면,
노드 레벨에서 nftables를 굳이 유지할 필요가 있을지 다시 고민하게 되네요.
Cilium은 node/host 엔드포인트에 라벨을 붙여서 Host Firewall 수준의 제어도 가능하고,
실제로는 iptables/nftables을 우회해서 커널 eBPF 경로에서 바로 처리하니까요.

오히려
– nftables를 완전히 비활성화하고
– SSH 포함한 노드 보호까지 Cilium Host/Node policy로 일원화하면

레이어가 더 단순해지고,
패킷 경로도 짧아져서 성능 면에서도 이점이 있을 것 같다는 생각이 듭니다.

그래서 궁금한 점이 있는데,
nftables 없이 Cilium(eBPF)만으로 host + pod 트래픽을 모두 커버하는 구성을
실제 프로덕션에서 운영해 보신 사례가 있는지요?

있다면 안정성이나 트러블슈팅 관점에서
주의해야 할 포인트가 무엇이었는지도 듣고 싶습니다.

1 Like
5

기술적 성숙도 측면에서는 정답입니다. 하지만 운영적 지속성 측면에서는 다음과 같은 '중도 모델’을 권장합니다.

“가장 중요한 생명줄(SSH, Kubelet API)은 nftables로 아주 좁게 열어두고, 나머지 워크로드 관련 노드 보안은 Cilium Host Policy로 넘기는 전략”

이렇게 하면 Cilium이 죽더라도 노드에 접속해서 살릴 수 있는 '최소한의 통로’는 확보하면서, 복잡한 트래픽 제어는 eBPF의 성능 이점을 챙길 수 있습니다.

기술적으로 매우 우아하고 "Cloud Native"다운 발상입니다. Cilium의 Host Firewall(Host Policies) 기능을 활용해 노드와 파드의 보안 경계를 eBPF라는 단일 데이터 플레인으로 통합하는 것은 성능과 관리 일관성 측면에서 분명한 ‘종착역’ 중 하나입니다.

다만, 이상과 현실 사이에는 언제나 **‘운영이라는 괴물’**이 살고 있죠. 질문하신 부분에 대해 실무적인 관점에서의 우문현답을 정리해 드립니다.

1. 실제 프로덕션 사례: “누가 이렇게 쓰고 있나?”

실제로 nftables/iptables를 완전히 걷어내고 Cilium Host Policy로 통합하는 구성은 **초대규모 인프라(Hyper-scaler)**나 특수 목적 하드웨어 환경에서 주로 발견됩니다.

  • GKE Dataplane V2: 구글 클라우드의 GKE는 Cilium 기반이며, 상당 부분의 호스트 보호 로직을 eBPF로 처리합니다. 사용자는 iptables를 거의 볼 일이 없습니다.

  • Telco/5G 인프라: 초저지연이 생명인 환경에서는 패킷이 커널의 네트워킹 스택(iptables 등)을 통과하며 발생하는 오버헤드 $O(N)$를 줄이기 위해 eBPF를 이용한 직접 처리를 선호합니다.

  • 금융권 보안 강화 모델: 'Zero Trust’를 노드 레벨까지 적용하려는 팀들이 Cilium의 CiliumClusterwideNetworkPolicy를 통해 노드 간 SSH 트래픽까지 화이트리스트로 관리합니다.

2. 주의해야 할 포인트: “기술적 우아함이 독이 되는 순간”

막상 nftables를 끄고 Cilium으로 일원화했을 때 마주하게 될 실무적인 '복병’들은 다음과 같습니다.

① 부트스트랩 패러독스 (The Bootstrap Paradox)

가장 치명적인 문제입니다.

  • 현상: Cilium은 결국 쿠버네티스 위에서 '데몬셋(DaemonSet)'으로 실행됩니다.

  • 위험: 만약 노드가 재부팅되었는데, 어떤 이유(이미지 풀링 실패, CNI 설정 오류 등)로 Cilium 파드가 뜨지 않는다면?

  • 결과: 노드의 보안 정책이 로딩되지 않은 '무방비 상태’가 되거나, 반대로 정책이 없어서 모든 통신이 끊겨 원격 SSH 복구조차 불가능한 '벽돌 상태’가 될 수 있습니다.

Tip: 이를 방지하기 위해 Cilium은 Cilium Node Init 컨테이너나 별도의 시스템드(systemd) 서비스를 통해 Cilium이 뜨기 전 최소한의 보호막을 치는 복잡한 설계를 요구합니다.

② "보이지 않는 적"과의 싸움 (Troubleshooting)

전통적인 엔지니어에게 iptables -L이나 nft list ruleset은 '진리’였습니다.

  • 문제: Cilium Host Policy는 커널 내부 eBPF 맵에 저장됩니다. 일반적인 네트워크 진단 도구로는 룰이 왜 적용 안 되는지 보이지 않습니다.

  • 도구의 한계: cilium bpf hostfw list 같은 전용 CLI 명령어를 숙달해야 하며, 문제가 생겼을 때 "이건 OS 문제인가, Cilium 문제인가?"를 두고 인프라 팀과 플랫폼 팀이 서로 얼굴을 붉히기 딱 좋습니다.

③ 커널 의존성의 덫

Cilium Host Firewall은 비교적 최신 기능입니다.

  • 사용하시는 리눅스 커널 버전(최소 5.10 이상 권장)에 따라 BPF 헬퍼 함수 지원 여부가 달라지며, 특정 커널 패치에서 예기치 못한 패킷 드롭이 발생할 확률이 기존 nftables보다 훨씬 높습니다.
1 Like