90DaysOfDevOps (Day 69)

고태규·2026년 1월 10일

devops

DevOps

목록 보기

64/75

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 69 - Enhancing Kubernetes security, visibility, and networking control logic at the Linux kernel

1. eBPF란 무엇인가?

eBPF(extended Berkeley Packet Filter)는 리눅스 커널을 소스 코드 수정이나 커널 모듈 로드 없이 안전하고 효율적으로 프로그래밍할 수 있게 해주는 기술이다.

비유:
- 웹 브라우저에 JavaScript가 도입되면서 정적인 페이지가 동적인 애플리케이션으로 변모했듯, eBPF는 리눅스 커널에게 있어 JavaScript와 같은 역할을 한다.
- 즉, 운영체제의 핵심인 커널에 동적인 프로그래밍 가능성을 부여한다
안전성:
- 샌드박스 (Sandbox) 환경에서 실행되므로, 개발자가 작성한 코드가 커널을 패닉에 빠뜨리거나 시스템 전체에 문제를 일으키지 않도록 '링 펜스 (Ring-fenced)' 처리가 되어 있다.

1-1. 작동 원리: 이벤트 기반의 샌드박스 실행

eBPF는 이벤트 기반 (Event-Driven)으로 작동한다.

사용자가 작성한 eBPF 프로그램은 커널 내 특정 이벤트가 발생할 때까지 대기하다가, 해당 이벤트가 트리거되는 순간 실행된다

사용자 공간 (User Space): Process가 새로운 프로그램을 실행하기 위해 execve()라는 시스템 호출을 수행한다.
커널 공간 (Kernel Space): 요청이 Syscall 인터페이스로 전달된다.
eBPF 훅 (Hook): 기존에는 커널이 단순히 스케줄러로 넘어갔겠지만, eBPF가 활성화되어 있다면 Attachment Point에 부착된 eBPF 프로그램이 먼저 실행된다.
데이터 수집 및 전달: eBPF 코드는 해당 이벤트의 컨텍스트 (PID, 명령어 등)를 수집하여 사용자 공간의 관측 도구로 전달하거나, 특정 로직을 수행한다.

int syscall__ret_execve(struct pt_regs *ctx) {
    struct comm_event event = {
        .pid = bpf_get_current_pid_tgid() >> 32, // 현재 프로세스 ID(PID) 수집
        .type = TYPE_RETURN,
    };
    
    bpf_get_current_comm(&event.comm, ...); // 현재 실행된 명령어 이름 수집
    comm_events.perf_submit(ctx, &event, ...); // 수집된 데이터를 사용자 공간으로 전송
    return 0;
}

이처럼 eBPF는 커널 내부의 헬퍼 함수(bpf_get_current_...)를 사용하여 프로세스 정보를 Pull 하거나 조작할 수 있다.

이 모든 과정은 샌드박스 (Sandbox) 내에서 이루어지므로, 코드가 커널을 멈추게 하거나 보안을 침해하지 않도록 안전하게 격리된 상태로 실행된다

1-2. 주요 부착 지점 (Attachment Points)

eBPF 프로그램은 커널의 다양한 레이어에 부착될 수 있으며, 이를 통해 시스템 전반에 걸친 가시성을 확보한다.

프로세스 및 스케줄링 레벨:
- 프로세스가 실행(execve)되거나 종료되는 시점을 추적
- 운영체제에서 커널 레벨로 내려오는 프로세스의 모든 활동을 감시
네트워킹 레벨 (Cilium의 핵심) - (오른쪽 흐름) :
- 가장 강력한 부착 지점 중 하나로, Cilium이 주로 활용하는 영역
- Sockets : 애플리케이션이 연결을 시도하는 순간을 포착
- TCP/IP : 패킷이 프로토콜 스택을 통과하는 과정을 추적
- Network Device (XDP/TC):
  - NIC (네트워크 카드) 드라이버 레벨에서 패킷이 들어오자마자 (Ingress) 혹은 나가기 직전 (Egress)에 eBPF가 개입
  - 해당 지점에서 패킷을 드롭하거나 리다이렉트 하면 iptables를 거치는 것보다 압도적으로 빠른 성능을 낼 수 있음.

스토리지 및 I/O 레벨 - (왼쪽 흐름) :
- Syscall: write(), read() 같은 파일 조작 요청을 가장 먼저 감지
- VFS (Virtual File System): 파일 시스템의 추상화 계층 (특정 파일 접근을 제어)
- Block Device: 실제 하드웨어로 데이터가 넘어가기 직전의 I/O 요청을 추적하여 디스크 성능 분석 가능

결국 eBPF는 리눅스 커널을 마치 마이크로서비스처럼 프로그래밍 가능하게 만들어주며, 이를 통해 별도의 커널 수정 없이도 보안, 네트워킹, 관측 가능성 기능을 동적으로 추가할 수 있게 해 준다.

2. Cilium이란?

Cilium은 eBPF 기술을 기반으로 구축된 오픈 소스 프로젝트로, CNCF를 Graduated했다.

Kubernetes 환경에서 단순한 CNI (Container Network Interface)를 넘어 네트워킹, 보안, 관측 가능성을 통합적으로 제공한다.

기존 Kubernetes 네트워킹 (iptables 기반)은 서비스가 복잡해질수록 성능 저하와 디버깅의 어려움을 겪었다.

Cilium은 리눅스 커널 레벨의 eBPF를 사용하여 이 문제를 해결한다.

작동 원리

Cilium Agent (User Space):
- 각 노드에 DaemonSet 형태로 실행된다.
- Kubernetes API 서버와 통신하며 네트워크 정책이나 서비스 변경 사항을 감지한다.
- 서비스 변경 사항을 eBPF 바이트코드로 컴파일하여 커널에 로드한다.
eBPF Programs (Kernel Space):
- 커널에 주입된 eBPF 프로그램은 네트워크 인터페이스(tc, XDP)나 소켓 등의 부착 지점 (Hook)에서 패킷을 실시간으로 처리한다.

No kube-proxy:
- Cilium은 kube-proxy의 역할을 완전히 대체할 수 있다.
- iptables의 복잡한 규칙을 거치지 않고, eBPF Map을 사용하여 O(1)에 가까운 성능으로 로드 밸런싱을 수행한다.

2-1. Cilium의 Networking 기능

Cilium은 단순한 파드 간 통신(Connectivity)을 넘어 엔터프라이즈급 네트워크 기능을 제공한다.

2-1-1. 라우팅 모드: Direct Routing vs Overlay

Cilium은 환경에 따라 유연한 네트워크 모드를 지원한다.

Overlay Network (Encapsulation): VXLAN이나 Geneve를 사용하여 패킷을 캡슐화한다. 네트워크 구성을 단순화할 수 있어 기본값으로 많이 사용된다.
Direct Routing (Native Routing): 캡슐화 없이 호스트의 라우팅 테이블을 직접 사용한다. 패킷 헤더 오버헤드가 없어 성능이 가장 뛰어나다.
- BGP 통합: Direct Routing 모드에서 Cilium은 BGP(Border Gateway Protocol)를 통해 파드 CIDR과 서비스 IP를 데이터 센터의 물리 라우터에 직접 광고한다. 이를 통해 외부 네트워크에서 NAT 없이 파드로 직접 통신이 가능하다.

2-2-2. 차세대 Ingress: Gateway API

Cilium은 기존 Ingress의 한계를 넘어서는 Gateway API를 구현하였다.

역할 분리: 인프라를 관리하는 'Gateway'와 라우팅 규칙을 정의하는 'HTTPRoute' 리소스를 분리하여 운영 효율성을 높인다.

트래픽 스플리팅 (Traffic Splitting): 실습에서 보여주었듯, 카나리 배포 시 가중치(Weight)를 설정하여 트래픽을 정교하게 분산(예: v1 99%, v2 1%)할 수 있다.

2-2-3. LB IPAM & L2 Announcement

온프레미스 환경이나 홈 랩에서는 클라우드 제공업체의 로드 밸런서 (AWS ELB 등)를 사용할 수 없다.

Cilium은 이를 자체적으로 해결한다.

LB IPAM: 별도의 도구 (MetalLB 등) 없이도 LoadBalancer 서비스에 IP를 자동으로 할당한다.

L2 Announcement: BGP 라우터가 없는 환경에서도 ARP(Address Resolution Protocol)를 사용하여 로컬 네트워크에 서비스 IP를 전파, 외부 접근을 가능하게 한다.

2-2-4. Overlay Network란?

오버레이 네트워크(Overlay Network)는 말 그대로 기존의 물리적 네트워크(Underlay Network) 위에 논리적으로 겹쳐진(Overlay) 가상의 네트워크를 의미한다.

즉, 물리적인 인프라를 기반으로 네트워크 가상화 기술을 사용하여 End-to-End 통신을 수행하는 기술이다.

오버레이 네트워크의 핵심은 캡슐화(Encapsulation) 기술에 있다.

Underlay Network (물리적 도로): 실제 스위치, 라우터, 케이블로 구성된 물리적 인프라를 의미하며, 해당 계층은 오직 노드 간의 IP 통신만 담당한다.
작동 메커니즘 (터널링):
1. 출발: 파드 A가 파드 B로 패킷을 보낸다.
2. 포장 (Encapsulation): 패킷이 노드를 떠나기 전, Cilium이 원본 패킷(파드 IP)을 새로운 헤더(노드 IP)로 감싼다. 이때 주로 VXLAN이나 Geneve 프로토콜이 사용된다.
3. 배송: 물리적 네트워크(Underlay)는 겉포장에 적힌 '노드 IP'만 보고 패킷을 전달한다. 라우터는 파드 IP 대역을 알 필요가 없다.
4. 도착 및 개봉 (Decapsulation): 목적지 노드에 도착하면 Cilium이 겉포장을 벗겨내고, 원본 패킷을 목적지 파드 B로 전달한다.

2-2-5. Cilium은 왜 다양한 라우팅 모드를 지원하는가?

Cilium이 Overlay와 Direct Routing을 구분하여 지원하는 이유는 환경적 제약과 비즈니스 요구사항 (보안, 성능)이 각기 다르기 때문이다.

1. 보안 가시성 측면

Overlay의 한계 (Black Box): 오버레이 네트워크를 사용하면, 물리적 네트워크 장비(레거시 방화벽, 스위치) 입장에서는 패킷이 암호화된 것처럼 보인다.
- 방화벽 로그에는 오직 '노드 IP' 간의 통신만 기록될 뿐, 실제 그 안에서 '어떤 파드'가 통신했는지 알 수 없다.
- 이는 기존의 물리적 보안 장비에서 파드 레벨의 IP 제어를 불가능하게 만든다.
Direct Routing의 이점 (Transparency): 캡슐화를 하지 않으므로, 물리적 네트워크 장비가 실제 파드 IP를 식별할 수 있다.
- 레거시 방화벽 연동: 기존 온프레미스 방화벽에서 "특정 파드 IP 대역만 DB 접근 허용"과 같은 정책을 그대로 유지할 수 있다.
- 소스 IP 보존: 클라이언트의 실제 IP를 보존하거나 파드의 IP를 외부로 노출시켜야 하는 보안 감사(Audit) 환경에서 유리하다.

2. 성능 측면

Overlay의 오버헤드: 오버레이 네트워크를 사용하면, 물리적 네트워크 장비 (레거시 방화벽, 스위치) 입장에서는 패킷이 암호화된 것처럼 보인다.
Direct Routing의 초고성능: 패킷을 있는 그대로 전송하므로 오버헤드가 0에 가깝다.
- 금융 거래(HFT), AI/ML 데이터 처리 등 초저지연(Low Latency)과 높은 처리량이 필수적인 환경에서는 Direct Routing이 사실상 필수 선택지다.

3. 인프라 환경 측면

Overlay (클라우드/범용성): AWS, Azure와 같은 퍼블릭 클라우드에서는 사용자가 물리 네트워크 장비인 라우터를 직접 제어(BGP 설정 등)할 수 없다.
- 밑단의 물리 네트워크가 어떻게 생겼든 상관없이 쿠버네티스를 구축해야 하므로, 호환성을 위해 Overlay가 기본값으로 사용된다.

Direct Routing (온프레미스/제어권): 자체 데이터 센터에서는 라우터와 스위치를 직접 제어할 수 있다.
- 복잡한 설정을 감수하더라도 성능과 가시성을 확보할 수 있는 환경이라면 Direct Routing을 선택하여 인프라 효율을 극대화한다

고려 사항	Overlay Network	Direct Routing
보안 가시성	물리 방화벽이 파드 식별 불가 (노드 IP만 보임)	물리 방화벽이 파드 IP 식별 가능 (기존 보안 정책 통합 유리)
성능 (Latency)	캡슐화 오버헤드 존재 (약간 느림)	오버헤드 없음 (Wire Speed)
설정 복잡도	매우 낮음 (네트워크 몰라도 됨)	높음 (BGP, 라우팅 테이블 이해 필요)
추천 환경	퍼블릭 클라우드, 빠른 구축, 개발 환경	온프레미스, 금융/통신/AI 등 고성능 환경

2-2. Security: ID 기반의 제로 트러스트

IP 주소는 클라우드 환경에서 끊임없이 변경되므로 보안 식별자로 부적합하다.

Cilium은 ID(Identity)를 기반으로 보안을 혁신한다.

2-2-1. ID 기반 정책 (Identity-based Policy)

Cilium은 파드의 Label 정보를 바탕으로 고유한 숫자 ID를 부여한다.

네트워크 정책은 IP가 아닌 이 ID를 기준으로 적용되므로, 파드가 재시작되어 IP가 바뀌어도 보안 정책은 유효하다.

암시적 거부(Implicit Deny): 화이트리스트 방식을 채택하여, 명시적으로 허용되지 않은 모든 트래픽은 기본적으로 차단한다.

2-2-2. L7 정책 제어 (API-Aware Security)

기존 방화벽은 포트(L4)까지만 제어할 수 있었다. 하지만 Cilium은 패킷의 페이로드까지 분석한다.

암시적HTTP 필터링: 단순히 "80번 포트 허용"이 아니라, "GET 메서드로 /products 경로는 허용하되, /internal 경로는 차단"하는 식의 정교한 규칙을 설정할 수 있다.

2-2-3. 투명 암호화 (Transparent Encryption)

애플리케이션 코드를 수정하거나 사이드카를 주입할 필요 없이, Cilium 설정(enable-wireguard: true)만으로 모든 트래픽을 암호화한다.

WireGuard: 커널 레벨에서 작동하는 고성능 VPN 프로토콜인 WireGuard를 사용하여 노드 간 및 파드 간 통신을 보호한다.

2-3. Observability: Hubble이 보여주는 심층 가시성

Hubble은 Cilium의 Data Plane 위에 구축된 분산형 관측 플랫폼이다.

eBPF를 사용하여 오버헤드 없이 깊이 있는 데이터를 수집한다.

2-3-1. 서비스 맵 & 플로우 로그

Service Map: 어떤 서비스가 누구와 통신하고 있는지, 연결이 성공했는지 실패했는지(색상 구분)를 실시간 그래프로 시각화한다.
Flow Logs: 네트워크 패킷의 흐름을 마치 tcpdump나 Wireshark를 사용하는 것처럼 상세하게 보여준다. 특히 Kubernetes 메타데이터(파드 이름, 네임스페이스)와 결합되어 있어 해석이 용이하다.

2-3-2. L7 가시성 및 메트릭

프로토콜 분석: HTTP 요청의 경로, 응답 코드, 지연 시간 등을 별도의 프록시 설정 없이 eBPF 레벨에서 추출한다.
DNS 모니터링: DNS 쿼리 실패나 응답 지연 등을 추적하여, 네트워크 문제인지 DNS 문제인지 빠르게 식별할 수 있다. 실습에서는 잘못된 DNS 설정을 Hubble을 통해 찾아내는 과정을 보여주었다.

2-3-2. Tetragon (런타임 보안)

Cilium의 보안 기능을 완성하는 것은 Tetragon이다.

이는 단순한 네트워크 감시를 넘어 프로세스 실행을 감시한다.

포렌식: 실습 시나리오에서 Death Star가 폭발했을 때, Tetragon은 어떤 파드(TIE Fighter)가 kill 명령어를 실행했는지, 사용된 인자(Arguments)는 무엇인지, 실행 당시의 권한(Capabilities)은 어땠는지까지 커널 레벨에서 추적하여 보여준다.

결국 Cilium은 eBPF를 통해 커널의 능력을 극대화함으로써, 플랫폼 엔지니어와 보안 담당자는 성능 저하 없이도 전례 없는 수준의 제어권과 가시성을 확보할 수 있다.

3. Discovery Lab 1: 플랫폼 엔지니어링

해당 실습 랩은 플랫폼 엔지니어가 애플리케이션 팀에게 기본 연결성뿐만 아니라 보안, 가시성, 그리고 고급 트래픽 관리 기능을 제공하는 방법을 중점적으로 다룬다.

3.1 Hubble UI를 통한 서비스 의존성 및 L7 가시성 확보

Hubble UI는 별도의 애플리케이션 수정 없이 eBPF를 통해 커널 레벨에서 네트워크 데이터를 수집하여 시각화한다.

Service Map (서비스 맵): Endor 네임스페이스와 같이 특정 논리적 경계 내에서 서비스들이 서로 어떻게 상호작용하는지 그래프 형태로 보여준다.
플로우 시각화 (Flow Visualization): 트래픽의 허용 및 차단 여부를 색상으로 구분한다. 예를 들어, X-Wing 파드가 Death Star와 통신을 시도할 때 명시적인 네트워크 정책이 없으므로 '암시적 거부(Implicit Deny)'에 의해 트래픽이 차단(Drop)되며, 이는 UI 상에서 빨간색 선으로 즉시 식별된다.
L7 심층 가시성: 단순한 TCP/IP 연결 정보를 넘어, HTTP 트래픽의 상세 정보를 제공한다.
- HTTP 메서드: GET, POST, DELETE 등의 메서드를 식별한다.
- URL 경로: /login, /products 등 구체적인 호출 경로를 확인할 수 있다.
- DNS 정보: 외부 통신 시 swapi.dev, disney.com과 같은 FQDN(Fully Qualified Domain Name)을 보여주어 외부 의존성을 파악하게 해준다.

3.2 외부 노출 전략: Ingress에서 Gateway API로의 진화

외부 트래픽을 클러스터 내부로 유입시키는 두 가지 표준 방식을 비교한다.

Ingress (기존 방식):
- Cilium을 Ingress Controller로 사용하여 TLS 종료를 처리한다.
- deathstar.cilium.rocks 호스트로 들어오는 HTTPS(443) 요청을 백엔드 서비스인 deathstar의 80 포트로 라우팅하는 규칙을 정의한다.
- 한계: 인프라 설정 (TLS 인증서, 로드밸런서)과 라우팅 규칙이 하나의 리소스에 혼재되어 있어, 플랫폼 팀과 앱 팀 간의 역할 분리가 어렵다.
Gateway API (차세대 표준):
- 역할 분리: Gateway 리소스(인프라/리스너 설정)와 HTTPRoute 리소스(라우팅 규칙)를 분리하여 운영 효율성을 높인다.
- 트래픽 스플리팅 (Traffic Splitting): HTTPRoute 리소스에서 weight 필드를 사용하여 카나리 배포를 구현한다.
- 실습 예시: 기존 Death Star 서비스에 가중치 1, 새로운 Death Star v2 서비스에 가중치 99를 부여한다. 실제로 200번의 요청을 보냈을 때, 약 198건이 v2로, 2건이 기존 버전으로 라우팅되는 것을 검증한다.

3.3 Grafana & Prometheus를 활용한 네트워크 트러블슈팅

Hubble의 메트릭을 Prometheus가 수집하고, 이를 Grafana 대시보드에서 시각화하여 문제를 해결한다.

DNS 문제 진단 시나리오:
- 증상: 외부 리소스와 통신이 되지 않는 상황에서 Grafana의 'Network Overview' 대시보드를 확인한 결과, DNS 쿼리 수는 급격히 줄어들고 'Missing DNS Responses' 지표가 나타난다.
- 원인 분석: hubble observe CLI를 통해 CoreDNS 포드의 트래픽을 분석한다. DNS 요청이 정상적인 DNS 서버가 아닌 1.2.3.4라는 잘못된 IP로 전송되고 있음을 확인한다.
- 해결: CoreDNS 설정을 수정하여 포워더(Forwarder) 주소를 8.8.8.8로 변경하고, 포드를 재시작하여 정상적인 DNS 해석이 이루어지도록 조치한다.
골든 시그널 모니터링: 애플리케이션 자체에 계측 코드를 심지 않아도, Cilium이 커널 레벨에서 수집한 데이터를 통해 요청 성공률, 처리량, 지연 시간(P50, P95, P99)과 같은 핵심 성과 지표를 모니터링한다.

4. Discovery Lab 2: 클라우드 네트워크 엔지니어링

해당 랩은 Kubernetes를 고립된 섬이 아닌, 기존 데이터 센터 네트워크의 일원으로 통합하는 과정을 다룬다.

4-1. BGP (Border Gateway Protocol)를 이용한 직접 라우팅

Direct Routing (직접 라우팅): 오버레이 방식의 오버헤드를 제거하기 위해 호스트 네트워크를 그대로 사용한다.
BGP Peering 설정:
- CiliumBGPPeeringPolicy 리소스를 사용하여 각 노드가 Top-of-Rack (ToR) 라우터와 BGP 세션을 맺도록 설정한다.
- 설정 내용에는 로컬 ASN, 피어 ASN, 그리고 피어링할 라우터의 IP 정보가 포함된다.
경로 광고:
- 클러스터 내부의 Pod CIDR 대역을 BGP를 통해 외부 네트워크에 광고한다.
- 이를 통해 외부 네트워크 장비는 파드의 IP가 어느 노드에 위치하는지 알게 되며, NAT 없이 파드 IP로 직접 트래픽을 보낼 수 있게 된다.

4-2. IPv4/IPv6 듀얼 스택 (Dual Stack)

간편한 활성화: Cilium 설정 파일(ConfigMap 등)에서 enable-ipv6: true 옵션을 켜는 것만으로 듀얼 스택 네트워킹을 활성화한다.

검증: 애플리케이션(Death Star) 배포 시 IPv4와 IPv6 주소가 모두 할당되는 것을 확인하고, 외부 클라이언트(Outpost)에서 IPv6 주소를 사용하여 파드에 직접 접속하는 연결성을 테스트한다.

4-3. LB IPAM & L2 Announcement

클라우드 제공업체의 로드밸런서 없이 온프레미스 환경에서 서비스 IP를 관리하는 방법이다.

LB IPAM: CiliumLoadBalancerIPPool 리소스를 정의하여 서비스에 할당할 IP 대역 (CIDR)을 설정한다. 서비스 생성 시 이 풀에서 자동으로 IP가 할당된다.
L2 Announcement (ARP):
- BGP 라우터가 없는 환경 (홈 랩 등)에서는 ARP 프로토콜을 사용하여 로컬 네트워크에 서비스 IP를 알린다.
- 실습에서는 서비스 리소스에 announce=bgp와 같은 레이블을 부착하여, 해당 IP가 어떤 프로토콜(BGP 또는 L2)을 통해 전파될지 제어하는 과정을 보여준다.

4-4. Egress Gateway (출구 트래픽 제어)

문제점:
- 파드가 외부 시스템 (방화벽으로 보호된 DB 등)에 접근할 때, 트래픽은 파드가 실행 중인 노드의 IP로 Masquerade (SNAT)되어 나간다.
- 파드는 어떤 노드에서든 실행될 수 있으므로, 방화벽 팀은 모든 노드의 IP를 허용해야 하는 보안 구멍이 발생한다.
해결책: CiliumEgressGatewayPolicy를 적용한다.
- "특정 레이블(org=empire)을 가진 파드의 트래픽은 반드시 지정된 게이트웨이 노드의 특정 인터페이스를 통해 나가야 하며, 이때 고정된 Egress IP(예: 10.0.x.x)를 사용해야 한다"고 정의한다.

결과: 외부 방화벽은 해당 고정 IP 하나만 허용하면 되므로 보안 정책을 단순화하고 강화할 수 있다.

5. Discovery Lab 3: SecOps 엔지니어링

해당 랩은 네트워크 레벨의 차단을 넘어, 커널 레벨에서의 런타임 감시 및 집행을 통해 심층적인 보안을 구축하는 방법을 다룬다.

5-1. 네트워크 정책과 상호 인증 (Mutual Authentication)

암시적 거부 (Implicit Deny): 화이트리스트 모델을 기반으로 한다. 정책이 정의되지 않은 트래픽(X-Wing -> Death Star)은 기본적으로 차단되며, 이를 통해 공격 표면을 줄인다.
상호 인증 (mTLS):
- 애플리케이션 코드 수정이나 사이드카 프록시 주입 없이, 네트워크 정책에 authentication: mode: required를 추가하는 것만으로 파드 간 mTLS를 적용한다.
- Hubble UI에서는 자물쇠 아이콘을 통해 해당 통신이 암호화되고 인증되었음을 시각적으로 보여준다.

5-2. 투명 암호화 (Transparent Encryption)

WireGuard 적용: 클러스터 설정에서 enable-wireguard: true를 적용하면, 노드와 노드 사이를 오가는 모든 트래픽이 커널 레벨에서 자동으로 암호화된다.

보호 범위: 파드 간 통신뿐만 아니라, 노드 자체의 제어 트래픽까지 암호화하여 네트워크 스니핑과 같은 중간자 공격 위험을 원천 차단한다.

5-3. Tetragon: 런타임 보안 관측 및 집행

네트워크 정책만으로는 막을 수 없는, 이미 침투한 공격이나 내부자의 악의적 행위를 탐지한다.

사고 시나리오: Death Star가 폭발하는 사고가 발생했고, 로그에는 "Panic: Death Star exploded"라는 메시지만 남아있다.
포렌식 분석 과정:
1. Hubble 분석: exhaust-port(배기구) 엔드포인트로 HTTP 요청이 들어온 것을 확인한다. 공격 주체는 적군이 아닌 내부의 TIE Fighter(아군) 파드였다.
2. Tetragon 심층 분석: 단순히 "누가 접속했다"를 넘어 "어떤 프로세스가 실행되었는가"를 추적한다.
3. 로그 상세 확인: Tetragon 로그는 다음과 같은 상세 정보를 JSON 형태로 제공한다.
  - 바이너리: /usr/bin/kill과 같은 실행 파일 경로.
  - 인자 (Arguments): kill 명령어 뒤에 붙은 구체적인 파라미터.
  - 프로세스 권한: 컨테이너가 실행될 당시의 리눅스 Capabilities 및 네임스페이스 정보.
결과:
- 이를 통해 TIE Fighter 파드 내부에서 누군가 악의적인 의도(또는 실수)로 kill 명령어를 실행하여 Death Star 프로세스를 종료시켰음을 정확히 규명한다.
- Tetragon은 이러한 행위를 실시간으로 탐지하고, 설정에 따라 즉시 프로세스를 강제 종료(SIGKILL)하여 공격을 차단할 수도 있다.

6. 정리

eBPF는 리눅스 커널을 수정 없이 안전하고 효율적으로 프로그래밍할 수 있게 해주는 혁신적인 기술이며, Cilium은 이 eBPF를 기반으로 Kubernetes의 네트워킹, 보안, 가시성을 통합적으로 제공하는 플랫폼이다.

기존 iptables나 사이드카 방식의 성능 한계와 복잡성을 극복하고, 커널 레벨에서의 고성능 데이터 처리와 L7 수준의 심층적인 가시성을 보장한다.

인프라 환경에 구애받지 않는 유연한 연결성(Overlay/Direct Routing)과 강력한 보안(Zero Trust, 런타임 감시)을 제공하기 때문에, 복잡해지는 클라우드 네이티브 환경을 효율적이고 안전하게 운영하기 위한 필수적인 선택지라 할 수 있다.

고태규

이전 포스트

90DaysOfDevOps (Day 68)

다음 포스트