eBPF 런타임 보안: Falco·Tetragon 실전 가이드 2026

왜 지금 eBPF 기반 런타임 보안인가

솔직히 말해서, 2026년 리눅스 보안 환경은 꽤 험악합니다. 하루 평균 8~9건의 새로운 커널 CVE가 보고되고 있고, 랜섬웨어 그룹들은 커널 익스플로잇을 적극적으로 무기화하고 있죠. 전통적인 패치 기반 대응만으로는 더 이상 버틸 수가 없는 상황입니다.

숫자를 한번 보면 현실이 확 와닿습니다. 기업의 평균 패치 사이클이 30~60일인 반면, 공격자들은 공개된 취약점을 15일 이내에 무기화합니다. 이 15~45일의 위험 창(risk window)—이 간극을 메울 수 있는 기술이 바로 eBPF 기반 런타임 보안 모니터링입니다.

eBPF(Extended Berkeley Packet Filter)는 커널 소스 코드를 수정하거나 모듈을 로드하지 않고도 커널 공간에서 사용자 정의 프로그램을 안전하게 실행할 수 있는 기술인데요. CNCF 2026년 1분기 보고서에 따르면 eBPF 기반 보안 솔루션의 프로덕션 도입률이 전년 대비 300%나 증가했습니다. 이 수치만 봐도 업계의 분위기가 느껴지실 겁니다.

이 가이드에서는 eBPF 생태계의 양대 도구인 Falco(탐지 중심)와 Tetragon(집행 중심)을 활용해서, 프로덕션 환경에서 커널 수준 위협 탐지 시스템을 구축하는 과정을 처음부터 끝까지 다뤄보겠습니다.

eBPF 보안 모니터링의 작동 원리

eBPF가 보안에 혁명적인 이유를 이해하려면, 기존 보안 도구들의 한계를 먼저 알아야 합니다. 전통적인 호스트 기반 침입 탐지 시스템(HIDS)은 로그 파일 분석이나 파일 무결성 검사에 의존했는데, 이 방식은 공격이 이미 성공한 후에야 탐지가 가능하다는 치명적인 단점이 있었습니다.

eBPF는 이 패러다임을 완전히 뒤집습니다.

커널 내부의 훅 포인트(hook point)에 프로그램을 부착해서, 시스템 콜 호출, 프로세스 생성, 파일 접근, 네트워크 연결 같은 이벤트가 발생하는 바로 그 순간에 실시간으로 감시하고 대응할 수 있습니다. 사후 대응이 아니라 실시간 감시라는 점이 핵심이죠.

eBPF 보안 프로그램의 실행 흐름

eBPF 기반 보안 도구가 어떻게 동작하는지 단계별로 살펴보겠습니다:

프로그램 로드: 사용자 공간의 보안 도구(Falco, Tetragon 등)가 eBPF 프로그램을 커널에 로드합니다
검증(Verification): 커널의 eBPF 검증기(verifier)가 프로그램의 안전성을 확인합니다. 무한 루프나 불법 메모리 접근, 커널 크래시를 유발할 수 있는 코드가 있으면 로드 자체를 거부합니다
JIT 컴파일: 검증을 통과한 프로그램은 네이티브 기계어로 JIT 컴파일됩니다. 덕분에 거의 네이티브에 가까운 성능이 나옵니다
훅 부착: 컴파일된 프로그램이 kprobe, tracepoint, LSM 훅 등 지정된 커널 이벤트 지점에 부착됩니다
이벤트 처리: 해당 커널 이벤트가 발생하면 eBPF 프로그램이 즉시 실행되어, 이벤트 데이터를 수집하거나 정책에 따라 차단 조치를 취합니다
사용자 공간 전달: 수집된 이벤트는 perf 버퍼 또는 링 버퍼를 통해 사용자 공간의 보안 도구로 전달됩니다

eBPF 훅 포인트 유형

보안 모니터링에서 주로 사용하는 eBPF 훅 포인트를 정리해 보면 이렇습니다:

kprobe/kretprobe: 커널 함수의 진입점과 반환점에 부착합니다. 가장 유연하지만 커널 버전에 따라 함수명이 달라질 수 있어서 주의가 필요합니다
tracepoint: 커널이 공식적으로 제공하는 안정적인 추적 지점입니다. kprobe보다 안정적이지만 커버리지가 제한적이라는 트레이드오프가 있죠
LSM 훅: Linux Security Module 프레임워크의 훅 포인트입니다. SELinux/AppArmor와 동일한 보안 결정 지점에서 동작하기 때문에 정책 집행에 이상적입니다
uprobe: 사용자 공간 프로그램의 함수에 부착합니다. 특정 애플리케이션의 동작을 추적할 때 유용한데, 생각보다 활용도가 높습니다

Falco: 행위 기반 런타임 위협 탐지

Falco의 핵심 아키텍처

Falco는 CNCF 졸업(graduated) 프로젝트로, 리눅스 커널 이벤트를 실시간으로 감시하여 비정상적인 행위를 탐지하는 오픈소스 런타임 보안 도구입니다. 기존 시그니처 기반 탐지와 가장 큰 차이점은 행위 기반 탐지(behavioral detection)를 핵심으로 한다는 것입니다. "이 파일이 악성인가?"를 묻는 대신 "이 프로세스가 지금 하는 행동이 정상인가?"를 판단하는 방식이죠.

현재 Falco는 93개의 공식 룰을 관리하고 있으며, 이 중 25개가 maturity_stable 등급으로 기본 릴리즈에 포함되어 있습니다. 나머지는 커뮤니티 기여 룰이라 환경에 맞게 취사선택하면 됩니다.

리눅스 호스트에서 Falco 설치

자, 그럼 실제로 설치해 봅시다. 먼저 단독 리눅스 서버에 Falco를 설치하는 방법부터 살펴볼게요. Debian/Ubuntu 기준입니다.

# Falco 저장소 키 및 소스 추가
curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \
  sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] \
  https://download.falco.org/packages/deb stable main" | \
  sudo tee /etc/apt/sources.list.d/falcosecurity.list

# 패키지 설치
sudo apt-get update
sudo apt-get install -y falco

# eBPF 드라이버로 실행 (커널 모듈 대신 권장)
sudo falco --modern-ebpf

RHEL/CentOS 계열이라면 이렇게 하면 됩니다:

# RPM 저장소 추가
rpm --import https://falco.org/repo/falcosecurity-packages.asc
curl -s -o /etc/yum.repos.d/falcosecurity.repo \
  https://falco.org/repo/falcosecurity-rpm.repo

# 설치
sudo dnf install -y falco

쿠버네티스 환경에서 Falco 배포

쿠버네티스 클러스터에서는 Helm을 사용해 DaemonSet으로 배포하는 게 표준적인 방법입니다.

# Falco Helm 저장소 추가
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Falco 설치 (eBPF 드라이버 사용)
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=modern_ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"

# 배포 상태 확인
kubectl rollout status -n falco daemonset/falco -w

여기서 falcosidekick을 함께 활성화하는 게 포인트입니다. 이걸 켜두면 탐지 이벤트를 Slack, Teams, Prometheus, PagerDuty, 커스텀 웹훅 등 다양한 채널로 바로 보낼 수 있거든요.

Falco 커스텀 룰 작성 실전 가이드

Falco의 진정한 힘은 커스텀 룰에서 나옵니다. 기본 룰만으로도 일반적인 위협은 탐지할 수 있지만, 실제 프로덕션 환경에서는 조직의 보안 정책에 맞춘 커스텀 룰이 거의 필수라고 보시면 됩니다.

커스텀 룰은 /etc/falco/falco_rules.local.yaml에 작성하세요. 기본 룰 파일을 직접 수정하면 업데이트할 때 덮어써지니까요.

예제 1: 컨테이너 내부 셸 실행 탐지

공격자가 컨테이너에 침입하면 가장 먼저 하는 일이 뭘까요? 셸을 띄우는 겁니다. 정상적인 컨테이너 워크로드에서는 셸이 실행될 이유가 거의 없으므로, 이건 매우 강력한 탐지 시그널이 됩니다.

# /etc/falco/falco_rules.local.yaml

- rule: 프로덕션 컨테이너 셸 실행 탐지
  desc: 프로덕션 네임스페이스의 컨테이너에서 셸 프로세스가 실행되면 경고
  condition: >
    spawned_process
    and container
    and shell_procs
    and k8s.ns.name in (production, prod, critical)
  output: >
    프로덕션 컨테이너에서 셸 실행 감지
    (user=%user.name namespace=%k8s.ns.name pod=%k8s.pod.name
     container=%container.name shell=%proc.name command=%proc.cmdline)
  priority: CRITICAL
  tags: [container, shell, mitre_execution]

예제 2: 신뢰하지 않는 레지스트리의 컨테이너 이미지 탐지

공급망 공격 방어의 첫 번째 방어선은 승인된 레지스트리에서만 이미지를 실행하도록 강제하는 것입니다. 이 룰 하나만 잘 적용해도 공급망 공격의 상당 부분을 막을 수 있습니다.

- rule: 미승인 레지스트리 이미지 실행
  desc: 승인된 레지스트리 목록 외부의 컨테이너 이미지 실행을 탐지
  condition: >
    spawned_process
    and container
    and not (
      container.image.repository startswith "gcr.io/my-company/" or
      container.image.repository startswith "registry.internal.company.com/" or
      container.image.repository startswith "docker.io/library/"
    )
  output: >
    미승인 레지스트리의 이미지 실행 감지
    (image=%container.image.repository container=%container.name
     namespace=%k8s.ns.name pod=%k8s.pod.name)
  priority: WARNING
  tags: [container, supply_chain, mitre_initial_access]

예제 3: 컨테이너 드리프트 탐지

컨테이너 드리프트(drift)란 원본 이미지에 없던 새로운 실행 파일이 런타임에 추가되어 실행되는 현상입니다. 공격자가 컨테이너 내부에서 악성 도구를 다운로드하고 실행하는 전형적인 패턴이죠. 이걸 탐지할 수 있으면 공격 체인의 상당히 초기 단계에서 잡아낼 수 있습니다.

- rule: 컨테이너 드리프트 탐지
  desc: 원본 이미지에 없던 실행 파일이 컨테이너에서 실행되면 경고
  condition: >
    spawned_process
    and container
    and proc.is_exe_from_memfd=true
  output: >
    컨테이너 드리프트 - 메모리에서 로드된 실행 파일 탐지
    (container=%container.name image=%container.image.repository
     namespace=%k8s.ns.name pod=%k8s.pod.name
     user=%user.name process=%proc.name cmdline=%proc.cmdline)
  priority: CRITICAL
  tags: [container_drift, mitre_defense_evasion]

예제 4: 민감 파일 접근 모니터링

- rule: 민감 파일 읽기 시도
  desc: /etc/shadow, /etc/passwd 등 민감 파일에 대한 읽기 시도를 탐지
  condition: >
    open_read
    and fd.name in (/etc/shadow, /etc/gshadow, /etc/master.passwd)
    and not proc.name in (login, sshd, passwd, sudo, su)
  output: >
    민감 파일 읽기 시도 탐지
    (file=%fd.name process=%proc.name user=%user.name
     container=%container.name command=%proc.cmdline)
  priority: WARNING
  tags: [filesystem, credential_access, mitre_credential_access]

오탐(False Positive) 관리

프로덕션에서 Falco를 운영하면 오탐은 반드시 발생합니다. 피할 수 없는 현실이에요. 헬스체크 스크립트가 셸을 사용한다든가, CI/CD 러너가 패키지를 설치한다든가 하는 완전히 정당한 활동이 경고를 유발하게 되죠.

이런 경우에는 append를 사용해서 예외를 추가하면 됩니다:

# 헬스체크 스크립트의 셸 실행 허용
- rule: 프로덕션 컨테이너 셸 실행 탐지
  append: true
  condition: >
    and not (
      k8s.ns.name = "monitoring"
      and container.image.repository = "registry.internal.company.com/healthcheck"
    )

# CI/CD 러너의 패키지 설치 허용
- rule: Package Manager Execution
  append: true
  condition: >
    and not (
      k8s.ns.name = "ci-cd"
      and container.image.repository contains "runner"
    )

오탐 관리에서 한 가지 팁을 드리자면, 처음부터 완벽한 룰을 만들려고 하지 마세요. 모니터링 모드로 먼저 배포해서 1~2주 정도 오탐 패턴을 수집한 다음, 예외를 추가하는 방식이 훨씬 현실적입니다.

Tetragon: 커널 수준 정책 집행 엔진

Tetragon이 Falco와 다른 점

Falco가 "탐지하고 알려주는" 도구라면, Tetragon은 여기서 한 발 더 나아갑니다. Tetragon은 Cilium의 서브 프로젝트이자 CNCF 프로젝트로, eBPF를 통해 커널 수준에서 직접 정책을 집행할 수 있습니다. 위반 행위를 탐지하는 것에 그치지 않고, 해당 프로세스를 즉시 종료(SIGKILL)하거나 시스템 콜을 차단할 수 있다는 뜻이에요.

이게 실무에서는 엄청난 차이를 만듭니다.

핵심 차이점을 표로 정리하면 이렇습니다:

항목	Falco	Tetragon
주요 목적	런타임 이상 행위 탐지 및 알림	런타임 정책 집행 + 관찰성
대응 방식	이벤트 기록 → 외부 시스템에 알림	커널 내에서 즉시 차단/종료
성능 오버헤드	상대적으로 높음	1% 미만
정책 정의	YAML 룰 파일	TracingPolicy CRD
쿠버네티스 통합	메타데이터 enrichment	Cilium/Hubble 생태계 네이티브

실무에서 최적의 구성은 Falco로 광범위한 탐지를, Tetragon으로 핵심 정책의 커널 수준 집행을 담당하게 하는 겁니다. 둘 다 각자의 강점이 뚜렷하니까요.

Tetragon 설치: 쿠버네티스 환경

Tetragon의 Helm 차트는 2026년 4월 기준 v1.6.1이 최신입니다. 설치 자체는 꽤 간단합니다.

# Cilium Helm 저장소 추가
helm repo add cilium https://helm.cilium.io
helm repo update

# Tetragon 설치
helm install tetragon cilium/tetragon \
  -n kube-system \
  --set tetragon.grpc.enabled=true \
  --set tetragon.exportAllowList='

# 배포 완료 대기
kubectl rollout status -n kube-system ds/tetragon -w

# 설치 확인
kubectl get pods -n kube-system -l app.kubernetes.io/name=tetragon

Tetragon 설치: 단독 리눅스 호스트

쿠버네티스 없이 단독 리눅스 서버에서도 Tetragon을 쓸 수 있습니다. 의외로 이걸 모르는 분들이 많더라고요.

# 바이너리 다운로드 (최신 릴리즈 확인: github.com/cilium/tetragon/releases)
curl -LO https://github.com/cilium/tetragon/releases/latest/download/tetragon-linux-amd64.tar.gz
tar xzf tetragon-linux-amd64.tar.gz
sudo mv tetragon /usr/local/bin/

# systemd 서비스로 실행
sudo tetragon --config-dir /etc/tetragon/

커널 버전 5.8 이상이 권장되며, BTF(BPF Type Format) 지원이 활성화되어 있어야 합니다. 현재 커널의 BTF 지원 여부는 다음 명령으로 확인할 수 있습니다:

# BTF 지원 확인
ls /sys/kernel/btf/vmlinux 2>/dev/null && echo "BTF 지원됨" || echo "BTF 미지원"

# 커널 버전 확인
uname -r

TracingPolicy 실전 예제

Tetragon의 핵심은 TracingPolicy입니다. 쿠버네티스 CRD(Custom Resource Definition)로 정의되며, 어떤 커널 이벤트를 추적하고 어떤 조치를 취할지를 선언적으로 명시합니다. 말로 설명하는 것보다 예제를 보는 게 훨씬 빠르니까, 바로 들어가 보겠습니다.

예제 1: /etc/shadow 접근 모니터링 및 차단

패스워드 파일에 대한 무단 접근은 권한 상승 공격의 전조일 수 있습니다. 다음 정책은 이런 접근을 모니터링하고, 필요에 따라 차단까지 할 수 있습니다.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: monitor-sensitive-files
spec:
  kprobes:
  - call: "sys_openat"
    syscall: true
    args:
    - index: 0
      type: int
    - index: 1
      type: "string"
    - index: 2
      type: "int"
    selectors:
    - matchArgs:
      - index: 1
        operator: "Equal"
        values:
        - "/etc/shadow"
        - "/etc/gshadow"
        - "/etc/passwd"
      matchBinaries:
      - operator: NotIn
        values:
        - "/usr/bin/login"
        - "/usr/sbin/sshd"
        - "/usr/bin/passwd"

정책을 적용하고 테스트하는 방법은 이렇습니다:

# 정책 적용
kubectl apply -f monitor-sensitive-files.yaml

# 이벤트 관찰 (다른 터미널에서)
kubectl exec -n kube-system ds/tetragon -c tetragon -- \
  tetra getevents -o compact

# 테스트: 컨테이너에서 /etc/shadow 읽기 시도
kubectl exec -it test-pod -- cat /etc/shadow

예제 2: 권한 상승(Privilege Escalation) 실시간 탐지

setuid 계열 시스템 콜을 모니터링하면 프로세스가 자신의 권한을 상승시키려는 시도를 실시간으로 잡아낼 수 있습니다.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-privilege-escalation
spec:
  kprobes:
  - call: "__sys_setresuid"
    syscall: false
    args:
    - index: 0
      type: "int"
    - index: 1
      type: "int"
    - index: 2
      type: "int"
    selectors:
    - matchArgs:
      - index: 1
        operator: "Equal"
        values:
        - "0"
      matchActions:
      - action: Post
        rateLimit: "1m"
        rateLimitScope: "process"

예제 3: 비정상 네트워크 연결 차단

이건 꽤 강력한 정책인데요. 컨테이너가 허용되지 않은 외부 IP에 연결을 시도하면 즉시 해당 프로세스를 종료해 버립니다.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-unauthorized-connections
spec:
  kprobes:
  - call: "tcp_connect"
    syscall: false
    args:
    - index: 0
      type: "sock"
    selectors:
    - matchArgs:
      - index: 0
        operator: "NotDAddr"
        values:
        - "10.0.0.0/8"
        - "172.16.0.0/12"
        - "192.168.0.0/16"
      matchActions:
      - action: Sigkill

사설 IP 대역 외부로의 TCP 연결을 시도하는 프로세스를 즉시 종료하는 정책입니다. 한 가지 꼭 주의할 점이 있는데, 프로덕션에서 적용하기 전에 반드시 action: Post(모니터링 전용)로 먼저 충분히 테스트하세요. 안 그러면 정상적인 외부 API 호출까지 차단돼서 장애가 발생할 수 있습니다.

예제 4: 컨테이너 탈출 시도 탐지

컨테이너 탈출은 가장 심각한 보안 위협 중 하나입니다. 다음 정책은 일반적인 컨테이너 탈출 기법에서 사용되는 파일 경로 접근을 감시하고 즉시 차단합니다.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-container-escape
spec:
  kprobes:
  - call: "sys_openat"
    syscall: true
    args:
    - index: 0
      type: int
    - index: 1
      type: "string"
    - index: 2
      type: "int"
    selectors:
    - matchArgs:
      - index: 1
        operator: "Prefix"
        values:
        - "/proc/1/root"
        - "/proc/1/ns"
        - "/sys/fs/cgroup"
      matchActions:
      - action: Sigkill

Falco + Tetragon 통합 보안 아키텍처

실제 프로덕션 환경에서는 Falco와 Tetragon을 함께 사용하는 것이 가장 효과적입니다. 각 도구의 장점을 살려서 역할을 분담하면 탐지 범위와 대응 속도 모두를 극대화할 수 있거든요.

역할 분담 전략

Falco 담당: 광범위한 행위 기반 이상 탐지, 쿠버네티스 감사 로그 분석, 다양한 알림 채널 연동, 컴플라이언스 모니터링
Tetragon 담당: 핵심 보안 정책의 커널 수준 집행, 파일 접근 제어, 네트워크 정책 집행, 프로세스 실행 제어

개인적으로는 이 조합이 2026년 현재 가장 가성비 좋은 런타임 보안 스택이라고 생각합니다.

통합 배포 예시

Helm을 사용해 두 도구를 함께 배포하는 스크립트를 준비했습니다:

#!/bin/bash
# eBPF 런타임 보안 스택 배포 스크립트

# 1. Tetragon 배포 (정책 집행)
helm repo add cilium https://helm.cilium.io
helm install tetragon cilium/tetragon \
  -n kube-system \
  --set tetragon.grpc.enabled=true

# 2. Falco 배포 (탐지 + 알림)
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=modern_ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="${SLACK_WEBHOOK_URL}"

# 3. 배포 상태 확인
echo "=== Tetragon 상태 ==="
kubectl rollout status -n kube-system ds/tetragon -w

echo "=== Falco 상태 ==="
kubectl rollout status -n falco daemonset/falco -w

# 4. TracingPolicy 적용
kubectl apply -f monitor-sensitive-files.yaml
kubectl apply -f detect-privilege-escalation.yaml
kubectl apply -f block-unauthorized-connections.yaml

echo "eBPF 런타임 보안 스택 배포 완료"

Prometheus + Grafana 통합 모니터링

Falco와 Tetragon의 이벤트를 Prometheus 메트릭으로 수집하고 Grafana 대시보드로 시각화하면, 보안 상태를 한눈에 파악할 수 있습니다. 솔직히 이 부분을 빼먹으면 아무리 좋은 탐지 시스템을 구축해도 의미가 반감됩니다.

# Falcosidekick Prometheus 메트릭 활성화
helm upgrade falco falcosecurity/falco \
  --namespace falco \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.prometheus.enabled=true

# Tetragon Prometheus 메트릭 활성화
helm upgrade tetragon cilium/tetragon \
  -n kube-system \
  --set tetragon.prometheus.enabled=true \
  --set tetragon.prometheus.serviceMonitor.enabled=true

모니터링할 주요 메트릭은 다음과 같습니다:

falco_events_total: Falco가 탐지한 총 이벤트 수 (priority 별 분류)
tetragon_events_total: Tetragon이 처리한 총 이벤트 수
tetragon_policy_events_total: TracingPolicy에 의해 트리거된 이벤트 수
tetragon_enforcer_events_total: 정책 집행(차단/종료)이 실행된 횟수

운영 환경 성능 최적화

eBPF 기반 보안 도구를 프로덕션에 배포할 때 가장 많이 받는 질문이 "성능에 얼마나 영향을 미치나요?"입니다. 결론부터 말씀드리면, 올바르게 구성하면 영향은 미미합니다. 하지만 (그리고 이게 중요한데) 잘못 구성하면 꽤 심각한 오버헤드가 발생할 수 있습니다.

Falco 성능 튜닝

# /etc/falco/falco.yaml 성능 관련 설정

# 시스템 콜 버퍼 크기 (기본값: 8MB, 고부하 환경에서 증가)
syscall_buf_size_preset: 4  # 0-10 스케일, 4 = 약 8MB

# 내부 이벤트 큐 크기
outputs:
  queue:
    capacity: 1024  # 기본 0(무제한), 메모리 제한이 필요하면 설정

# 불필요한 이벤트 소스 비활성화
plugins: []  # 사용하지 않는 플러그인 제거

Tetragon 성능 튜닝

# Tetragon Helm values.yaml 성능 설정
tetragon:
  # 링 버퍼 크기 (바이트 단위)
  exportRateLimitPerMinute: 1000  # 분당 최대 내보내기 이벤트 수

  # 리소스 제한 설정
  resources:
    limits:
      cpu: "1"
      memory: "1Gi"
    requests:
      cpu: "200m"
      memory: "512Mi"

핵심 성능 최적화 원칙

성능 최적화에서 가장 중요한 원칙 네 가지를 정리해 봤습니다.

인커널 필터링 최대화: Tetragon의 selectors를 적극 활용해서 커널 내에서 이벤트를 필터링하세요. 사용자 공간으로 전달되는 이벤트가 적을수록 오버헤드가 줄어듭니다. 이게 성능 최적화의 핵심이라고 해도 과언이 아닙니다
와일드카드 매칭 최소화: Falco 룰에서 과도하게 넓은 조건은 이벤트 폭주의 원인이 됩니다. 가능한 한 구체적인 조건을 사용하세요
Rate Limiting 설정: 동일한 유형의 이벤트가 반복 발생할 때 모든 이벤트를 개별로 처리하지 않도록 레이트 리미팅을 꼭 적용하세요
모니터링 우선, 집행 나중: 새로운 정책은 반드시 모니터링 모드(Falco의 룰 또는 Tetragon의 action: Post)로 먼저 배포해서 오탐을 확인한 후에 집행 모드(action: Sigkill)로 전환하세요. 이 순서를 지키지 않으면 서비스 장애로 이어질 수 있습니다

eBPF 보안 모니터링의 위협과 한계

eBPF가 강력한 기술인 건 맞지만, 만능은 아닙니다. 이 부분을 솔직하게 짚고 넘어가야 할 것 같습니다. 2026년 들어 eBPF 이벤트 파이프라인 자체를 노리는 새로운 위협이 실제로 등장하고 있거든요.

eBPF 루트킷의 등장

최신 리눅스 루트킷들은 eBPF 이벤트 경로 내의 함수를 가로채서, 보안 도구가 읽기 전에 이벤트 레코드를 필터링하거나 아예 삭제해 버립니다. 감시 카메라 자체를 무력화하는 셈이죠. 이건 eBPF 기반 모니터링이 만능이 아니라는 걸 잘 보여주는 사례입니다.

대응 전략

다층 방어(Defense in Depth): eBPF 모니터링만 의존하지 말고, auditd, 파일 무결성 모니터링(AIDE/OSSEC), 네트워크 IDS 등 여러 계층의 보안을 함께 운영하세요
서명된 eBPF 프로그램: 리눅스 커널 6.x 이상에서는 서명된 eBPF 프로그램만 로드하도록 제한할 수 있습니다. 악성 eBPF 프로그램의 로드를 원천 차단하는 효과적인 방법입니다
커널 잠금(Kernel Lockdown): 커널 lockdown 모드를 활성화하면 BPF 프로그램 로드에 추가적인 제한을 가할 수 있습니다
sysctl 하드닝: kernel.unprivileged_bpf_disabled = 1을 설정하여 비권한 사용자의 BPF 프로그램 로드를 차단하세요

# eBPF 보안 강화를 위한 sysctl 설정
echo "kernel.unprivileged_bpf_disabled = 1" | sudo tee -a /etc/sysctl.d/99-ebpf-hardening.conf
echo "net.core.bpf_jit_harden = 2" | sudo tee -a /etc/sysctl.d/99-ebpf-hardening.conf
sudo sysctl --system

자주 묻는 질문 (FAQ)

eBPF 기반 보안 도구를 사용하려면 최소 커널 버전은 얼마인가요?

기본적인 eBPF 기능은 커널 4.14 이상에서 사용할 수 있지만, Falco와 Tetragon의 모든 기능을 제대로 활용하려면 커널 5.8 이상이 권장됩니다. 특히 BTF(BPF Type Format) 지원이 중요한데, 이건 커널 5.2 이상에서 사용할 수 있으며 커널 설정에서 CONFIG_DEBUG_INFO_BTF=y로 활성화되어 있어야 합니다. 다행히 2026년 기준으로 주요 배포판(Ubuntu 22.04+, RHEL 9+, Debian 12+)은 모두 이 요건을 충족하고 있어서, 대부분의 경우 별도 작업 없이 바로 사용할 수 있습니다.

Falco와 Tetragon 중 어떤 것을 먼저 도입해야 하나요?

보안 성숙도에 따라 다릅니다만, 런타임 보안을 처음 도입하는 조직이라면 Falco부터 시작하는 걸 추천합니다. 기본 룰셋만으로도 즉각적인 가시성을 확보할 수 있고, Falcosidekick을 통한 알림 연동이 정말 간편하거든요. 이후 핵심 보안 정책의 커널 수준 집행이 필요해지면 그때 Tetragon을 추가로 도입하면 됩니다. 궁극적으로는 Falco(탐지)와 Tetragon(집행)을 함께 운영하는 것이 가장 효과적이지만, 한꺼번에 다 하려고 하면 운영 부담이 커지니까 단계적으로 접근하는 게 좋습니다.

eBPF 보안 모니터링의 성능 오버헤드는 어느 정도인가요?

올바르게 구성된 환경에서 Tetragon은 1% 미만의 CPU 오버헤드를 보입니다. Falco는 모니터링하는 시스템 콜의 양에 따라 다르지만, eBPF 드라이버를 사용하면 일반적으로 1~3% 수준입니다. 핵심은 인커널 필터링을 최대한 활용하여 사용자 공간으로 전달되는 이벤트 양을 줄이는 것인데, 과도하게 넓은 룰이나 와일드카드 매칭이 성능 저하의 주범이라는 점만 기억해 두시면 됩니다.

SELinux/AppArmor와 eBPF 보안 도구는 어떻게 다른가요?

이 질문을 정말 많이 받는데요. SELinux/AppArmor는 사전 정의된 정적 정책을 기반으로 접근 제어를 수행하는 MAC(Mandatory Access Control) 시스템입니다. 반면 eBPF 기반 도구는 동적 런타임 관찰과 대응에 초점을 맞추고 있죠. 중요한 건, 이 둘이 경쟁 관계가 아니라 상호 보완적이라는 점입니다. SELinux/AppArmor가 정적 보안 경계를 설정하고, eBPF 도구가 그 경계 내에서 발생하는 동적 위협을 감시하고 대응하는 구조가 이상적입니다. 실제로 Tetragon은 LSM 훅을 통해 SELinux와 동일한 보안 결정 지점에서 동작할 수도 있습니다.

eBPF 보안 모니터링을 우회하는 공격에 대한 방어 방법은?

2026년 현재 가장 주의해야 할 위협은 eBPF 이벤트 파이프라인을 노리는 루트킷입니다. 방어를 위해 kernel.unprivileged_bpf_disabled = 1과 net.core.bpf_jit_harden = 2를 필수적으로 설정하고, 커널 lockdown 모드를 활성화하세요. 그리고 (아무리 강조해도 지나치지 않은 부분인데) eBPF 모니터링에만 의존하지 말고 auditd, 파일 무결성 감시(AIDE), 네트워크 IDS를 함께 운영하는 다층 방어 전략을 반드시 적용해야 합니다. 서명된 eBPF 프로그램만 로드하도록 제한하는 것도 빠뜨리지 마세요.